Re: [pygtk] centralized multiple instances of a pygtk app
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 m...@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@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
[pygtk] [ANNOUNCE] PyGTK 2.24.0
Hi All, A new stable development release of the Python bindings for GTK-2 has been released. The new release is available from ftp.gnome.org and its mirrors as soon as its synced correctly: http://ftp.gnome.org/pub/GNOME/sources/pygtk/2.24/ Note: PyGTK 2.24 supports the GTK-2.24 API. New users wising to develop Python applications using GTK are recommended to use the GObject-Introspection features available in PyGObject. Existing authors of PyGtk applications are also recommended to port their applications to PyGObject if they wish to take advantage of new features appearing in GTK-3 and beyond. More information on PyGObject and GObject-Introspection can be found at; http://live.gnome.org/PyGObject PyGTK-2.24 will be the final major release of PyGTK. Additional bug-fix releases may appear when necessary to maintain compatibility and stability with the GTK-2.24 series. What's New: New features since PyGtk-2.22.0 * Wrap new API added in GTK/GDK 2.23/2.24 * Many windows build fixes * Many documentation updates and improvements * Many bug fixes Bug reports, as always, should go to Bugzilla; check out http://pygtk.org/developer.html and http://pygtk.org/feedback.html for links to posting and querying bug reports for PyGTK. John Stowers ___ 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, Trimmed responses below: 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. OK, so I am going to have jhbuild the whole thing, right? Has it been done before on 64-bit? Is it even meant to work? 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 Hah! Much easier, thanks. 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? This sounds a bit unclean, but it may be easier. (...) 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... 2.24 was just released today, which makes it an ideal time to look into this. The wix/2.23.1.win64.xml file is a skeleton build description file. (...) You could use wix/2.23.1.win32.xml as an example here. Gotcha. Note that 64-bit pycairo/pygobject/pygtk Python extension modules will need to be built with the build_bindings.sh script backed by a 64-bit GTK+ runtime, 64-bit Python and a MinGW64 toolchain. Why the MinGW64 toolchain? I thought that you needed to use VC2008 to ensure python modules can link to VC dlls used to build Python 2.x? (...) [1] I've been playing with the idea to turn the whole project into a more generic gnome-windows .msi installer generator. Just think about the impact a good stand-alone Glade or whatever installer could have. Guess the build description schema is going to have to evolve even more! :) That's quite ambitious. When I find the time, I'll try to bootstrap at least GTK 64-bit and see how it goes from there. Can you just confirm whether I should be using MinGW or VC2008? 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
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. Giuseppe. On Fri, Apr 1, 2011 at 8:26 AM, Pietro Battiston m...@pietrobattiston.itwrote: 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 m...@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@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 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 m...@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 m...@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@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] win64 all-in-one build?
Quoting Antoine Martin anto...@nagafix.co.uk: 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. OK, so I am going to have jhbuild the whole thing, right? Has it been done before on 64-bit? Is it even meant to work? Last time I tried, jhbuild on MSYS/MinGW wasn't exactly a walk in the park (see for example http://afuera.me.uk/jhbuild-windows/). Eventually gave up fighting it, for a while at least... But I don't think you'll need to jhbuild the whole platform. You can maybe build pycairo/pygobject/pygtk with the build_bindings.sh script against either: a) these (mostly) recent 64-bit builds: - http://www.gtk.org/download-windows-64bit.html (the website is a bit outdated) - http://ftp.gnome.org/pub/GNOME/binaries/win64/ Some of those 64-bit packages on ftp.gnome.org will need to be updated and now that Tor has basically thrown in the towel[1] you'll need to take care of that before anything else. Think you might get away with just looking into glib-2.28 and gtk+-2.24. b) the opensuse build service Tor refers to has both 32-bit and 64-bit builds of way more that what has been offered on ftp.gnome.org before. I think we'll need to rely on those builds in the future (for GTK+-3 and PyGObject-3 etc). As there's no history of 64-bit pycairo/pygobject/pygtk windows builds you could also start with these. Btw, the 32-bit aio installer includes the packages from: http://ftp.gnome.org/pub/GNOME/binaries/win32/ (...) 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... 2.24 was just released today, which makes it an ideal time to look into this. Well, almost everything is ready to release the 2.24 aio installer. The only things I'm still waiting on: - an answer to https://bugzilla.gnome.org/show_bug.cgi?id=646437 - an unstable Glade 3.7.4 or stable Glade 3.8 release (3.7.3 has a tendency to show invalid info in the widget overview and crash when you click a widget in the overview). If nothing comes up I'll stay with 3.6... A build script for Glade is tracked here: https://bugzilla.gnome.org/show_bug.cgi?id=634978 If all goes well I'll release pygtk 2.24 all-in-one somewhere next week (with or without Glade 3.7/3.8). Note that 64-bit pycairo/pygobject/pygtk Python extension modules will need to be built with the build_bindings.sh script backed by a 64-bit GTK+ runtime, 64-bit Python and a MinGW64 toolchain. Why the MinGW64 toolchain? I thought that you needed to use VC2008 to ensure python modules can link to VC dlls used to build Python 2.x? Well, Visual Studio is preferred by the Python core devs. MinGW works too, with some gotchas here and there due to mixing different c libraries at runtime. For example: - msvcrt used by the GTK+ runtime and PyGTK when built with MinGW - msvcr90 used by Python 2.6 and newer In this case a function (from GIO for example) that returns a file descriptor is useless from Python code and vice versa. Other than that, building Python extensions with MinGW works fine. (...) [1] I've been playing with the idea to turn the whole project into a more generic gnome-windows .msi installer generator. Just think about the impact a good stand-alone Glade or whatever installer could have. Guess the build description schema is going to have to evolve even more! :) That's quite ambitious. Most of what's needed is already there :) It could use a good refactoring though... When I find the time, I'll try to bootstrap at least GTK 64-bit and see how it goes from there. Read above :) Can you just confirm whether I should be using MinGW or VC2008? MinGW might be the path of least resistance, don't think anyone has given PyGObject's dsextras.py and PyGObject's+PyGTK's setup.py msvc support code any attention for a couple of years. I'm pretty sure PyGTK-2.12 was the last release actually built with msvc... mvg, Dieter [1] http://tml-blog.blogspot.com/2011/03/gtk-on-windows-i-am-not-really-doing-it.html 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/
