Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 29/07/2014, à 11:06

Fly0s

Interface graphique pour un programme en ligne de commande

Bonjour à tous,

J'ai développé un petit programme (enfin, pour être plus précis et modeste, j'ai modifié un code source déjà existant) qui fait une analyse statistique à partir de données génétiques, écrit en C++ et qui tourne très bien sous Windows/Mac/Linux, mais en ligne de commande.

Comme les biologistes sont souvent effrayés par la ligne de commande, et souvent sous Windows (dont on ne peut pas dire que l'invite de commande soit super sympa à utiliser...), je me demandais s'il était difficile de créer une interface graphique pour rentrer :
- éventuellement, la localisation du binaire
- la localisation des fichiers d'entrée
- les paramètres divers du programme (genre nombre d'itérations, etc...)
qui lancerait ensuite la commande dans un terminal.

J'ai un peu regardé du côté de QtCreator, qui possède une interface de création de GUI. Le problème, c'est que je ne suis absolument pas programmeur de formation, et que je n'ai jamais fait de choses de ce genre.

Du coup, je me suis dit que j'allais demander à des vétérans leur avis sur une telle entreprise. À quel point il serait compliqué de créer un front-end graphique pour mon programme (même basique, qui se contente juste de rassembler les infos et de lancer le programme en invite de commande), sachant que mon niveau en interface graphique s'approche du 0 (quelques vagues tutoriels Qt tout simple que j'avais fait il y a un bon moment maintenant) ?

J'entends aussi pas mal parler de QML qui permettrait de faire des interfaces graphiques sans trop rentrer dans les détails du code Qt et C++, mais je sais pas du tout si c'est adapté à mon cas...

Je suis ouvert à tout conseil !

Hors ligne

#2 Le 30/07/2014, à 21:52

Arbiel

Re : Interface graphique pour un programme en ligne de commande

Bonsoir

J'utilise depuis quelque temps "zenity" qui est assez simple. Cependant, dans ton cas, comme tu veux localiser plusieurs fichiers et demander plusieurs paramètres, il va te falloir une succession d'écrans, autant que de fichiers à localiser et de paramètres à initialiser, chaque écran ne te donnant qu'une seule information.

"yad", qui n'est pas disponible en binaire (autant que je sache) te permettrait de saisir plusieurs informations avec un seul écran. ce qui est plus confortable.

Je suis actuellement peu disponible, mais disposé à t'aider dans l'utilisation de l'un ou l'autre de ces deux produits.

Arbiel


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#3 Le 30/07/2014, à 22:06

Babdu89

Re : Interface graphique pour un programme en ligne de commande

Bonsoir .
Je vais peut-être dire une bêtise, mais...

Fly0s a dit;
J'ai développé un petit programme (enfin, pour être plus précis et modeste, j'ai modifié un code source déjà existant) qui fait une analyse statistique à partir de données génétiques, écrit en C++ et qui tourne très bien sous Windows/Mac/Linux, mais en ligne de commande.

Comme les biologistes sont souvent effrayés par la ligne de commande, et souvent sous Windows (dont on ne peut pas dire que l'invite de commande soit super sympa à utiliser...), je me demandais s'il était difficile de créer une interface graphique pour rentrer :

Arbiel a dit;
J'utilise depuis quelque temps "zenity" qui est assez simple........

Zenity , fonctionne sous W$ et MAc ?...

@+. Babdu89  .


J'ai découvert Ubuntu avec la 07.10.... Et alors?!...  Depuis je regarde de temps en temps si Windows marche toujours....

Hors ligne

#4 Le 31/07/2014, à 08:58

Fly0s

Re : Interface graphique pour un programme en ligne de commande

Zenity semble être multi-plateforme (bien qu'il semble manquer le support Mac OS X, d'après Wikipédia), et YAD, je trouve pas l'information. Je vais me pencher sur ces deux solutions, voir ce que je peux faire avec. C'est intéressant en effet !

Hors ligne

#5 Le 31/07/2014, à 15:41

Arbiel

Re : Interface graphique pour un programme en ligne de commande

Ma proposition ne couvre que GNU/Linux. Mais pour répondre à la demande de Fly0s, nul besoin, à mon avis, d'un produit multiplateforme. L'important est de proposer à ses utilisateurs, fût-ce avec trois produits différents, des interfaces qui soient, si ce n'est strictement identiques, du moins suffisamment semblables pour qu'ils puissent passer, le cas échéant, de l'une à l'autre sans trop de difficultés.

yad http://sourceforge.net/projects/yad-dialog/

Avec Windows, j'ai utilisé Virtual Basic pour écrire une petite application. qui n'a pu aboutir qu'après mon passage à GNU/Linux et le recours à VirtualBox, Je n'ai plus beaucoup de souvenirs de ce langage.

Je n'ai par ailleurs aucune connaissance des logiciels Mac.

Arbiel


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#6 Le 31/07/2014, à 16:52

claudius01

Re : Interface graphique pour un programme en ligne de commande

Bonjour,

Fly0s a écrit :

J'ai développé un petit programme (enfin, pour être plus précis et modeste, j'ai modifié un code source déjà existant) qui fait une analyse statistique à partir de données génétiques, écrit en C++ et qui tourne très bien sous Windows/Mac/Linux, mais en ligne de commande.

Pourquoi pas un formulaire Web de saisie qui ne nécessite de développer qu'une page en HTML + Python, PHP, Javascript, etc. et à déployer localement puis à proposer une URL du type "file:///xxxx" avec présentation des résultats après appel à ce "petit programme" pour les utilisateurs avec leur navigateur préféré (un seul développement pour 3 plates-formes ;-)

NB: Cela s'appelle une solution avec un client léger en opposition au client lourd.


Cordialement, A+
--
Claudius

Dernière modification par claudius01 (Le 31/07/2014, à 17:02)

Hors ligne

#7 Le 31/07/2014, à 16:59

alius

Re : Interface graphique pour un programme en ligne de commande

Bonne idée, mais cela nécessite que son programme soit entierement paramétrable avec les arguments de la ligne de commande pour qu'il soit executable par python par exemple.

EDIT: je ne crois pas qu'il y est de sollution simple à ton problème.

Dernière modification par alius (Le 31/07/2014, à 17:00)


Alius

Hors ligne

#8 Le 31/07/2014, à 17:45

lann

Re : Interface graphique pour un programme en ligne de commande

Si tu as déjà fait le code source en C++, orientes toi vers gtkmm (Multiplateforme)

Hors ligne

#9 Le 31/07/2014, à 20:00

claudius01

Re : Interface graphique pour un programme en ligne de commande

alius a écrit :

Bonne idée, mais cela nécessite que son programme soit entièrement paramétrable avec les arguments de la ligne de commande pour qu'il soit exécutable par python par exemple.

Certes, mais le demandeur maîtrise les sources, donc si le programme n'est pas interactif au sens qu'il s'exécute avec un ensemble de paramètres qui peuvent:
1) Soit être mis dans un fichier qui sera alors écrit suite au post du formulaire puis lu par le programme
2) Soit être mis en ligne de commande et parsés par l'excellent getopt (cf. Example of Getopt)

