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 > <[email protected]> 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 > > <[email protected]> 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 [email protected] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://faq.pygtk.org/ > > _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
