[pygtk] blog: Bundling a Python application on Mac OS X with VirtualEnv
Hi all, I wrote a blog on how I package my Python+gtk application for OS X. http://blog.xebia.com/2011/03/31/bundling-a-python-application-on-mac-os-x-with-virtualenv/ Use it to your advantage ;) Regards, Arjan ___ 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] blog: Bundling a Python application on Mac OS X with VirtualEnv
Arjan Molenaar wrote: Hi all, I wrote a blog on how I package my Python+gtk application for OS X. http://blog.xebia.com/2011/03/31/bundling-a-python-application-on-mac-os-x-with-virtualenv/ Use it to your advantage ;) This is the same approach as used by ige-mac-bundler: https://sourceforge.net/apps/trac/gtk-osx/wiki/Bundle And same is used on Windows (one GTK per application), if reading on http://www.gtk.org/download-windows.html We went for a different approach, since we had a lot of small python programs all using pygobject/pygtk... (so bundling Python and PyGTK with each one would add a lot of overhead, especially for the generated ones) So instead we use the system #!/usr/bin/python with a _single_ installation of gtk+ and pygtk in /opt/gtk... Using the Quartz version, rather than the X11 version. More details at http://0install.net/install-mac.html Used to have Homebrew too, but since _all_ python modules are refused* upstream (in master) it was removed again. * see https://github.com/mxcl/homebrew/issues/issue/1612 And of course homebrew didn't offer any packages anyway... --anders ___ 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 ?
laguillaumie sylvain wrote: yes on windows it works fine with handle no problems ok for pygtk 2.23 so macport is not uptodate 2.23.1 is a development version, 2.22 is the stable series. So it seems up-to-date with 2.22.0 (=latest stable version). If you want access to new features from the later versions, you need to do selective backports (like the patch I posted*). But nswindow and nsview _are_ a part of the GTK 2.22 API: http://git.gnome.org/browse/gtk+/tree/gdk/quartz/gdkquartz.h?h=gtk-2-22 So you could request for it to be included in PyGTK 2.22.1 ? http://git.gnome.org/browse/pygtk/tree/gtk/gdk.override?h=pygtk-2-22 --anders * http://git.gnome.org/browse/pygtk/commit/?id=be609e744ee47b117ced07f234262e4032658050 ___ 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
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.) In my idea a server is dedicated only to listen, so I don't understand how I could work in a single thread/process, I will take a look to the example link that you provided anyway, 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] centralized multiple instances of a pygtk app
On Thu, Mar 31, 2011 at 12:35 AM, Johannes Sasongko sason...@gmail.comwrote: 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 The problem with dbus is that as far as I've read on the internet it is not supported on windows (my app is mainly for linux but should work fine on windows as well). 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] centralized multiple instances of a pygtk app
Il giorno mer, 30/03/2011 alle 13.50 +0200, Giuseppe Penone ha scritto: I found some tips on threading on pygtk (http://faq.pygtk.org/index.py?file=faq20.006.htpreq=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. (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) Pietro ___ 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
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, seems like the user wants to open that file Main process1: as it does in every iteration of the main loop, scans for new info from the Server1, finds a new filename to open, remembers it's already opened in some window, rises that window. (again, maybe I just missed something trivial, but at least that should be able to avoid any additional misunderstandings) (notice that _in any case_, with gtk, it is sane to play with GUI only from one thread/process) Pietro ___ 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
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) On Thu, Mar 31, 2011 at 8:42 PM, Pietro Battiston m...@pietrobattiston.itwrote: 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/
Re: [pygtk] centralized multiple instances of a pygtk app
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/
Re: [pygtk] centralized multiple instances of a pygtk app
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/
Re: [pygtk] centralized multiple instances of a pygtk app
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. Cheers, Giuseppe. On Thu, Mar 31, 2011 at 9:30 PM, Pietro Battiston m...@pietrobattiston.itwrote: 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@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
