Discussion :

[chrtophe]

Bonjour,

En utilisant le langage C, on ne peut accéder directement aux propriétés ou méthodes d'un objet GTK, car en C on est pas en gestion objet. Pour cela on utilise les fonctions C fournies par Gtk qui en interne fonctionnent en gestion objet, ces fonctions étant l'interface avec gtk.

Plus exactement, le langage C n'est pas "orienté object" comme l'est le C++ ou le Java. Pour palier à ce manque, GObject a été développé. C'est une interface C pour la gestion objet. La classe de base de GtkWidget et tous les widgets c'est GObject, tu peux le voir sur le diagramme de classe de chaque objet.

On peut accéder aux propriétés des objets GTK en C++ ou les modifier en utilisant Gtkmm et en compilant avec g++ au lieu de gcc. Gtkmm étant alors une surcouche de dialogue avec gtk.

En fait il existe des "bindings" (des "ponts") qui permettent d'utiliser les bibliothèques GTK à partir d'autres langages que le C. Voici la liste des bindings permettant d'utiliser GTK. GTKmm est le nom des bindings pour le C++.

Au niveau C, on passe en paramètres aux fonctions Gtk un ou plusieurs pointeurs, ceux-ci contenant une ou des structures utilisées par la bibliothèque GTK. Les éléments de ces structures ne me sont pas accessible en C.

Tu fais la confusion entre GTK et C. GTK est une API, une interface de programmation. C est un langage de programmation. Ce n'est pas la même chose. Les éléments de tes structures sont accessibles en C en passant par les fonctions de GTK. Mais comme toujours en C, il est aussi possible de bidouiller et d'accéder aux structures de donnée manuellement, mais cela n'a pas grand intérêt ici, car tu finirais pas refaire ce que fait déjà GTK.

Mes difficultés rencontrés ( en dehors d'un manque d'expérience bien entendu ) résident du fait que :

- Je ne trouve pas la fonction Gtk effectuant ce que je veux faire.

Lis (au moins succinctement) la doc, approfondis un peu plus au besoin. Il faut au moins que tu saches les classes qui existent, même si au début tu ne sais pas les utiliser. Cela t'évitera de réinventer la roue.

- Je n'est pas conscience de toutes les interactions
des objets

En général tu as pour chaque objet une description rapide de comment l'utiliser, dans la rubrique "Description", par exemple voici la description pour GtkDialog. Tu as un bandeau de navigation en en-tête des pages de doc pour accéder à ces sections plus rapidement.

- Les bizarreries que je rencontre et pour lesquelles je ne trouve pas de solutions sont du au fait que je ne sais pas ce que je peux faire ou pas faire exactement, la documentation ne précisant pas forcément "si je ne fais pas comme ça,résultat aléatoire et/ou erroné ", à savoir que si la doc suppose un minimum de connaissance cela est sous entendu : en tout cas pas pour moi.

La doc suppose que tu l'aies parcourue pour voir les fonctions à ta disposition. Bien souvent les noms de fonctions sont suffisemment évocateurs pour t'indiquer ce qu'elle font, la doc t'en dit plus, et les messages de warning/erreurs te permettent de comprendre ce qui manque.

- je ne "respectes pas les règles " sans forcément en avoir conscience.

Dans certains cas un peu plus complexes, il faut effectivement chercher des tutoriels, ou des exemples concrets d'utilisation avec des moteurs de recherche de code comme koders.com ou google codesearch.

J'essaye de bien comprendre avec les tutoriaux, mais dès que je sors du cas standard, je bloque.

Il peut être intéressant parfois de se rapporter au code source de GTK ou d'applications codées en GTK. Je sais en tout cas que lire des portions du code de GTK et de la GLib m'a été grandement bénéfique, que ce soit en style ou conception objet ou juste pour choisir un nom compréhensible à pour une fonction.
Le code de GTK, de la GLib et des plein d'applications basées sur GTK:
http://git.gnome.org/browse/

La documentation n'est pas forcément adaptée aux débutants. exemple la doc décrivant le fonctionnement de gtk_toolbar_insert_stock dit de ne plus l'utiliser au profit de gtk_toolbar_insert mais comment faire pour utiliser l'un à la place de l'autre : démerdes-toi. Du coup, avec la fonction gtk_toolbar_insert à la place de gtk_toolbar_insert_stock faut il ajouter les icônes à la main, et dans ce que il s'agit d'un retour en arrière, quel est l'intérêt d'avoir une bibliothèque si il faut faire les choses à la main ? là vu que ça me parait aberrant, je pense que j'ai compris de travers.

