Discussion :

[ryced]

Bonjour

J'ai une application (python 2.7 + wxpython 3), multi documents (AuiMDIParentFrame), et j'aimerais qu'elle fonctionne comme la plupart des applications multi documents :
- une seule instance lancée à la fois
- si on double-clic sur un fichier document de cette application, il s'ouvre dans l'instance déjà lancée.

En réalité, j'ai déjà fait un truc qui marche en suivant cette méthode : http://stackoverflow.com/questions/5...ssing-commands
Mais il y a pas mal d'inconvénients :
- demande de franchissement du pare-feu (Windows) au premier lancement (ça rebute un peu les utilisateurs)
- après une mise en veille prolongée, l'instance déjà lancée est "oubliée" ... et une deuxième s'ouvre.

Est-ce que quelqu'un aurait une autre méthode ?
Merci d'avance !

[BufferBob]

salut,

je pense qu'une méthode quik 'n dirty pourrait consister à maintenir un descripteur de fichier -temporaire, un lockfile- ouvert en écriture, étant donné que l'écriture concurrente est en général interdite par la plupart des systèmes, mais il y a peut-être plus pro/efficace

[Dan737]

Bonjour,

J'ai pas testé, mais peut-être que wx.SingleInstanceChecker pourrait t'être utile dans ce cas là. J'avais aussi trouvé ces réponses sur StackOverflow plutôt intéressantes. La dernière fait de nouveau référence à wx.SingleInstanceChecker

[ryced]

Bonjour
Et merci pour la réponse.

je pense qu'une méthode quik 'n dirty pourrait consister à maintenir un descripteur de fichier -temporaire, un lockfile- ouvert en écriture, étant donné que l'écriture concurrente est en général interdite par la plupart des systèmes, mais il y a peut-être plus pro/efficace

Je n'ai rien contre le quik 'n dirty que je pratique tous les jours.
Je vois bien comment un fichier temporaire peut permettre à une nouvelle instance de détecter qu'il y en a une autre qui est lancée, mais pas comment ordonner à la première d'ouvrir un fichier document ...

[ryced]

Bonjour

J'ai pas testé, mais peut-être que wx.SingleInstanceChecker pourrait t'être utile dans ce cas là. J'avais aussi trouvé ces réponses sur StackOverflow plutôt intéressantes. La dernière fait de nouveau référence à wx.SingleInstanceChecker

Merci aussi pour cette piste, mais j'avais déjà vu ça ... et je répondrais comme à BufferBob : comment ordonner à l'instance de l'application déjà lancée d'ouvrir un document (dont le chemin se trouve dans les arguments passés à la deuxième instance : sys.argv[1]) ?

Mais merci !

[Dan737]

En effet... Comme trouvé ici https://groups.google.com/forum/#!se...U/xKV46pSf95sJ il te faudra un moyen de communiqué avec l'application déjà ouverte.

Une piste serait peut-être psutil

[BufferBob]

il te faudra un moyen de communiqué avec l'application déjà ouverte.

+1, les tubes nommés (dispos à travers le module win32pipe à priori) sont probablement les plus intéressants, ça fonctionne comme une socket (client, serveur, connect, disconnect) mais à travers un fichier, un peu comme les socket unix finalement, donc ça ne lèvera pas d'exception firewall

Une piste serait peut-être psutil

-1, ça sert pas vraiment à ça psutil, ce serait plutôt du monitoring/relevé d'informations genre consommation disque, cpu, mémoire etc.

[Dan737]

Je pensais à psutil pour trouver le pid de l'application déjà ouverte en fait...

[ryced]

Effectivement, je viens de tester psutil et ça permet bien de récupérer le pid de mon application ... mais comment lui communiquer une commande ? (sans les inconvénients cités plus haut bien sûr)

Quand à win32pipe, j'ai peur qu'avec un nom pareil ça ne soit pas multiplateforme ...

[BufferBob]

Effectivement, je viens de tester psutil et ça permet bien de récupérer le pid de mon application ... mais comment lui communiquer une commande ? (sans les inconvénients cités plus haut bien sûr)

dans l'absolu il suffit que la première instance (celle qui ouvre le lockfile en écriture) écrive son PID dedans, les autres instances auront simplement à lire le fichier et vérifier si le PID est bel et bien en l'air, mais le PID n'est d'aucun secours ici, il faut plutôt se tourner vers les moyens de communication entre processus distants, et dont on a assez vite fait le tour à mon avis

Quand à win32pipe, j'ai peur qu'avec un nom pareil ça ne soit pas multiplateforme ...

ah non c'est sur... honnêtement si je devais faire un truc comme ça -avec les contraintes et exigences que ça implique- et qui en plus soit multiplateforme, je pense que je ferais ça avec une socket, peut-être que quelqu'un aura une meilleure solution à te proposer

[wiztricks]

Salut,

Quand à win32pipe, j'ai peur qu'avec un nom pareil ça ne soit pas multiplateforme ...

A part les sockets et les fichiers, rien n'est multi-plateforme: il faut ajouter des "couches" comme D-Bus (ou autre). Ceci dit, çà ne gêne pas grand monde d'avoir ne variante Windows (named pipe), Linux (autre chose),.... car les informations a échanger sont quand même limitées (et c'est juste "adapter" un code de quelques dizaines de lignes).

- W

[ryced]

Merci à tous pour votre aide ... je n'ai plus qu'à me plonger dans les sockets.

Mais il va me falloir un peu de temps.