Créer un GUI. Quel toolkit?

Salut,
ayant fini la première étape de mon projet (voir pointeur-vers-structures-t41815.html), je pensais lui coller un GUI pour:
-me débarrasser de l’interface bidon que j’ai pondu à coup de printf.
-le passer à mes potes et que ça ne les rebute pas.
-continuer à apprendre.

Michel_vi avait posté quelque chose de semblable mais lui partait sur du C++.
Mon projet est écrit en C. Je me suis naturellement tourné vers les librairies fournies par GTK+ ainsi que l’outil glade. En plus je comprends rien à la licence de Qt.

Avant de me lancer là dedans, je voudrais être sûr de prendre la bonne direction.
-Je rame pour trouver de la doc sur GTK. Pour l’instant, j’ai une page datant de 2007 où le mec explique comment faire un mini editeur de texte. Le fichier .glade est tellement vieu que je n’arrive pas à l’ouvrir.
-Est ce que c’est portable? Tout le monde chez windows hein…
-Mon programme va ressembler à un tableur. Je voudrais rajouter/enlever des lignes dynamiquement, c’est à dire en fonction de ce que fait l’utilisateur via l’interface ou bien en fonction du fichier ouvert. Là c’est le flou. L’interface m’a l’air d’être définie à la compilation, comment modifier un container grid lors de l’éxecution…
Je m’attendais à ce que glade me sorte un fichier .c que j’aurais pu bidouiller mais non. Le fonctionnement de tout ça n’est pas encore très clair pour moi. Vive la doc…

Si quelqu’un a une expérience avec Qt ou GTK et le C, je prends. Tout avis sur cette histoire d’interface dynamique m’intéresse aussi.

S’il le faut, ça ne sera pas inintéressant, je peux essayer de tout refaire en C++/Qt mais je ne connais que (vaguement) le C (et matlab).

QT est l’interface qui a le vent en poupe en ce moment, GTK semble souffrir de défaut / manque d’évolution qui rebute pas mal de projet. WireShark par exemple…

Si tu veux réaliser simplement un projet multi-plateforme, à ce jour Qt est plus recommandé/simple. L’IDE QtCreator est assez bien foutu et simple d’utilisation.

Gtk est en pleine mutation et actuellement les nouveaux widqets évoluent rapidement. Tu peux faire du multiplateforme mais ça va te demander plus de travail. L’IDE Anjuta est bien foutu et propose sensiblement les mêmes fonctions que QtCreator (en moins shinny).

Glade t’aide à définir une interface graphique. Ça produit un fichier xml détaillant les widgets de cette interface. Après dans ton programme tu vas manipuler les widgets, les détruire, etc.

Après est-ce que tu as forcément besoin de faire ton programme en C ? Le cas échéant, les langages comme Python sont portables et proposent des toolkits graphiques simples (ex: tkinter) pour réaliser simplement des programmes…

Salut et merci à tout les deux pour vos réponses.
J’ai pris un peu de temps pour me documenter.
Pour l’instant, je suis parti sur GTK+/C pour le GUI.
Précision: Je ne suis pas développeur. A travers ce projet, je suis aussi en train de me constituer un mini-tutoriel sur mesure. Je commente beaucoup mon code et j’ai donc besoin de comprendre ce que j’écris. Les solutions clés en main ne me branchent pas trop.

Pour Qt, il appartient à Nokia. Qu’est ce qu’il pourrait se passer si un jour Nokia décide de le privatiser, de lâcher la double licence?
Pour GTK+, les devs n’ont pas l’air très ouverts et le projet à l’air collé à Gnome. D’après la doc, GTK+3 amène sont lot de changements. En bien ou en mal?
Dans les 2 cas, le coté “tributaire” m’inquiète un peu.

J’ai essayé Anjuta, c’est trop pour ce que je veux faire. Je préfére rajouter des outils au fur et à mesure de mes besoins. Pour l’instant, vim, terminal, Makefile.
Je connaissais Glade. C’est chouette pour faire un premier design de l’appli. Comme je suis pas très fan du .xml à coté du binaire, je pensais écrire l’interface directement avec les fonctions GTK. Il suffit de se servir du .xml pour voir quel widget utiliser et avec quelles options.

Mon programme consiste en gros à écrire dans un tableur + quelques opérations. Je pourrais écrire ces opérations directement dans les fonctions qui gèrent les signaux mais je préfére séparer clairement l’interface et le coeur.
Ca devrait permettre une plus grande liberté dans le toolkit et le langage pour le GUI. On peut mettre le gui à jour sans se prendre la tête avec la librairie.
L’idée serait de compiler le coeur déjà écrit en C sous forme de librairie. La partie GUI n’aurait plus qu’à faire l’intermédiaire en le contenu des widgets et les fonctions de la librairie.

