Discussion :

[troumad]

Bonjour

Ça fait un moment que je me pose la question, que j'ai des doutes, mais depuis que j'ai intégré l'astuce proposée ici : http://www.developpez.net/forums/d13...blant-tableur/ , il n'y a plus de doute.

Je ne comprends pas les paramètres des fonctions callbacks.
Pourquoi parfois, on de telles différences ? Voici trois exemples de propototype :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void bord (GtkWidget *ChildWidget, cairo_t *cr);
void GPL (GtkMenuItem *menuitem, struct widgets * _widgets);
void sphere_nouv(GtkWidget *wid, gpointer param);
void print_intelligence(GtkRadioAction *action, GtkRadioAction *current, gpointer param);

Je veux biebn que le premier paramètre soit le paramètre de l'item qu ia généré l'appel. J'aurais dit que le dernier était celui défini par l"utilisateur
En C avec une de ces deux lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
gtk_action_group_add_radio_actions (p_actionGroup, i_radio_entries ,  G_N_ELEMENTS (i_radio_entries), 2, (GCallback)print_intelligence, (gpointer) param);
gtk_builder_connect_signals(widgets.builder, &widgets);

Ou dans le fichier glade avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<signal name="activate" handler="GPL" swapped="no"/>

Le problème, c'est que ce n'est pas le cas avec le premier exemple et que parfois, on a trois paramètres... D'où viennent ces différences ?

[diesel83]

Bonjour,

Dans une fonction de callback, on a autant de paramètres que l'on veut (ou presque).

Dans le désordre :

