Il giorno gio, 31/03/2011 alle 20.44 +0200, Giuseppe Penone ha scritto:
> ok, so you advice that every instance of the app would have his own
> server (this is the only way any independent instance can listen and
> control the window in shared memory)
> 


Well, frankly speaking I started from the assumption that at every
moment there will be only _one_ instance of the app (with its own
server), handling all the windows. Every time the user calls it, a new
one starts, but dies within moments, and tells the original one to open
the file (or open an empty window if no filename is given, that depends
on the app).
Is there some particular reason why you must have more instances running
at the same time?
If there is, then my idea is still extendable, but things become indeed
more complex.

Pietro

> 
> On Thu, Mar 31, 2011 at 8:42 PM, Pietro Battiston
> <m...@pietrobattiston.it> wrote:
>         Il giorno gio, 31/03/2011 alle 20.27 +0200, Pietro Battiston
>         ha scritto:
>         
>         > Il giorno gio, 31/03/2011 alle 20.01 +0200, Giuseppe Penone
>         ha scritto:
>         > >
>         > >         (Assuming that indeed there's no way of using
>         sockets in a
>         > >         non-blocking
>         > >         fashion - I'm totally ignorant about that) maybe
>         having a
>         > >         little process
>         > >         created with multiprocessing would be simpler &
>         more portable,
>         > >         for you,
>         > >         than using threading? I guess a single one is
>         sufficient, so
>         > >         the
>         > >         overhead shouldn't be significant, even on
>         Windows. Then, at
>         > >         every
>         > >         iteration of the main loop, the main process could
>         check, from
>         > >         a shared
>         > >         Value (or Array), if there's something to open.
>         > >
>         > >         (untested, sorry if I wrote something stupid)
>         > >
>         > > Hi Pietro,
>         > > the problem of having a single and independent process
>         dedicated to
>         > > the job of server is that the server would not be able to
>         rise a
>         > > minimized/hidden window as consequence of the situation "a
>         new file
>         > > open starts (user double click) unaware that the same file
>         is already
>         > > opened".
>         >
>         >
>         > The server should not, that would be the job of the main
>         process...
>         >
>         > User: "Hey, program, open that file"
>         > Main process1: starts, spawns the server through the
>         multiprocessing
>         > module
>         > Server1: "Hey, main process, there is no open instance, have
>         fun"
>         > Main process1: "thanks", opens the file in a new window
>         >
>         > later...
>         >
>         > User: "Hey, program, open that file"
>         > Main process2: starts, spawns the server through the
>         multiprocessing
>         > module
>         > Server2: "hey, Main process2, there is an already open
>         instance!"
>         > Main process2: "OK, tell it to open that file!"
>         > Server2: "Server1, could you please tell you friend Main
>         process to open
>         > that file?"
>         > Server1: "Sure, Server2!"
>         > (Main process2 & Server2 exit)
>         > Server1: "Hey, Main process2,
>         
>         
>         Sorry Server1, but that's Main process1.
>         
>         
>         Pietro
>         
>         _______________________________________________
>         pygtk mailing list   pygtk@daa.com.au
>         http://www.daa.com.au/mailman/listinfo/pygtk
>         Read the PyGTK FAQ: http://faq.pygtk.org/
>         
> 


_______________________________________________
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Reply via email to