Ça n’appartient plus à Nokia, ça a été revendu à Digia il n’y a pas très longtemps. Mais ça ne change rien : s’ils décident de le “privatiser” ça ne sera pas rétroactif, ils ne pourront pas empêcher les forks à partir de la dernière version “double licence” existante.
Et ils perdront énormément de clients commerciaux qui se dirigeront vers la version libre pour rester compatible avec le reste. Bref, ça serait du suicide.

en rapport avec le sujet, intéressant à lire

linuxfr.org/news/gcompris-change-de-moteur

[quote=“agentsteel”]en rapport avec le sujet, intéressant à lire

linuxfr.org/news/gcompris-change-de-moteur[/quote]
Bon ça va, j’ai compris…
Je vais tenter ma chance avec Qt.
Dommage le style de Gtk+/C comencait à me convenir.
Je n’ai toujours pas bien compris ce qu’était “l’orienté objet” d’ailleurs à part que c’est blindé de structures (objets + méthodes).
Ce que j’ai compris pour l’instant, c’est que en C on pense un TYPE (généralement une structure ex: GtkGrid) et toutes ses fonctions (gtk_grid_new etc…). En C++, ça sera une structures contenant le TYPE et les méthodes.
Ca donnera quelque chose comme grid.new() au lieu de grid = gtk_grid_new()?
Bon, je vais me mettre au C++ et tester Qt.

Bref pour revenir au sujet initial, il y a quelquechose que je cherche à faire depuis 2 semaines.
Je voudrais modifier mon GUI pendant le runtime. Par exemple, rajouter une ligne à une grille en cliquant sur un bouton et afficher la nouvelle ligne.
C’est faisable en Qt? En GTK, je trouve rien.

[quote=“Funkygoby”]Je vais tenter ma chance avec Qt.
Dommage le style de Gtk+/C comencait à me convenir.
Je n’ai toujours pas bien compris ce qu’était “l’orienté objet” d’ailleurs à part que c’est blindé de structures (objets + méthodes).
Ce que j’ai compris pour l’instant, c’est que en C on pense un TYPE (généralement une structure ex: GtkGrid) et toutes ses fonctions (gtk_grid_new etc…). En C++, ça sera une structures contenant le TYPE et les méthodes.
Ca donnera quelque chose comme grid.new() au lieu de grid = gtk_grid_new()?
Bon, je vais me mettre au C++ et tester Qt.[/quote]
Les deux sont orientés objet. L’un crée sa propre couche objet au dessus d’un langage qui ne possède pas ce concept de base et l’autre utilise de manière minimal le C++ parce qu’il est arrivé à une époque où le C++ avait des problème dans sa bibliothèque standard.
Les concepts ne changent pas particulièrement.

Dans un langage objet (orienté classe), tu définis des classes qui se manipulent à peut près comme des structures. Les classes contiennent à la fois des données (des variables) et de la logique (des méthodes). Un objet est une instance de classe, comme ton ordinateur est une instance particulière d’ordinateur : on peut lui faire faire la même chose que n’importe quel ordinateur, mais il est tout de même unique. Là c’est pareil, chaque objet possède ses propres variables, mais tu peut appeler la même méthode sur n’importe quel objet de cette classe.

Voila pour la version ultra basique qui ne parle pas de l’héritage, du polymorphisme et de l’encapsulation (et qui se concentre sur de l’orienté classe).

[quote=“Funkygoby”]Je voudrais modifier mon GUI pendant le runtime. Par exemple, rajouter une ligne à une grille en cliquant sur un bouton et afficher la nouvelle ligne.
C’est faisable en Qt? En GTK, je trouve rien.[/quote]
C’est faisable avec n’importe le quel des 2.

Bonjour,

Pour information : Wireshark passe de GTK+ à QT… l’argumentaire tourne surtout autour de “l’homogénéité de l’application sur toutes les plateformes”.

Perso j’ai démarré un projet aussi sauf que j’utilise le langage Vala et donc GTK+ (eh oui Vala utilise comme base des objets “GObject” alors que QT utilise “QObject” qui sont incompatibles). Vala est orienté objet mais il “compile” les fichiers sources pour créer des fichiers “C” ensuite compilés par GCC. C’est sympa mais parfois je me dis que j’aurais bien aimé voir ce que cela donnerait sur Qt…

Petite précision, GTK+ est écrit en C, il n’est donc pas “objet” pour autant il utilise le paradigme de la programmation orientée objet (comme c’est bien dit… sur wikipedia). En gros cela signifie qu’il propose des fonctions pour “créer des objets” et pour “gérer des objets” mais sans utiliser de “notion de classe”. De fait, il existe des “bindings” de librairies proposant des classes regroupant les prototypes d’objets.

