Discussion :

[troumad]

Bonjour

J'avais pensé faire une communication père-fils (un concept que j'essaie d'apprendre) sous GTK en laissant au fils l'adresse d'un GtkEntry afin qu'il puisse y écrire ce qu'il veut. Mais, ça ne marche pas !
L'adresse du GtkEntry est bien restée la même, mais le

Code :

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

gtk_entry_set_text(GTK_ENTRY(adresse_gtkentry),buffer);

ne marche pas : rien n'est écrit.
Il faudrait que le père puisse lancer une boucle non bloquante pour attendre l'information venant du fils. Ul petit programme parallèle... Mais pas un fils car le problème resterait le même !

Je me dis que si je peux éviter carrément la notion de fils et faire directement une boucle d'attente non bloquante en parallèle avec le programme comme on lance des fenêtres, ce serait aussi bien !

Je regarde gtksocket, mais mon niveau d'anglais me permet juste de comprendre que ça pourrait être utile. Pas de l'utiliser

[troumad]

Je reviens un peu sur le problème...

Dans une fonction, je n''ai une boucle infinie : attente de communication par socket.
Si je me débrouille pour sortir dès la première communication, je vois qu'elle a bien été traité.
Si je reste en permanence dedans, gtk bloque : plus d'affichage.

Si je passe la fonction (avec tous les paramètres) en fils avec ceci :

Code :

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

1
2
  pid_t pid= fork();
  if (pid!=0) return;

Ça plante !

[gerald3d]

J'ai du mal a saisir ce que tu cherches à faire. Maintenant tu peux toujours lancer un thread avec les fonctions associées au GThread.

Si tu passes par cette solution attention. Tu ne pourras pas agir directement depuis le thread sur les widgets de la boucle principale GtkMain. Si tu manipules des données communes il te faudra utiliser les GMutex en complément.

[troumad]

Je souhaite que mon programme ouvre un fichier. Je lui passe le chemin vers le fichier et il l'ouvre.

En pratique j'ai une fenêtre maîtresse à partir de laquelle je peux ouvrir plein de fichiers. Si j'appelle une autre fois mon programme avec un nom de fichier en paramètre, je souhaite que ce soit la première fenêtre qui ouvre/gère le fichier afin de ne pas ouvrir à nouveau une fenêtre maîtresse. Le second appel et les suivants ne feront que passer le nom de la fenêtre.
J'arrive à gérer ce passage de paramètres, mais il est bloquant. C'est à dire que qui j'attends un seul passage, mon programme récupèrera le nom du fichier passé et l'application graphique se sera active qu'à ce moment ! Pas avant car ça bloque.

[gerald3d]

... Si j'appelle une autre fois mon programme avec un nom de fichier en paramètre, je souhaite que ce soit la première fenêtre qui ouvre/gère le fichier afin de ne pas ouvrir à nouveau une fenêtre maîtresse...

Donc il faut que ton programme, lors de son lancement, vérifie qu'il n'existe pas déjà une instance de lui-même. Le post suivant traite déjà de ce sujet.

Ensuite, si ton application est lancée, il faudrait peut être prévoir une "porte ouverte" pour lui donner un nom de fichier pendant son fonctionnement. Ici je pencherai pour les GIOChannel. Tu peux écouter un fichier, une pipe ou un socket sans être bloquant.

[liberforce]

libunique fait cela pour GTK2. Pour GTK 3 c'est inclus de base dans GApplication ou GtkApplication.

[troumad]

Donc il faut que ton programme, lors de son lancement, vérifie qu'il n'existe pas déjà une instance de lui-même.

C'est bon, avec le socket ça passe sans problème

Ensuite, si ton application est lancée, il faudrait peut être prévoir une "porte ouverte" pour lui donner un nom de fichier pendant son fonctionnement. Ici je pencherai pour les GIOChannel. Tu peux écouter un fichier, une pipe ou un socket sans être bloquant.

Je voterai pour un socket.

Ai-je bien raison quand je pense ceci :

Le paramètre d'entrée de g_io_channel_unix_new () (http://developer.gnome.org/glib/stab...el-unix-get-fd ) est bien la sortie de socket(AF_UNIX, SOCK_STREAM, 0)

Après, je lance le système non bloquant avec g_io_add_watch () .

La fonction déclarée dans g_io_add_watch () utilise g_io_channel_read_line () ou g_io_channel_read_line_string () pour récupérer les données arrivant dans le socket. La seconde fonction me fait peur car je ne vois pas comment est gérée la taille du buffer. g_io_channel_read_to_end () pourrait aussi convenir, elle me semble plus simple car il n'y a pas la gestion d'un caractère de fin spécifique.

Pour passer un message au socket, j'utilise g_io_channel_write_chars ().

Quand j'ai fini de me servir d'un chanle, je dois le fermer avec g_io_channel_close () . Est-ce bien obligatoire ?