Re: [pygtk] centralized multiple instances of a pygtk app
> so far I've allowed a single instance only for simplicity but now I would
> like to introduce the opportunity to open more instances
> of different documents, but avoid to open twice the same document for
> mistake and instead put the running window to toplevel
> in case there's already an instance of that document opened.
If I understand the problem correctly, you can easily do this using
D-Bus. (If you're on GTK+ 3, GtkApplication makes it even easier; see
its example code [1]. I assume you're on GTK+ 2, which doesn't have
this.)
[1] http://library.gnome.org/devel/gtk/unstable/GtkApplication.html
To do this with D-Bus, in pseudocode:
On app run:
Try to reserve a service address ("bus name", in D-Bus terminology)
If succeeded:
Act as service provider, open windows when requested, etc.
// This is your main app process, the only one that ever lives
// for more than 1 second. Thus, it contains your GUI code as
// well as the D-Bus service.
else:
Send "open file" message to the existing service through D-Bus
Die
On receiving "open file" message: // In main app
If file is already open:
Bring up the window
else:
Open file
--
Johannes
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] centralized multiple instances of a pygtk app
On 03/30/2011 04:58 PM, Giuseppe Penone wrote: This makes sense, but I don't see why you need threads to do it. Multiple windows can be controlled by a single thread. If a given document needs an intensive calculation, that can be split into it's own thread, but that seems orthogonal to having multiple documents open. I cannot do everything in a single thread because, when the user tries to open the same document again I should be aware that the document is already opened and put the already opened window on top of the screen rather than open two instances of the same document. If you double click on a text file, then just minimize the window and double click again upon the same file you will understand the (correct) behavior that apps such as gedit have. So I need a centralized server or something like that, I'm with you up to here. I'd probably create a controller object that keeps track of all open windows, receives requests to open documents, and opens new windows or brings old windows to the front as appropriate. But I'm sure there are other ways to do it just as well. which must be on a separate thread or separate process. I don't understand why this must be. The controller object (or whatever) can run just fine in the same thread as all of the windows. The one example I have handy is Reinteract, which has a window associated with each "notebook" and only allows each notebook to be opened once. An object of class "Application" keeps track of all of these windows. You may wish to consider Application.open_notebook() in http://git.fishsoup.net/cgit/reinteract/tree/lib/reinteract/application.py (This may not be the best example, because Reinteract does use threads. But the windows and the Application object all live in the main thread.) Robert ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] centralized multiple instances of a pygtk app
Hi Robert, This makes sense, but I don't see why you need threads to do it. Multiple > windows can be controlled by a single thread. If a given document needs an > intensive calculation, that can be split into it's own thread, but that > seems orthogonal to having multiple documents open. > I cannot do everything in a single thread because, when the user tries to open the same document again I should be aware that the document is already opened and put the already opened window on top of the screen rather than open two instances of the same document. If you double click on a text file, then just minimize the window and double click again upon the same file you will understand the (correct) behavior that apps such as gedit have. So I need a centralized server or something like that, which must be on a separate thread or separate process. > Especially if you're communicating over a socket. If you're doing this, > why not run each document in its own process? You'd get even more > separation (no GIL) and don't have to worry about how to call GTK functions > from multiple threads. > I could keep separate processes but this way I'm afraid I would not be able to control the window of another process unless all processes/windows have their own server, so the server being not only one but one per instance, maybe I'll try this solution. Thank you and best regards, Giuseppe. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] win64 all-in-one build?
Hi, On 30/03/2011 19:41, Antoine Martin wrote: > I thought I would try to build the installer myself, and whilst I was at > it why not try a 64-bit build? Thank you so much for looking into a 64-bit build! I'm still without a 64-bit Windows machine myself, so it's very much appreciated! > First, it complained about missing WiX, I found version 3.5 here: > http://wix.codeplex.com/ Yes, build_installer.py relies on WiX's current 3.5 stable build (WIX_VERSION = '3.5.2519.0') > (maybe you should add a link to the README and mention which versions > are meant to work - if not all) I'll add this to a HACKING.rst file and point to that from the README.rst file in the "About the pygtk-installer project" section. > Second, it wasn't really clear where I was meant to get xmllint from > once it complained about that, after a failed attempt (xmllint.exe from > googlecode) I ended up downloading a bunch of ZIP files from: > ftp://ftp.zlatkovic.com/libxml/ > And sticking the contents of the bin/ folder in C:\WINDOWS (for > simplicity). You may want to add a link and brief explanation to the README. I've used a GTK+ runtime environment constructed manually from scratch (basically, it contained everything now included with the 32-bit aio installer except maybe glade) to bootstrap. After that, once you've got a complete aio version installed for the Python version used to run build_installer.py, you have everything (except WIX) needed (i've always executed build_installer.py with Python 2.7 + PyGTK All-in-one 2.whatever.-the-latest-build-might-be). Heh, once you're bootstrapped it's a bit of a self-hosting environment ;) A 32-bit xmllint can be found in http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/libxml2-dev_2.7.7-1_win32.zip And a 64-bit version is included in http://ftp.gnome.org/pub/GNOME/binaries/win64/dependencies/libxml2-dev_2.7.7-1_win64.zip Thinking about it, maybe you could use a 32-bit Python 2.7 with a 32-bit PyGTK-All-in-one (complete installation) to run the build_installer.py script just to bootstrap build_installer for a 64-bit build? > Then the build stopped complaining about that, but asked me to specify > the moduleset, looking at the source and looking at the list of > "PLATFORMS", I figured that I needed to use: > build_installer.py 2.23.1.win64 > Again, you may want to add one or two lines of text to explain what the > options are (or how to find that out) Indeed, documentation on how to configure and run both build_bindings.sh and build_installer.py would be great. Allow me a couple of days to come up with the HACKING.rst file (it's extremely busy here atm). > What about building 2.22.1? Where can I find the module file for that? All releases are tagged in git, so you can still check out the state of the code from that era and even continue from that point in a branch if that would be needed. The reason those files no longer exist in current HEAD: build description files of early releases like 2.22.1 where heavily connected with the build_installer.py code (the xml schema was evolving fast). Honestly, current build description files are still heavily connected to the code... So I've taken a habbit to for example: "git mv wix/2.22.6.win32.xml wix/2.23.1.win32.xml" I agree that's not a good long-term solution[1] , but with 2.24 being the last PyGTK release ever[2] I won't bother changing build_installer just yet... > Finally, here is the build error I stopped at (added a bit of debug to > try to figure out what filename/URL it was bailing out on): > > * Creating .msi installer targeting Python 2.6 > * Cleaning build environment... > * Preparing build environment... > * Preparing feature "PythonExtensionModules"... > * Preparing source package "pygtk" > * Preparing build environment... > * Fetching package sources... > * Downloading package sources from filename= URL=/... > Traceback (most recent call last): > File "build_installer.py", line 1001, in > main() > File "build_installer.py", line 992, in main > builder.build() > File "build_installer.py", line 259, in build > product.merge() > File "build_installer.py", line 284, in merge > self.do_build() > File "build_installer.py", line 323, in do_build > self.build_feature(feature) > File "build_installer.py", line 328, in build_feature > self.build_feature(child) > File "build_installer.py", line 335, in build_feature > sourcepackage.merge() > File "build_installer.py", line 543, in merge > self.do_fetch() > File "build_installer.py", line 564, in do_fetch > response = urlopen(url) > File "C:\Python27\lib\urllib2.py", line 126, in urlopen > return _opener.open(url, data, timeout) > File "C:\Python27\lib\urllib2.py", line 384, in open > protocol = req.get_type() > File "C:\Python27\lib\urllib2.py", line 245, in get_type > raise ValueError, "unknown url type: %s" % self.__original > ValueError: unknown url type: / The
[pygtk] win64 all-in-one build?
Hi, I thought I would try to build the installer myself, and whilst I was at it why not try a 64-bit build? First, it complained about missing WiX, I found version 3.5 here: http://wix.codeplex.com/ (maybe you should add a link to the README and mention which versions are meant to work - if not all) Second, it wasn't really clear where I was meant to get xmllint from once it complained about that, after a failed attempt (xmllint.exe from googlecode) I ended up downloading a bunch of ZIP files from: ftp://ftp.zlatkovic.com/libxml/ And sticking the contents of the bin/ folder in C:\WINDOWS (for simplicity). You may want to add a link and brief explanation to the README. Then the build stopped complaining about that, but asked me to specify the moduleset, looking at the source and looking at the list of "PLATFORMS", I figured that I needed to use: build_installer.py 2.23.1.win64 Again, you may want to add one or two lines of text to explain what the options are (or how to find that out) What about building 2.22.1? Where can I find the module file for that? Finally, here is the build error I stopped at (added a bit of debug to try to figure out what filename/URL it was bailing out on): * Creating .msi installer targeting Python 2.6 * Cleaning build environment... * Preparing build environment... * Preparing feature "PythonExtensionModules"... * Preparing source package "pygtk" * Preparing build environment... * Fetching package sources... * Downloading package sources from filename= URL=/... Traceback (most recent call last): File "build_installer.py", line 1001, in main() File "build_installer.py", line 992, in main builder.build() File "build_installer.py", line 259, in build product.merge() File "build_installer.py", line 284, in merge self.do_build() File "build_installer.py", line 323, in do_build self.build_feature(feature) File "build_installer.py", line 328, in build_feature self.build_feature(child) File "build_installer.py", line 335, in build_feature sourcepackage.merge() File "build_installer.py", line 543, in merge self.do_fetch() File "build_installer.py", line 564, in do_fetch response = urlopen(url) File "C:\Python27\lib\urllib2.py", line 126, in urlopen return _opener.open(url, data, timeout) File "C:\Python27\lib\urllib2.py", line 384, in open protocol = req.get_type() File "C:\Python27\lib\urllib2.py", line 245, in get_type raise ValueError, "unknown url type: %s" % self.__original ValueError: unknown url type: / I have no idea why it is targetting Python 2.6, I've got Python 2.7.1 installed... I tried tweaking the constants at the top of the file, but that didn't help. Apologies if this is all covered somewhere else - I couldn't find it. Thanks Antoine ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] centralized multiple instances of a pygtk app
Hi Guiseppe, Let me preface this by saying that I don't really understand threads, so I may be wrong. But my understanding is that threads are used to separate expensive calculations from the code handling the GUI, while still allowing you to pass Python objects back and forth. On 03/30/2011 07:50 AM, Giuseppe Penone wrote: so far I've allowed a single instance only for simplicity but now I would like to introduce the opportunity to open more instances of different documents, but avoid to open twice the same document for mistake and instead put the running window to toplevel in case there's already an instance of that document opened. This makes sense, but I don't see why you need threads to do it. Multiple windows can be controlled by a single thread. If a given document needs an intensive calculation, that can be split into it's own thread, but that seems orthogonal to having multiple documents open. I'm guessing that you're intending to run each window in it's own thread, but that would mean that each window will have to jump through the threading hoops (threads_enter/_leave or doing everything with callbacks) to update itself. This seems like a lot of pain, and I don't see what you gain. it seems to me that the only way to obtain this is to have a server that controls all the instances, being my app cross platform I opted for a tcp/ip server in loopback 127.0.0.1. Especially if you're communicating over a socket. If you're doing this, why not run each document in its own process? You'd get even more separation (no GIL) and don't have to worry about how to call GTK functions from multiple threads. I'm sure it is possible to do what you're trying to do with threads, but I don't know enough to help you out with it. I do think, though, that threads are not the easiest answer to your problem. Robert ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] centralized multiple instances of a pygtk app
Quoting "Giuseppe Penone" : it seems to me that the only way to obtain this is to have a server that controls all the instances, being my app cross platform I opted for a tcp/ip server in loopback 127.0.0.1. gtk.threads_enter() gtk.main() gtk.threads_leave() If your application truly needs to be cross platform (the following holds on windows), don't ever touch gtk.gdk.threads_init/threads_enter /threads_leave. You'll need to rely on gobject.threads_init and only allow the main thread to touch your ui (via gobject.idle_add for example). See http://git.gnome.org/browse/pygtk/tree/examples/threading/gtk_threading.py for a working example. If anybody has a clue about treating many instances of the same app being aware of an already running instance/able to control the already running instance rather than spawning a new one please help me. No ideas here atm, sorry... mvg, Dieter This message was sent using IMP, the Internet Messaging Program. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
[pygtk] centralized multiple instances of a pygtk app
Hi, the app I'm working on is let's say a rich text editor ( http://giuspen.com/cherrytree) so far I've allowed a single instance only for simplicity but now I would like to introduce the opportunity to open more instances of different documents, but avoid to open twice the same document for mistake and instead put the running window to toplevel in case there's already an instance of that document opened. it seems to me that the only way to obtain this is to have a server that controls all the instances, being my app cross platform I opted for a tcp/ip server in loopback 127.0.0.1. the problem is that when the server opens a new thread, as soon as the new thread enters the gtk main loop (gtk.main()) the server stucks. I thought that a new thread, opened with thread.start_new_thread(..) was not blocking but instead the main loop blocks all. I found some tips on threading on pygtk ( http://faq.pygtk.org/index.py?file=faq20.006.htp&req=show) so I tried gtk.threads_enter() gtk.main() gtk.threads_leave() that works on the first opened instance but then crashes on the second. If anybody has a clue about treating many instances of the same app being aware of an already running instance/able to control the already running instance rather than spawning a new one please help me. Best regards, Giuseppe. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] gtk from macport with or without x11 ?
On Wed, 2011-03-30 at 01:36 +0200, laguillaumie sylvain wrote: > so > > no success :( > > i updated the Portfile of macport and i tried to build pygtk 2.23.1 and .2... Please contact the macports or gtk-osx mailing list. John ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