Bref, outre le fait de statuer sur l’API graphique, tu peux aussi t’interroger sur le choix du langage :slightly_smiling: (Vala, Go, C, C++, Python, …)

Bon courage.

Salut,
j’ai testé un peu de Qt.
L’obstacle de Qt a été le C++ que je n’arrive décidement pas à saisir. Les concepts ne me sont plus étrangers puisque mon projet m’a poussé progressivement à faire de l’OO, sans parler de GTK qui fait de l’OO sauce C.
Mon problème avec le C++ est sa syntaxe que je ne trouve pas intuitive.

J’apprends énormèment en programmant en C. Ma vision des passages d’arguments, des accés mémoires s’est sérieusement étoffée. C’était le but premier du projet d’ailleurs.
Je sais qu’il y a python ou plein d’autres languages plus abordables que C/C++ mais je voulais précisément comprendre ce que je faisais.

J’ai donc écrit mon GUI avec GTK+/C. Je suis parti d’un exemple minimaliste trouvé sur le net et je me suis servi du manuel de référence pour construire dessus.

Maintenant, j’entends bien que Qt est en train de prendre le pas sur GTK. Sur des systèmes embarqués, c’est flagrant.
Pour celui qui (contrairement à moi) n’a pas de contrainte linguistiques, Qt est definitivement le Toolkit à choisir.
C’est l aprochaine grande étape… se mettre sérieusement au C++ puis Qt.
Ayant bien disoccié ma partie centrale du GUI, je peux facilement rajouter une partie GUI/Qt en plus de la ligne de commande et de GTK+ déjà existant.

Merci à tous pour vos contributions. Je ne résoud pas le fil puisqu’il s’agit d’un discussion ouverte.

@Funkygoby > Tu fais ce que tu veux, hein, mais j’ai l’impression que tu n’a pas une bonne approche. Qu’est ce que tu cherche à faire ?

Apprendre le C ?
Apprendre le fonctionnement du système ? (oui c’est différent du C)
Apprendre à faire une interface graphique ?

Pour des objectifs différents, il vaut mieux faire des choses différentes. Faire une interface graphique est quelque chose de très haut niveau alors que pour le système tu dois être d’un niveau relativement bas.

Bien sûr tu fais ce que tu veux, mais d’une part tu va être confronté à beaucoup de problématiques différentes en même temps et au final tu risque d’être frustré.

Aujourd’hui faire des interfaces non-déclaratives, c’est vraiment vraiment vraiment vraiment vraiment vraiment vraiment vraiment dommage. Donc ce qui peut être intéressant c’est de faire du C/EFL (edje…), du C/Gtk/Glade ou du C/Gtk/GtkBuilder.

Embryon comparé à vous tous, je n’ai bricolé qu’un peu de gtk en C, surtout en python, puis ensuite un peu de wxwidget qui me semblait plus “portable”.

Mon vocabulaire n’est pas adapté, mais il y a un truc que j’ai retenu finalement de mes essais en autodidactes, que m’a rappelé récemment Misterfreez : peu importe l’interface, l’idéal est lorsque le programme peut fonctionner sans.

Sur le principe, ça me fait penser au système serveur/client. Le programme de base est sous forme de “serveur”, il attend qu’on lui dise quoi faire. L’interface (ligne de commande ou graphique) envoie les ordres au programme. Résultat, ça marche toujours et c’est en fait plus simple à gérer.

Tout à fait et nombre de logiciel ont un cœur écris dans un langage type C/C++/Fortran/ADA/… et une interface dans un langage de très haut niveau comme python ou plus récemment javascript. Le cœur expose une API (un ensemble de fonctions) et tu crée une interface qui utilise cette API.

@Misterfreez: Ce que je cherche à faire: écrire un programme bien pensé (je ne veux pas un tas de boue qui marche) avec un GUI. L’écriture de ce programme a un but pédagogique. Ce dernier point est important si tu veux espérer comprendre ma démarche:
"-Mais pourquoi tu fais ça comme ça?
-Pour apprendre (la programmation)."

Ce que fait ce programme doit surement pouvoir être fait sous un tableur avec des formules excel.

Pour le coeur du programme, j’ai choisi C.
Le C a été mon language à la fac pour faire du calcul scientifique. Dans ce domaine, ça roule.
Mon projet avait pour but de creuser des domaines que j’avais jusqu’à présent survolés: les pointeurs, la mémoire.
J’ai bien galéré mais ces notions sont maintenant claires et elles me semblent fondamentales (la pile, le tas, l’interêt d’un constructeur/destructeur si on manipule des structures).
Je me suis retrouvé malgré moi à faire de l’orienté objet en C à cause de mes structures. Ca tombe bien, sans ça GTK+ (ou même Qt) m’aurait paru très mystérieux.

