[pygtk] centralized multiple instances of a pygtk app

[Pietro Battiston]

Il giorno ven, 01/04/2011 alle 17.49 +0200, Giuseppe Penone ha scritto:
> The project is not big and complex, no hard to change, it's just me
> that have not clear how to behave yet.
> 
> You say in gedit there's always one process, I don't understand how he
> can listen to the attempt of the user to open a new file,
> a server should always be in a dedicated process... maybe I'll try to
> search in gedit code.

Gedit was only an example of how a single process can manage different
windows, not of how a single process can receive new calls from it being
executed (because gedit does that through DBus, which is not a solution
for you).

But once you switch to the "one process, any number of windows"
principle, then _that_ single process can spawn, with multiprocessing,
its server, stuck listening, and any new process will just tell _that_
server what to open, and then would die in peace.

For instance, currently when I ask CherryTree to create a new instance,
the currently open one is closed. Instead, the app could open it in a
new window. Being able to do something like that that doesn't solve the
problem of the communication with new processes independently spawned,
but seems to me a first step.

Pietro



> 
> Giuseppe.
> 
> 
> 
> On Fri, Apr 1, 2011 at 8:26 AM, Pietro Battiston
> <me a pietrobattiston.it> wrote:
>         Il giorno gio, 31/03/2011 alle 23.59 +0200, Giuseppe Penone ha
>         scritto:
>         > The reason to have more instances in my app
>         (giuspen.com/cherrytree)
>         > is that the user can have more tree notes and copy/paste
>         from one to
>         > the other.
>         
>         
>         Again, "instances" != "processes". Take gedit: as many
>         toplevel windows
>         as you want, each one with as many open notebooks as you want,
>         you
>         obviously can copy/paste from one to the other... and still,
>         only one
>         process running at any time.
>         
>         Then, if you're saying that your project is big, complex and
>         now it's
>         too hard to change, that's another point. But if that's the
>         point, my
>         impression is that _whatever_ communication mechanism you use,
>         it will
>         be very hard to coordinate open instances: for instance, even
>         if you
>         could use DBus, what of the many open processes would act as a
>         server?!
>         
>         Pietro
>         
>         
>         
>         
>         >
>         > Cheers,
>         > Giuseppe.
>         >
>         >
>         >
>         > On Thu, Mar 31, 2011 at 9:30 PM, Pietro Battiston
>         > <me a pietrobattiston.it> wrote:
>         >         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
>         >
>         >
>         >
>         
>         
>         
>         
>         _______________________________________________
>         pygtk mailing list   pygtk a daa.com.au
>         http://www.daa.com.au/mailman/listinfo/pygtk
>         Read the PyGTK FAQ: http://faq.pygtk.org/
>         
>