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 ?

[troumad]

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

C'est la même chose que GIOChannel ?
ou
C'est mieux ? Plus simple à utiliser ? Plus puissant une fois programmé ?

Au premier coup d'oeil, je dirais que c'est plus simple à gérer... Le fichier d'exemple à l'air pas mal.
Il faut aussi signaler ces pages :
http://developer.gnome.org/unique/1....sage-Data.html
http://developer.gnome.org/unique/stable/UniqueApp.html

Première vue sur le sujet (est-ce bien exact ?)
unique_app_new_with_commands : pour définir/identifier le programme
unique_app_is_running : pour vérifier si le programme est déjà lancé
g_signal_connect (app, "message-received", G_CALLBACK (message_received_cb), NULL); pour lancer en fond l'écoute grâce à un signal
unique_app_send_message : pour envoyer un message qui sera reçu par la fonction callback
(UniqueApp *app, UniqueCommand command, UniqueMessageData *message, guint time_, pointer user_data) : format de la fonction callback (je pense que ce que je n'ai pas mis en gras ne doit pas être présent si on ne prend pas le format _with_commands.

La question que je me pose est pour le retour vers première instance. Est-il possible de prévoir un retour pour vérification ? Peut-être que c'est avec le paramètre app ?

[troumad]

Bonsoir

J'ai un problème avec le début de la gestion de unique :

Code :

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

1
2
3
4
5
6
 /* initialisation GTK */
 gtk_init (&argc, &argv);
 app = unique_app_new_with_commands ("Tirage perso add", NULL,"foo", COMMAND_FOO,"bar", COMMAND_BAR,NULL);
 if (unique_app_is_running (app))
 {
    printf("Envoie de message au programme qui tourne déjà\n"

Et bien, je passe toujours par ce printf !
Pourquoi ? Un fichier caché qui signale la présence du programme ? Mais où alors ?

Il y a aussi la commande qui me gène : elle sert à quoi ? Si je n'en définis pas, j'ai un warning lors de l'exécution !

[troumad]

L'erreur venait du nom de l'application qui doit avoir un certain format ! Je m'en suis douté après avoir cherché et comparé plein d'exemple sur internet. Mais, elles sont où les spécifications sur le nom ?

Code :

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

 app = unique_app_new_with_commands ("org.troumad.perso", NULL,"foo", COMMAND_FOO,"bar", COMMAND_BAR,NULL);

J'ai l'impression que ça marche
Il va me rester à nettoyer le code de tous les mouchards que j'ai mis pour les tests et de tester...

nb : ces modification sont valable pour Linux et Windows ? Je n'ai pas vu que ce n'était que pour Linux.