Le premier paramètre est un pointeur sur l'objet qui génère le signal,
Le dernier est un pointeur permanent sur un bloc de données. Ce pointeur est attaché au moment ou le signal est attaché à la fonction de callback (ou l'inverse ? ; la fonction de callback attachée au signal),
Les autres (ceux du milieu) sont définis lors de la déclaration du signal auprès du framework g_object par la fonction xxxx_init_class de l'objet qui produit le signal.

Jean-Marie

[troumad]

Où peut-on avoir des explications ou des exemples ? Ceci est intéressant !

[diesel83]

Vas voir le sujet "Régler une valeur numérique dans un label à l'aide d'un curseur popup" un peu plus bas.

En page 2, dans le listing du fichier scaledvalue.c tu trouveras en ligne 186 l'appel de la fonction g_signal_new.

Le dernier paramètre est 0. Si j'avais voulu y ajouter des données, cela aurait pu être par exemple ...G_TYPE_NONE, 1, value).

La déclaration de la fonction de callback associée aurait alors été par exemple : cd_scaledvalue_value_changed (ScaledValue *scaledvalue, guint value, gpointer data)

Jean-Marie

[troumad]

Ces astuces ne sont pas réglables avec glade ?

[diesel83]

Je ne sais pas, je n'utilise pas glade.

Cependant, là on est dans du code de création de widgets. Je ne suis pas sûr que glade serve à grand chose.

Jean-Marie

[troumad]

Si, glade peut construire le widget.

C'est la première fois que j'essaie qu'on me conseille depuis longtemps (surtout gerald3d il me semble). Je nettoie un ancien programme gtk que je convertis sans utilisé des fonctions pérémées et que j'essaie d'améliorer. J'avoue que la construction de fenêtre est plis facile avec glade : beaucoup moins de lignes de code. En plus, il est assez facile de rajouter/modifer des éléments.
Et juste un appel glade peut être traité avec comme paramètre (GtkWidget *ChildWidget, cairo_t *cr). C'est suite à l'exemple de bordure que j'ai vu qu'on pouvait mettre des paramètres originaux dans un appel. Si je pouvais avoir une liste de paramètres utilisables et de leurs propriétés. Je crois que je verrai plein de portes s'ouvrir.

[diesel83]

Je maintiens ma réponse :

Le premier paramètre de la fonction de callback est un pointeur sur l'objet qui génère le signal,
Le dernier est un pointeur sur un éventuel bloc de données déclaré par la fonction qui attache la fonction de callback au signal,
Tous les autres sont fixés par l'objet qui produit le signal (appel à la fonction g_signal_new).

A mon sens, la définition des paramètres qui sont dans la fonction de callback (à part peut-être le dernier) est faite dans le code du widget qui génère le signal et je ne pense vraiment pas qu'on puisse y changer quelque chose avec glade.

Par contre, qu'avec glade on puisse faire les déclarations de la fonction de callback, probablement, mais c'est une autre question.

Jean-Marie

[pvincent]

Bonjour,
Il me semble que votre discussion ne distingue pas très clairement la création d'une nouvelle classe de widgets de l'utilisation d'un widget d'une classe donnée.

La signature (i.e. les arguments) d'un callback est fixée quand on crée une classe de widgets et les signaux correspondants sont définis avec la fonction g_signal_new().
Comme l'indique la doc de cette dernière (https://developer.gnome.org/gobject/...l#g-signal-new), le nombre de paramètres et leur type est laissé au choix de l'auteur du widget. Je trouve que les auteurs de GTK ont employé un schéma assez uniforme, car le plus souvent on a deux arguments (pointeur sur le widget ,pointeur sur les données utilisateur)
C'est quand le callback peut utiliser d'autres paramètres qu'ils ont utilisé un schéma différent.

Dans l'exemple tableur que tu cite, le signal "draw", défini pour la classe GtkWidget, est utilisé pour déclencher le callback utilisé (la doc est ici: https://developer.gnome.org/gtk3/sta...GtkWidget-draw) et il semble normal, dans GTK3 qui a viré presque entièrement GDK au profit de Cairo, de passer en argument, en plus du pointeur sur les données utilisateur, le CairoContext qui sert précisément à tracer avec Cairo.

Conclusion: l'auteur du widget choisi de transmettre les arguments qui lui semblent utiles pour l'usager.

Je n'utilise pas Glade, mais il me semble peu probable qu'il permette de définir de nouvelles classes de widgets et, pour les classes existantes, l'utilisateur doit se conformer aux spécifications choisies pas l'auteur de la classe.

[troumad]

J'aime bien ta réponse.
Si dans l'exemple précédent, il y a un paramètre cairo, c'est que l’événement qui génère le signal a un rapport avec cairo. Encore faut-il penser que draw à un rapport avec cairo : il faut savoir ce que fait cairo. Je ne le savais pas.

Je n'aime pas ta réponse.
J'espérais qu'il suffise que je mette un champ "cairo * car" dans le prototype d'un callback pour pouvoir modifier l'affichage de l'item appelant. Visiblement, ce n'est pas le cas

Donc, les possibilité sont limités, il suffit juste de les connaître. GTK semble un machin énorme qu'il faudrait complètement maîtriser avant de faire deux lignes de code...

La fonction g-signal-new peut peut-être ouvrir de nouvelles options, mais il y a trop d'anglais dans cette page. Un peu, ça va, trop, bonjour les déjà, je ne comprends plus. Mon anglophobie prend le dessus.
Je dis souvent à mes étudiants que si j'avais su, j'aurais travaillé l'anglais. Maintenant, ça me fait trop peur... Même en chant choral, quand on essaie de me faire chanter de l'anglais, ça me plante.

[diesel83]

...Donc, les possibilité sont limités, il suffit juste de les connaître. GTK semble un machin énorme qu'il faudrait complètement maîtriser avant de faire deux lignes de code...

Ben..., non.

Il est tout à fait logique que ce soit le widget émetteur d'un signal qui décide de ce qui doit être envoyé comme données avec celui-ci (c'est lui qui sait vraiment à quoi ça sert). De toutes manières, il est impossible de concevoir le code d'un widget pour tenir compte de tous les desiderata possibles de toutes les fonctions de callback qui voudraient s'abonner à l'un de ses signaux si on laissait au développeurs de celles-ci la liberté de mettre ce qu'ils veulent dans les paramètres d'appel.

GTK+ a en plus bien prévu le coup puisqu'il te reste le pointeur sur le bloc de données en dernier paramètre pour y ajouter ce que tu veux au moment où tu attaches la fonction de callback au signal..

Jean-Marie

[troumad]

Il va falloir que je fasse des tests.

Pour moi, le dernier pointeur était surtout utilisé pour transmettre des informations sur l'environnement de la fenêtre appelante comme des paramètres internes.

[troumad]

Les tests continuent. je vois que certains callbacks demandent des formats particuliers pour les fonctions. je comprends même certaines fonctions qu'on ma'avait données que j'arrive à refaire moi-même.

[troumad]

Je viens enfin de voir où on trouve les paramètres des fonctions callback associées aux signaux.
Par exemple, le signal "draw" qui est généré par des GtkWidget se trouve définis dans la page associée aux GtkWidget :
https://developer.gnome.org/gtk3/stable/GtkWidget.html

Sur cette page, on peut voir la liste des signaux généré par les GtkWidgets en cliquant sur signals en haut à droite. En cliquant ensuite sur le signal qui nous intéresse, on arrive au prototype de la fonction callback qui lui est associé. Dans le cas de draw, c'est ici :
https://developer.gnome.org/gtk3/sta...GtkWidget-draw