Discussion :

[troumad]

Bonjour

J'ai un problème sur pluieurs fenêtres du style :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 GtkWidget * win;
  GtkFileFilter * filtre= gtk_file_filter_new();
  char * nom_de_fichier;
  struct_groupe * gr_tmp;
 
  win = gtk_file_chooser_dialog_new ("Ouvrir un groupe de personnages", NULL,
                                          GTK_FILE_CHOOSER_ACTION_OPEN,
                                          GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
                                          GTK_STOCK_OPEN, GTK_RESPONSE_YES,
                                          NULL);
 
 gtk_file_filter_add_pattern (filtre,"*.pers");
 gtk_file_chooser_set_filter(GTK_FILE_CHOOSER(win),filtre);
 if (gtk_dialog_run (GTK_DIALOG (win))==GTK_RESPONSE_CANCEL)
 {
    gtk_widget_destroy (win);
    return;
 }

Je ne vois pas pourquoi ce problème viendrait de moi ! J'ouvre une destination et j'affiche tous les fichiers correspondant au filtre. Si je modifie par un autre moyen (vi ou cp par exemple) un des fichiers affichés, mon programme plante (sortie du programme) avec dans la fenêtre shell le mesage suivant :

Code :

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

Gtk:ERROR:gtkfilesystemmodel.c:746:gtk_file_system_model_sort: assertion failed: (r == n_visible_rows)

D'où ceci peut bien venir ?

[teuf13]

Ca ressemble à https://bugzilla.redhat.com/show_bug.cgi?id=603781

[troumad]

J'avoue ne pas saisir quand ça plante sur ces rapports de bug !

[teuf13]

C'est malheureusement un rapport de bug sans solution

[0xpoint]

Regardez cette information

http://gitorious.org/mypaint/mypaint...dfe8620be23db0

[liberforce]

Bien vu ! Il semble effectivement qu'il suffise, pour contourner le bug, de détruire le filechooserdialog après chaque usage. Le code suivant remplacerait l'exemple donné à partir de l'appel à gtk_dialog_run

Code :

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

1
2
3
4
5
6
7
 
 if (gtk_dialog_run (GTK_DIALOG (win))==GTK_RESPONSE_YES)
 {
    /* action à exécuter sur le fichier choisi par l'utilisateur */
 }
 
 gtk_widget_destroy (win);

[troumad]

Je détruis bien la fenêtre après chaque usage ! Après le if, il y a un else dans lequel je fais la destruction aussi.

[liberforce]

Si tu ne mets pas toutes les portions intéressantes, c'est difficile de trancher...
Mais dans fichier.c tu fais plusieurs appels à gtk_dialog_run les uns à la suite des autres...

Au passage, j'ai mis hier soir ton application sur github pour pouvoir travailler sur des améliorations de lisibilité. Je sais que tu n'es pas chaud pour les systèmes de gestion de version, mais ce sera beaucoup plus simple pour moi pour te montrer les simplifications sur la base de code dont je t'avais parlé (exemple de patch pour la compilation via CMake). En revanche je vois que tu fais quand même pas mal de modifications de ton côté, et je ne sais pas encore comment gérer cela pour les importer pour l'instant mais bon... Le but c'est aussi pour moi d'apprendre un peu plus à utiliser git.

Le code est disponible sur https://github.com/liberforce/gtk-roleplay

[troumad]

Il va falloir que je regarde plus https://github.com/liberforce/gtk-roleplay ! Je m'inscris... Nouveau compte Troumad !
Mais en ce moment, je corrige des copies

Je note la présence d'un fichier inutile : mago.c.

[troumad]

fichier.c[/URL] tu fais plusieurs appels à gtk_dialog_run les uns à la suite des autres...

Ligne 284 gtk_dialog_run avec gtk_widget_destroy ligne 287 et gtk_dialog_run
à nouveau ligne 293 avec gtk_widget_destroy 297 ou 300
à nouveau ligne 383 avec le destroy l 384
à nouveau ligne 390 avec destroy ligne 393 ou 397
à nouveau ligne 1448 avec destroy ligne 1451 ou 1493
à nouveau ligne 1458 avec le destroy à la ligne 1459
à nouveau ligne 1483 avec le destroy ligne 1484