Pour le GUI, j’ai essayé glade… longtemps… C’était pas clair. D’ailleurs, libglade n’est plus d’actualité. Il faut passer par gtkbuilder en éditant sont .xml.
De toute façon, un fichier .xml décrivant l’interface ne m’intéresse pas (pour l’instant). Je rappelle que je cherche à apprendre et comprendre les outils,ici gtk+. Le fait de déclarer directement des GtkWidget* et d’appeler des méthodes dans un .c, ça me parle. C’est ma manière d’apprendre. Si je ne maîtrise pas suffisament les outils, ça me frustre.
D’ailleurs comment faire une interface dynamique avec glade? Il fallait de toute façon que je mette les mains dans du code GTK+…
Maintenant que j’ai à peu près pigé GTK+, je veux bien utiliser Glade, je ne me sentirai pas frustré.

Je développe un peu sur le choix de GTK+, c’est purement est simplement dû au fait que je ne voulais pas me taper un nouveau language (python pour faire du Qt par exemple) aussi simple soit il. Comme GTK+ a des bindings C de base, j’étais à l’aise au moins avec la syntaxe et la logique OO en C.

Quand je me suis lancé là dedans, j’avais tout à fait conscience de mon niveau et j’avais bien compris que je faisais pas le meilleur choix de language. Bilan: parfois, c’était bien galère mais je crois que la tempête est passée. Ca cross-compile, y a pas de seg-fault à l’horizon et valgrind me donne un bilan similaire à celui de vlc. A part cette histoire de lenteur d’affichage qu’il faut que je règle, tout le reste, c’est du gateau.
Python, Glade ou Qt Designer m’aurait surement fait gagner pas mal de temps mais est ce que j’aurais compris autant de choses?
Chez moi, la frustration a tendance à venir quand on me donne une recette que je ne comprends pas.
En fait, je suis le gamin qui a besoin de se cramer le doigt sur la bougie pour comprendre. D’ailleurs, j’ai toujours pas arreté…

Je dis peut-être une bêtise, mais pourquoi ne pas passer par la librairie SDL?

Pas beaucoup de code, possibilité de crée une interface, donc gui, agréable et épuré.

Vu que je travaille avec pour certains projets, je pense que ça peut-être utile.

C’est une proposition.

SDL me semble plus orienté pour du multimedia ou des jeux. J’ai bon?
Ca me semble aussi trop bas niveau. Il faut récupèrer les clic souris, les entrées clavier…

Pour moi un GUI (Graphic User Interface), c’est une fenetre contenant des éléments standards (menu, boutons, …). Le tout, intégré à l’environnement de bureau utilisé gràce à la gestion des thèmes. Pour ça GTK+ et Qt sont très bien.

Si tu as des exemples de GUI fait avec SDL, je veux bien voir à qui ça ressemble.

[quote=“Funkygoby”]SDL me semble plus orienté pour du multimedia ou des jeux. J’ai bon?
Ca me semble aussi trop bas niveau. Il faut récupèrer les clic souris, les entrées clavier…

Pour moi un GUI (Graphic User Interface), c’est une fenetre contenant des éléments standards (menu, boutons, …). Le tout, intégré à l’environnement de bureau utilisé gràce à la gestion des thèmes. Pour ça GTK+ et Qt sont très bien.

Si tu as des exemples de GUI fait avec SDL, je veux bien voir à qui ça ressemble.[/quote]

Si je me trompes pas:
Il y a une étape de différence entre sdl et qt:

  • qt, les boutons, menu sont déjà préparer, te reste à les utiliser dans ton code
  • sdl, il n’y en a pas, faut coder soit même les boutons, menu, puis les utilises

Si je me trompes encore pas:
Via sdl il te faudra:

  • faire des lignes, courbes, une taille pour dessiner un bouton (en gros faire un rectangle)
  • positionner (x-y) le bouton dans la fenêtre
  • design le bouton en couleur ou en image: en état défaut, état souris dessus, état cliquer (s’ils te sont nécessaire bien entendu)
  • calculer la souris: faire les actions nécessaire si la position de la souris est sur la position du bouton, en mode clique ou pas, etc.

Il y a aussi sfml en c++ (mais binding sur d’autres langage aussi) qui fait un peu pareil que sdl, pour les deux tu peux, tu pourras peut-être trouver des trucs prêt que d’autres on fait.

Voici un exemple (d’un gui sfml mais pourrait être fait pareil avec sdl): sfgui.sfml-dev.de/
L’idée est fun faut l’avouer, faut tous calculer.