Peut-être aussi n'as tu pas compris la logique de la doc ? Dans ton exemple précis, je n'ai jamais utilisé ces fonctions. Sur la doc de gtk_toolbar_insert_stock je vois que la fonction est dépréciée. On m'indique qu'il faut utiliser gtk_toolbar_insert à la place. Je regarde donc la documentation de cette fonction. Là je vois qu'elle demande un GtkToolItem, et qu'on est passé de 7 arguments avec l'ancienne fonction à 3 avec la nouvelle, ce qui simplifie l'API et la rend plus facilement mémorisable. Ensuite j'essaie de savoir comment utiliser GtkToolItem. Pour cela je regarde la section "description" qui m'apprend que pour items contenant des boutons, je dois regarder GtkToolButton, GtkToggleToolButton et GtkRadioToolButton. Un toggle button, c'est pour un bouton à deux états (actif/inactf). Un radion button, c'est un bouton radio avec des choix à sélectionner. Ce que tu veux c'est un stock button, un bouton prédéfini, donc tu t'orientes vers GtkToolButton. Et oh ! Magie ! La 2ème fonction de cet objet s'appelle gtk_tool_button_new_from_stock. Donc au lieux de créer le GtkToolButton et l'ajouter dans la toolbar en un seul appel avec 7 paramètres, on le fait avec deux fonctions qui ont moins de paramètres. En bonus, on a simplifié le code de GtkToolbar, qui s'occupait de choses qui ne le concernait pas, mais concernait en fait les boutons que l'on insérait dans la toolbar. On a ainsi ouvert la possibilité de rajouter plusieurs types de boutons (normaux, toggle, radio) sans avoir à rajouter une nouvelle fonction dans GtkToolbar ou un paramètre supplémentaire à gtk_toolbar_insert_item (ce qui l'aurait encore alourdi, démontrant que l'API était mal fichue). Note que ce changement est intervenu il y a très longtemps, dans GTK 2.4, parque que justement les développeurs se sont rendus compte que l'API d'origine était mal fichue.

On se retrouve avec des tutoriaux faisant la même chose de façon différente exemple utilisation de G_CALLBACK dans un cas et utilisation de gtk_signal_func dans un autre quelles sont les implications de l'un ou de l'autre ?

Les tutoriaux sont écrits à un instant t. Forcément, à un instant t+1, il n'y a plus forcément 100% de correct. Ce qui se faisait d'une manière à une époque se fait sans doute différemment plus tard, tout simplement parce que l'informatique n'est pas statique, elle est en perpétuelle évolution. Un projet qui ne change plus du tout, c'est soit un projet qui a atteint 100% de son objectif initial (ce qui n'est vrai que pour des projets très simples), soit c'est un projet mort. Les développeurs de GTK font comme beaucoup d'autres projets: ils améliorent le code, et déprécient les anciennes fonctions qui ne correspondent plus à l'usage recommandé. Ces fonctions existent et fonctionnent toujours, mais seront retirées lors que prochain saut de version majeur. C'est ce qui est arrivé au passage à GTK 3: toutes les fonctions dépréciées de GTK 2 ont été supprimées.

Pour être sûr de ne pas utiliser de fonction dépréciées, il suffit de compiler avec les symboles GTK_DISABLE_DEPRECATED, G_DISABLE_DEPRECATED etc., ce qui est expliqué en page 3 de la documentation officielle !
http://developer.gnome.org/gtk/stabl...compiling.html

Désolé de t'importuner une fois de plus et merci pour ta réponse.

Tu ne m'importune pas, mais pense bien que répondre à un pavé pareil me prend énormément de temps, et que si vous êtes plusieurs à le faire, je ne pourrai tout bonnement pas suivre. Merci donc de ne PAS me contacter par message privé, mais d'ouvrir des discussions sur ces problèmes. En plus, cela peut intéresser d'autres personnes dans ton cas, et tu aurais sans doute eu des commentaires constructifs en provenance d'autres personnes du forum. Au pire tu peux attirer mon attention sur un fil de discussion en m'envoyant un lien, mais je suis suffisemment actif ici pour que cela ne soit pas nécessaire.

Un jour peut-être qu'à la place de poser des questions je donnerais des réponses ..

On a tous commencé comme ça... Dans les cercles où j'évolue j'ai souvent l'impression d'être celui qui en connait le moins, c'est pour te dire...