Ça me semble correct !

[liberforce]

Arf, j'ai raté le gtk_widget_destroy de la ligne 287...

[teuf13]

Sinon un bug similaire a fait son apparition sur la mailing list gtk+ ces derniers jours https://mail.gnome.org/archives/gtk-.../msg00101.html

[troumad]

Si c'est un bug, il faudra que je teste sur un autre système...

[troumad]

Test fait sous Windows => pas de plantage.
Il faudrait que je teste sous une autre version de windows. Il faudrait que je teste une autre version de Linux.
Mais, là, je corrige des copies

[teuf13]

En revanche je vois que tu fais quand même pas mal de modifications de ton côté, et je ne sais pas encore comment gérer cela pour les importer pour l'instant mais bon... Le but c'est aussi pour moi d'apprendre un peu plus à utiliser git.

Si tu récupères le code sous forme de tarballs, tu dois pouvoir avoir une branche "upstream" qui mirrore juste le contenu des tarballs que te file troumad. Quand il y a des nouveautés, tu décompactes la tarball de troumad dans ta branche upstream, tu commit avec git commit -a. Ensuite tu reviens sur ta branche de travail, et soit tu fais un git merge, soit tu fais un git rebase upstream

[troumad]

Le code est disponible soit à partir de mon site, soit à partir d'un forum dédié au jeu de rôle. Tu peux le récupérer toi aussi si tu veux (mais il y a plus de 10000 lignes à regarder ) , c'est sur http://troumad.org/OOo/perso.zip

Je n'ai plus ce problème. À croire que c'était un bug de gtk...

nb pour liberforce : le code a subit une grosse modification, il y a un fichier de plus (envp.c) depuis la semaine dernière.

[liberforce]

Si tu récupères le code sous forme de tarballs, tu dois pouvoir avoir une branche "upstream" qui mirrore juste le contenu des tarballs que te file troumad. Quand il y a des nouveautés, tu décompactes la tarball de troumad dans ta branche upstream, tu commit avec git commit -a. Ensuite tu reviens sur ta branche de travail, et soit tu fais un git merge, soit tu fais un git rebase upstream

Super, merci pour le workflow . Faut dire que la journée je fais plutôt de l'intégration SVN, j'ai pas encore trop l'habitude de git. J'ai créé ma branche, extrait le tarball, et fait un merge dans master. En revanche je suis surpris que ma branche upstream n'ait pas été remontée par mon git push suivant. Elle est locale par défaut ?

Ah, et félicitations pour ton nouveau job chez RH .

[liberforce]

nb pour liberforce : le code a subit une grosse modification, il y a un fichier de plus (envp.c) depuis la semaine dernière.

C'est réintégré sur https://github.com/liberforce/gtk-roleplay . Bon, en revanche, j'ai pas franchement le temps de faire grand chose pour l'instant, pas mal de boulot à côté... Je n'ai fait que mettre à jour mon environnement de compilation basé sur CMake.

[teuf13]

En revanche je suis surpris que ma branche upstream n'ait pas été remontée par mon git push suivant. Elle est locale par défaut ?

Je ne suis pas sûr d'avoir bien compris ta question. Si tu fais "git push" sans paramètre, par défaut ça ne doit pousser que la branche courante (?). Je fais toujours des "git push remotename branchname" comme ça je sais exactement ce qu'il se passe

Ah, et félicitations pour ton nouveau job chez RH .

Merci!

[teuf13]

Sinon un bug similaire a fait son apparition sur la mailing list gtk+ ces derniers jours https://mail.gnome.org/archives/gtk-.../msg00101.html

Et il devrait être corrigé dans gtk 2.24.4 : https://mail.gnome.org/archives/gtk-.../msg00003.html

"* Thread-safety fixes in file chooser and app chooser code"