Maintenant à choisir, je préfère de loin la solution "fichier" qui est plus adaptée si beaucoup de paramètres ( > 10) à prendre en compte et qui plus est, serait au format XML pour une exploitation normalisée au moyen d'outils standards (Formulaire Web => XML notamment + Contraintes sur toutes ou une partie des saisies - cf. Validateur). L'autre avantage est la possibilité donnée à chaque utilisateur de reprendre son propre jeux de paramètres en soumettant ledit fichier au "petit programme".

Dernière modification par claudius01 (Le 01/08/2014, à 16:11)

Hors ligne

#10 Le 02/08/2014, à 12:43

Fly0s

Re : Interface graphique pour un programme en ligne de commande

Merci à tous pour vos réponses !

@claudius01: Je vais peut-être dire une connerie, mais le programme doit se lancer en local (il est "petit" en termes de code, mais il demande des ressources en CPU et en RAM, potentiellement sur une longue durée : la bioinfo, c'est relou ! wink ). Du coup, demander à l'utilisateur d'installer un serveur PHP pour exécuter "l'interface graphique", c'est pas l'idéal si ?
EDIT: Et j'ai aussi peur que l'utilisateur soit perdu d'avoir à utiliser une page Web pour lancer quelque chose en local...

@lann : Qu'apporte GTKMM par rapport à Qt ?

@alius : Oui, je crains qu'il n'y ait pas de solution simple... Mais qui ne tente rien... wink

Désolé si je sors des conneries, comme je le disais, je ne suis pas tout à fait un expert en la matière...

Vous pensez que c'est vraiment pas réaliste de se lancer dans une interface Qt de ce genre sans trop s'y connaître ? Je peux apprendre, mais le problème est que je suis un peu limité par le temps, donc je préfère faire au plus efficace...

Dernière modification par Fly0s (Le 02/08/2014, à 12:44)

Hors ligne

#11 Le 02/08/2014, à 12:51

lann

Re : Interface graphique pour un programme en ligne de commande

Fly0s a écrit :

@lann : Qu'apporte GTKMM par rapport à Qt ?

Je n'en sais trop rien. J'ai toujours utiliser gtkmm car j'étais sous le bureau gnome.
Un petit lien qui les compare : http://www.wikivs.com/wiki/GTK_vs_Qt

Hors ligne

#12 Le 02/08/2014, à 12:58

Fly0s

Re : Interface graphique pour un programme en ligne de commande

@Iann : OK, merci. Du coup, comme je connais déjà un tout petit peu Qt, je pense que je vais rester dessus. J'ai l'impression que je vais pas trop échapper au fait de me jeter là-dedans...

De ce que je vois sur Internet, il y a un objet Qt, nommé QProcess, qui permet de lancer un programme et pouvoir choper les entrées/sorties standard. Je peux peut-être construire un GUI suffisamment simple qui utilise QProcess pour lancer mon programme et affiche la sortie standard pour surveiller le processus ? C'est utopique ?

Hors ligne

#13 Le 02/08/2014, à 14:40

lann

Re : Interface graphique pour un programme en ligne de commande

Lancer une commande depuis un processus c'est facile mais récupérer les données ?

Hors ligne

#14 Le 02/08/2014, à 15:07

Fly0s

Re : Interface graphique pour un programme en ligne de commande

En fait, il n'y a rien à récupérer, la commande écrit les résultats dans un fichier, c'est tout. Par contre, il faut récupérer la sortie standard pour afficher l'avancement.

Hors ligne

#15 Le 02/08/2014, à 16:14

lann

Re : Interface graphique pour un programme en ligne de commande

Regarde alors avec la fonction system : http://www.cplusplus.com/reference/cstdlib/system/

Hors ligne

#16 Le 03/08/2014, à 11:38

CAFELion

Re : Interface graphique pour un programme en ligne de commande

Puisque tu a déjà le programme en ligne de commande qui fonctionne,
fait une petite interface graphique en python avec tkinter. il ne restera que les données a mettre dans l'ordre pour lancer ton petit programme par python.

Je n'ai aucune idée si python est porté sur Windows ou Mac ?

voir tkinter

Dernière modification par CAFELion (Le 03/08/2014, à 11:41)


Ubuntu 14.04 - SSD - AMD 8 core - NAS Netgear ReadyNas  || OpenELEC 4 - DD - AMD 3 core - Terratec Cinergy S2 || Debian 6 xfce - Celeron || raspberry py

Hors ligne

#17 Le 03/08/2014, à 15:41

diablotin87

Re : Interface graphique pour un programme en ligne de commande

Je ne suis pas un expert en GUI mais ce qui est sur, c'est que si les utilisateurs ne sont pas des pros, il faudrait
1) avoir un executable linke en static, comme ca l'utilisateur n'a pas a compiler lui meme le programme.
2) faire une GUI en python (dispo sour OS X linux et Win)
3) la lib graphique (Qt ou GTK) depend de toi mais peut etre que Qt est le plus approprie.