Bon courage

[liberforce]

Ah bah finalement tu as balancé ma réponse "brut de pomme"... J'espère que ça reste compréhensible...

[pvincent]

Il y a une remarque que j'ai en tête depuis un bon moment et je profite de ce post pour l'exposer.
Dans plus de la moitié des cas, je fais toujours les mêmes quatre opérations:

1. créer le widget,
2. l'attacher à un parent,
3. le rendre visible,
4. lui associer un "callback".

Avec GTK+ en C, il faut appeler quatre fonctions différentes pour cela. ce qui rend l'API puissante et souple, mais allonge sérieusement le nombre de lignes de code. Comme bien souvent, je n'ai pas besoin de toute cette souplesse, j'ai défini une surcouche de fonctions interfaces qui me simplifie la vie. Je pense que je suis loin d'être un cas isolé (je pense au "couteau suisse" que trouad a écrit pour le UI manager par exemple) et j'ai l'impression que nous devons être nombreux à utiliser la même démarche.

Ne serait-il pas utile de définir une surcouche "interface simplifiée" standardisée (avec doc simplifiée), pratique pour le débutant qui veut apprendre les rudiments comme pour le programmeur plus expérimenté quand il veut veut faire des choses simples?
Cette interface aurait le mérite d'être standard et d'éviter d'aller en ordre dispersé dans la même direction.

[liberforce]

Il y a une remarque que j'ai en tête depuis un bon moment et je profite de ce post pour l'exposer.
Dans plus de la moitié des cas, je fais toujours les mêmes quatre opérations:

1. créer le widget,
2. l'attacher à un parent,
3. le rendre visible,
4. lui associer un "callback".

Avec GTK+ en C, il faut appeler quatre fonctions différentes pour cela. ce qui rend l'API puissante et souple, mais allonge sérieusement le nombre de lignes de code. Comme bien souvent, je n'ai pas besoin de toute cette souplesse, j'ai défini une surcouche de fonctions interfaces qui me simplifie la vie. Je pense que je suis loin d'être un cas isolé (je pense au "couteau suisse" que trouad a écrit pour le UI manager par exemple) et j'ai l'impression que nous devons être nombreux à utiliser la même démarche.

Ne serait-il pas utile de définir une surcouche "interface simplifiée" standardisée (avec doc simplifiée), pratique pour le débutant qui veut apprendre les rudiments comme pour le programmeur plus expérimenté quand il veut veut faire des choses simples?
Cette interface aurait le mérite d'être standard et d'éviter d'aller en ordre dispersé dans la même direction.

Non, je ne pense pas... Déjà je ne vois pas pourquoi tu dois rendre chaque widget visible manuellement. gtk_widget_show_all fait le boulot à ta place, et un seul appel suffit à afficher toute l'arborescence de widgets.

Ensuite, entre avoir de nombreuses lignes de codes et de longues lignes de code, il vaut mieux le premier: cela permet de faire plus simplement des diff et voir plus facilement ce qui a changé dans un morceau de code. Ta surcouche finirait par consister en quelques fonctions avec 6 ou 7 paramètres, ce qui devient illisible (impossible de se rappeler dans quel ordre utiliser les paramètres sans avoir la doc sous les yeux).

Et pour finir, la création d'interface graphique en C... Cela ne devrait même plus exister ! GtkBuilder existe depuis un bon moment maintenant, libglade existait avant lui, et ces outils te permettent de dessiner ton interface graphique avec un outil comme glade, qui produit un fichier XML décrivant ton interface. Il ne te reste plus que l'étape 4 à faire dans le code: la connexion des signaux (tu peux la faire dans glade aussi, mais ce n'est pas conseillé).

Je vois plein de débutants créer leur interface à la main... Cela ne doit avoir qu'un but pédagogique. Si vous voulez être productifs, utilisez GtkBuilder. Le seul cas où on doit écrire du code pour créer des widgets, c'est quand on fait une interface dynamique, où une action peut entraîner l'apparition de nouveaux widgets sur la même fenêtre.

[gerald3d]

...Je vois plein de débutants créer leur interface à la main... Cela ne doit avoir qu'un but pédagogique. Si vous voulez être productifs, utilisez GtkBuilder. Le seul cas où on doit écrire du code pour créer des widgets, c'est quand on fait une interface dynamique, où une action peut entraîner l'apparition de nouveaux widgets sur la même fenêtre.

Tout à fait d'accord. +1