question bête : ya t il un moyen de creer une application console qui pourrait de manière non modale crée/détruire à la volée des fenêtres QT ? J'ai essayé avec des QThread qui génére les widgets etc ... mais j'ai enormement de warning bizarre à l'execution et l'appli en général se traine.

Je vois mal comment c'est possible: le thread GUI a besoin d'être le thread primaire, et doit tourner en ayant appellé QApplication::exec().

Au pire, tu peux développer une console, de cette façon tu as ton thread GUI principal + boucle d'événements, et tu peux créer des widgets à la volée sans souci

Si c'est pas indiscret, c'est quoi le contexte/but?

Edit: ortho...

en gros, j'ai des applis de calculs scientifiques qui font genre, des calculs.
J'aimerais avoir des fonctions qui, comme matlab, me permettent de dessiner dans une fenetre un graphe de valeur de ce tableau.
 
J'ai deja tt le truc pr le dessin, j'aimerais juste avoir la possibilité d'instancier à la volée les fenetres que je veut sans avoir à utiliser une fenetre.

Peux-tu te rabattre vers une autre solution? Tu peux pencher pour 2 applications:
> l'application de l'interface, n'ayant pas forcèment de widget visible (disons une icône dans le tray, histoire de pas le perdre),
> ton appli de calcul qui utilise les entrées/sorties standards.
 
Tu lances la 2ème dans un QProcess déclaré dans le premier, et tu parses la sortie; ça t'es possible?
Sans ça, je ne vois vraiment pas comment faire

j'ai pensé à deux trucs :
-> créer une fausse console vers laquelle on redirige cout//cin
-> créer une QCoreApplication qui spawn un autre process qui contient le code de visualisation. Ensuite, comment faire communiquer les deux bouzins ??

La première solution me paraît la plus facile et adaptée, si je comprends bien ce que tu envisages; bien sûr je n'ai pas la moindre idée de l'existant...
S'il est de taille, ça peut être une bonne chose d'embrayer sur la séparation process de calcul/process GUI. Pour les faire communiquer, c'est de suite plus chaud
Si tu es sous linux avec un support DBus, tu peux utiliser QtDBus. Si le dialogue ne contient pas trop de données, tu peux passer par les redirections d'entrées/sorties (du côté du process pour l'interface, de l'autre, tu pilotes avec QProcess, qui a des fonctions qui ne nécessite pas l'intervention d'une boucle d'événement).
 
C'est vraiment les 2 premières méthodes qui me viennent à l'esprit; je me suis toujours servi de QProcess pour diriger un process console depuis une interface, rarement l'inverse. (Et QtDBus, je sais qu'il existe, mais je l'ai pas encore testé, ni lui, ni DBus en fait )

en gros, le truc est multi-palteforme. Donc DBus oui mais non
Ensuite, il faut que ca soit al console qui drive le reste et non l'inverse car mes users ont et doivent conserver l'habitude d'ecrire du code console et utilise la library pour faire de l'affichage nopn modal non bloquant.
 
Je vais faire mumuse avec QProcess , ca devrait rouler

Tu pourras poster le résultat de tes pérégrinations? En fait de rarement, c'est vraiment "jamais" que j'ai redirigé les flux
Donc, je suis assez curieux de voir si ça fonctionne dans un tel cas.