En resume : si python et pyQt sont installe sur les machines, tu fournis un package avec le script python pour la GUI et tes executables compile en static (lib/.dll inclus dans l'executable). L'utilisateur a juste a executer ton script python et roule ma poule.

C'est mon avis smile

Hors ligne

#18 Le 04/08/2014, à 08:58

Fly0s

Re : Interface graphique pour un programme en ligne de commande

Oui, ils ne sont pas spécialement pros... L'interface Tk en python peut-être une solution, en effet.

Merci à tous pour vos conseils. Je reviendrai poster ici le résultat quand j'aurais avancé là-dessus (ça risque de prendre un moment, on verra).

Hors ligne

#19 Le 04/08/2014, à 21:31

claudius01

Re : Interface graphique pour un programme en ligne de commande

Bonsoir,

Fly0s a écrit :

... Du coup, demander à l'utilisateur d'installer un serveur PHP pour exécuter "l'interface graphique", c'est pas l'idéal si ?

Tout d'abord, cela n'est pas un serveur PHP, et de plus, on ne ne demande jamais à un utilisateur lambda d'installer un serveur quel qu'il soit, ce serveur est déjà installé sous forme d'un deamon par l'administrateur ou la personne qui maîtrise un tant soit peu le système ;-)
En l’occurrence, ce serveur qui fait peur est tout simplement apache2 (cf. Serveur HTTP Apache 2) qui servira tout aussi bien de simples pages HTML avec ou sans Javascript, Python, PHP, et que sais-je...

Fly0s a écrit :

Et j'ai aussi peur que l'utilisateur soit perdu d'avoir à utiliser une page Web pour lancer quelque chose en local...

Si tu savais le nombre de trucs et en particulier les aides en lignes qui sont lancées "en local' via des interfaces Web, et alors il où le problème. Le seul problème est que le l'architecture propose à l'utilisateur une interface de saisie et que le résultat lui soit présenté. Depuis quand l'utilisateur se préoccupe de l'architecture d'une solution si celle-ci lui rend le service souhaité ;-((


Cordialement, A+
--
Claudius

Dernière modification par claudius01 (Le 04/08/2014, à 21:40)

Hors ligne

#20 Le 04/08/2014, à 21:52

alius

Re : Interface graphique pour un programme en ligne de commande

Ce que veux dire FlyOs c'est que le fait d'utiliser un navigateur web en guise d'interface graphique d'un programme local peut provoquer des confusions. L'utilisateur va par exemple penser que le programme qu'il utilise est sur le net.


Alius

Hors ligne

#21 Le 04/08/2014, à 22:31

claudius01

Re : Interface graphique pour un programme en ligne de commande

alius a écrit :

Ce que veux dire FlyOs c'est que le fait d'utiliser un navigateur web en guise d'interface graphique d'un programme local peut provoquer des confusions. L'utilisateur va par exemple penser que le programme qu'il utilise est sur le net.

Je ne vois toujours pas où est le problème...

Et si un jour le programme est effectivement sur le net (pour des raisons de ressources requises - CPU/Mémoire/Disque/Parallélisation, etc.) là, l'utilisateur sera bien content de ne rien changer à ses "petites" habitudes ?

Désolé, un programme qui fonctionne sur 3 plates-formes / OS et le réduire à une seule ou presque sauf travail de portage aléatoire pour une simple raison d'IHM ne peut me satisfaire dans le principe.

Maintenant, FlyOs fait ce qu'il veut @ à ses utilisateurs et si l'architecture client-serveur lui fait peur, qu'il sache qu'elle est utilisée depuis près de 25 ans (cf. Le client-serveur et le downsizing ;-)

Dernière modification par claudius01 (Le 04/08/2014, à 22:53)

Hors ligne

#22 Le 05/08/2014, à 09:07

Fly0s

Re : Interface graphique pour un programme en ligne de commande

Ne te fâche pas claudius01, c'est juste que je pense que demander aux utilisateurs de mon programme d'avoir apache d'installé, c'est autre chose que leur demander d'avoir python d'installé par exemple. La mise en place d'une exécution sur un serveur ne se mettra jamais en place de mon fait, en tout cas. Et je n'ai rien contre l'architecture client-serveur ! Je suis pas sûr qu'elle soit adaptée dans le cas présent, c'est tout.

Au final, je pense que je vais tester la solution Qt avec QProcess, et si je vois que c'est trop compliqué ou que la portabilité est trop dure à gérer, je passerai sur du Python avec Tk (je préfère éviter de demander à l'utilisateur d'installer Python).

EDIT : Je crois qu'une partie du malentendu vient de la méconnaissance de ce que peut être un utilisateur académique en informatique. Souvent, il est administrateur de sa machine, il ne fait que peu confiance à son DSI, qui de toute façon est surchargée (souvent, c'est 1 informaticien seul) et ne s'occupe certainement pas de lui installer quoique ce soit, et pourtant, il est assez peu éduqué (quoiqu'un peu plus que la moyenne) en informatique.

Dernière modification par Fly0s (Le 05/08/2014, à 09:11)

Hors ligne

#23 Le 05/08/2014, à 19:46

alius

Re : Interface graphique pour un programme en ligne de commande

@claudiius : ce n'était qu'un simple exemple de confusion possible, nous informaticiens ne pouvons tous simplement pas nous mettre dans la tete des profanes.

@FlyOs : de toute façon, là tu vas te lancer dans du "bricolage" si tu me permet l'expression donc rien de mieux que d'essayer et de voir ce que ça donne.


Alius

Hors ligne

#24 Le 26/08/2014, à 16:28

Fly0s

Re : Interface graphique pour un programme en ligne de commande

1409066736.jpg

Et voilà ! En fait, avec Qt Creator, ça m'a pris 2 jours de travail !! J'ai vraiment été impressionné par la facilité avec laquelle on pouvait faire un GUI avec ! Quant à QProcess, vraiment très facile à utiliser, même pour un débutant comme moi !

Reste à voir si ça tourne sous Windows, mais y a pas de raison, au pire ça serait 2-3 bricoles à changer, je pense.

Merci à tous pour votre aide !

Dernière modification par Fly0s (Le 26/08/2014, à 16:29)

Hors ligne

#25 Le 23/09/2014, à 16:40

Fly0s

Re : Interface graphique pour un programme en ligne de commande

Petit update : c'était donc plutôt facile de concevoir l'interface, de la faire tourner sous Linux et de la distribuer pour Linux (suffit de dire aux gens d'installer les bons paquets Qt).

Pour passer sous Windows, ça a été un poil plus compliqué, mais ça marche à coup de DLL (le plus long, c'est de trouver tout ceux qu'il faut).

Pour Mac OS X par contre... À part me taper à recompiler Qt en statique et tout linker en statique... En dynamique, c'est hyper compliqué, avec ces histoires de frameworks, de bundle, etc... Comme je n'ai pas trop facilement accès à un Mac, ça va attendre un peu, je pense.

Hors ligne