Re: [pygtk] pygobject documentation ?
I agree with Pietro, taken that there are rules for retrieving the Python functions from the C functions, so the documentation for Python should be automagically generated from the C documentation. Let me correct Jérôme: it's wrong that glade 3.10 does not supports gtk2, actually requires gtk 2.20. Finally I wish that the pygtk all in one installer for windows will be available soon for PyGobject - GTK3 otherwise porting cross platform apps is not possible. Giuseppe. On Wed, Jan 11, 2012 at 00:23, Pietro Battiston m...@pietrobattiston.itwrote: Il giorno mar, 10/01/2012 alle 18.54 +0100, Timo ha scritto: Op 10-01-12 15:42, Jérôme schreef: Hi all. I started python and pygtk recently (a few weeks). For that I used Python 2.7 documentation http://docs.python.org/ python GTK2.0 tutorial http://pygtk.org/pygtk2tutorial/index.html Then, I decided to switch to pygobject. Two reasons for that : * The advice on pygtk.org : New users wishing to develop Python applications using GTK+ are recommended to use the GObject-Introspection features available in PyGObject. * The fact that glade, that I wanted to use as well, now (from version 3.10) only supports GTK3 (or so I understand). The resources I use are now referenced here : https://live.gnome.org/PyGObject * The tutorial : http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/index.html * A partial doc I don't really use : http://people.gnome.org/~johnp/girdocsalpha/Gtk/ * Examples I just discovered : http://developer.gnome.org/gnome-devel-demos/stable/ The most annoying is that I often find myself having to deal with the GTK3 reference manual : http://developer.gnome.org/gtk3/stable/ and guess what the python code corresponding to the C code can be. Some adaptations are trivial, like from voidgtk_window_set_title(GtkWindow *window, const gchar *title); to Gtk.Window.window.set_title(string) But it is sometimes hard to just guess the name of python constants from C constants. Like from GTK_WINDOW_POPUP to Gtk.WindowType.POPUP, for instance. Constants are actually pretty easy once you understand how they are mapped to Python. Have a look at the C docs page for all enumerations: http://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html Let's start at the top of these for convenience sake: GTK_ACCEL_MASK from GtkAccelFlags becomes Gtk.AccelFlags.MASK GTK_ARROWS_BOTH from GtkArrowPlacement becomes Gtk.ArrowPlacement.BOTH GTK_ARROW_UP from GtkArrowType becomes Gtk.ArrowType.UP You will notice a pattern: take the enumeration name, split the Gtk part and rest with a dot, then leave out GTK_*_ part from the types and append them to the previously splitted name. This approach always worked for me till now. I can confirm this holds for me too (though often with some trial and error, even after some time), but still I'm curious: is any further (possibly automatic?) step in documenting pygobject planned? In the end, introspection is about automatically transforming C functions/constants into python methods/constants, so automatic conversion of API docs should be feasible too. The descriptions could be left as they are, with the possibility of manual overriding (in particular for examples). Crazy? Or just lacking manpower? 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] pygobject documentation ?
Wed, 11 Jan 2012 12:28:12 +0200 Giuseppe Penone a écrit: Let me correct Jérôme: it's wrong that glade 3.10 does not supports gtk2, actually requires gtk 2.20. I was refereing to http://glade.gnome.org/ These are bugfix releases for the 3.8 series for GTK+-2 and the 3.10 series for GTK+-3 and http://us.generation-nt.com/answer/bug-638478-allow-installing-both-glade-3-8-3-10-help-204502131.html Glade 3.8 is the last that can create layouts usable with gtk2. Glade 3.10 has new features for gtk3 and loads of new bugs, one of them the inability to create gtk2 layouts. But I didn't really investigate, as the main reason for choosing GTK3 was the advice on pygtk.org. I didn't check about windows porting either, and your remark about the installer not yet available makes me believe the move was perhaps too early. -- Jérôme ___ 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] pygobject documentation ?
Tue, 10 Jan 2012 18:54:07 +0100 Timo a écrit: Constants are actually pretty easy once you understand how they are mapped to Python. Have a look at the C docs page for all enumerations: http://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html [...] You will notice a pattern: take the enumeration name, split the Gtk part and rest with a dot, then leave out GTK_*_ part from the types and append them to the previously splitted name. This approach always worked for me till now. Hi all. Thanks for the tip, and for your feedbacks about the doc. I thought there might be something of this kind but it didn't seem that _systematic_ to me. -- Jérôme ___ 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] pygobject documentation ?
On 01/10/2012 10:42 PM, Jérôme wrote: But it is sometimes hard to just guess the name of python constants from C constants. Like from GTK_WINDOW_POPUP to Gtk.WindowType.POPUP, for instance. Is there any document indicating generic recipes to do the translation, or do I just need to pull my hair a little more time until I can feel that ? Is there any other document I could use ? Was GTK3 actually too bleeding edge for a beginner ? More generally, what approach would you suggest ? Inspect the .gir file in your /usr/share/gir-1.0/. Those are xml files. You can also use GirLook as a GUI gir file inspection tool. http://sourceforge.net/projects/girlook/ ___ 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] pygobject documentation ?
On Wed, 11 Jan 2012 12:28:12 +0200, Giuseppe Penone wrote: I agree with Pietro, taken that there are rules for retrieving the Python functions from the C functions, so the documentation for Python should be automagically generated from the C documentation. Let me correct Jérôme: it's wrong that glade 3.10 does not supports gtk2, actually requires gtk 2.20. No. Glade 3.8.x is for GTK+ 2.X Glade 3.10.x is for GTK+ 3.X Both versions can be installed in parallel into the same prefix. Finally I wish that the pygtk all in one installer for windows will be available soon for PyGobject - GTK3 otherwise porting cross platform apps is not possible. The good news: - PyGObject win32 port is complete afaik (needs loads of testing) The not so good news: - GObject-Introspection win32 port is not complete, but mostly functional. See https://bugzilla.gnome.org/show_bug.cgi?id=620566 - GTK+3 on win32 is usable but has serious themeing work that still needing to be done (engines are out, css is the new way of doing things, but its win32 support is not yet complete). The default theme (Raleigh) or some other theme like Adwaita can be used instead, but most win32 people hate doing so... - Glade 3.10 doesn't build ootb, patches are being prepared, but: - GLib's handling of special paths on win32 (g_get_home_dir, g_get_tmp_dir, g_get_user_data_dir, ... so most everything in glib/gutils.c) has issues that need to be fixed first... That last point is blocking Glade 3.10, g-i and in very specific cases GTK+3 gsettings schema handling and who knows what else and is what I'm currently working on. Expecting all this to be fixed soon sounds like wishful thinking at best ;) For those adventurous enough, there are experimental builds coming with PyGObject linked against Python 2.7 (that *do not* integrate with Python like you're used to): http://optionexplicit.be/projects/gnome-windows/GTK+3/ 0) Do not ask me for builds supporting other Python versions 1) You'll have to remove the PyGTK All-in-one installer (or deactivate it's pygtk.pth file, eg by renaming it to pygtk.pth.bak) to be able to use this bundle. 2) Extract the bundle to C:\GTK+3 3) Create C:\GTK+3\testpygobject.bat (the name of the file doesn't matter, choose something better if you wish) with the following contents (adapt paths as needed): set PATH=C:\GTK+3\bin;%PATH% set PYTHONPATH=C:\GTK+3\lib\site-packages set GI_TYPELIB_PATH=C:\GTK+3\lib\girepository-1.0 c:\python27\python.exe 4) Run C:\GTK+3\testpygobject.bat and type away at the Python prompt :) If you decide to test these binaries: - patches welcome - note again that all this is *experimental* - do *not* use on production systems - there is *no* support - you are expected to be able to debug your own problems - you are on your own - there is no warranty - insert legalese here Have fun! mvg, Dieter ___ 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] pygobject documentation ?
you can download http://www.giuspen.com/cherrytree and have fun, the glade file is edited with *glade 3.10* and has a minimum requirement of *gtk 2.20* . no hacking was done, after opening my already existing glade file I clicked file--properties and I did set the requirement to 2.20 since it was the lower version available in the radiobutton. Let me correct Jérôme: it's wrong that glade 3.10 does not supports gtk2, actually requires gtk 2.20. No. Glade 3.8.x is for GTK+ 2.X Glade 3.10.x is for GTK+ 3.X Both versions can be installed in parallel into the same prefix. Finally I wish that the pygtk all in one installer for windows will be available soon for PyGobject - GTK3 otherwise porting cross platform apps is not possible. The good news: - PyGObject win32 port is complete afaik (needs loads of testing) The not so good news: - GObject-Introspection win32 port is not complete, but mostly functional. See https://bugzilla.gnome.org/show_bug.cgi?id=620566 - GTK+3 on win32 is usable but has serious themeing work that still needing to be done (engines are out, css is the new way of doing things, but its win32 support is not yet complete). The default theme (Raleigh) or some other theme like Adwaita can be used instead, but most win32 people hate doing so... - Glade 3.10 doesn't build ootb, patches are being prepared, but: - GLib's handling of special paths on win32 (g_get_home_dir, g_get_tmp_dir, g_get_user_data_dir, ... so most everything in glib/gutils.c) has issues that need to be fixed first... That last point is blocking Glade 3.10, g-i and in very specific cases GTK+3 gsettings schema handling and who knows what else and is what I'm currently working on. Expecting all this to be fixed soon sounds like wishful thinking at best ;) For those adventurous enough, there are experimental builds coming with PyGObject linked against Python 2.7 (that *do not* integrate with Python like you're used to): http://optionexplicit.be/projects/gnome-windows/GTK+3/ 0) Do not ask me for builds supporting other Python versions 1) You'll have to remove the PyGTK All-in-one installer (or deactivate it's pygtk.pth file, eg by renaming it to pygtk.pth.bak) to be able to use this bundle. 2) Extract the bundle to C:\GTK+3 3) Create C:\GTK+3\testpygobject.bat (the name of the file doesn't matter, choose something better if you wish) with the following contents (adapt paths as needed): set PATH=C:\GTK+3\bin;%PATH% set PYTHONPATH=C:\GTK+3\lib\site-packages set GI_TYPELIB_PATH=C:\GTK+3\lib\girepository-1.0 c:\python27\python.exe 4) Run C:\GTK+3\testpygobject.bat and type away at the Python prompt :) If you decide to test these binaries: - patches welcome - note again that all this is *experimental* - do *not* use on production systems - there is *no* support - you are expected to be able to debug your own problems - you are on your own - there is no warranty - insert legalese here Have fun! mvg, Dieter ___ 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] pygobject documentation ?
On Wed, 11 Jan 2012 15:26:05 +0200, Giuseppe Penone wrote: you can download http://www.giuspen.com/cherrytree [3] and have fun, the glade file is edited with GLADE 3.10 and has a minimum requirement of GTK 2.20. no hacking was done, after opening my already existing glade file I clicked file--properties and I did set the requirement to 2.20 since it was the lower version available in the radiobutton. So you have managed to steer clear of compatibility problems between both lines of development (GTK+ 2 + Glade = 3.8.X and GTK+ 3 + Glade = 3.10.x). However, claiming Glade 3.10.X supports GTK+ 2 is *wrong*. See Tristan's (Glade maintainer) blog post: http://blogs.gnome.org/tvb/2011/01/15/the-glade-dl/ And this glade-devel mailing list thread: http://lists.ximian.com/pipermail/glade-devel/2011-January/001858.html Hope this clears things up a bit. mvg, Dieter ___ 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] pygobject documentation ?
On Wed, 11 Jan 2012 19:23:22 +0100, Dieter Verfaillie wrote: On Wed, 11 Jan 2012 15:26:05 +0200, Giuseppe Penone wrote: you can download http://www.giuspen.com/cherrytree [3] and have fun, the glade file is edited with GLADE 3.10 and has a minimum requirement of GTK 2.20. no hacking was done, after opening my already existing glade file I clicked file--properties and I did set the requirement to 2.20 since it was the lower version available in the radiobutton. Forgot to add that the reason I'm so headstrong about this (even though fileproperties indeed shows 2.20 as the lowest available GTK+ version in Glade 3.10.x) is that because Glade 3.10.x itself is linked against GTK+ 3. This makes it impossible to use PyGTK widget catalogs in Glade 3.10.x as that would load both GTK+ 3 and GTK+ 2 in the address space of the same process which eventually results in a crash. That alone is enough to recommend Glade 3.8 for GTK+ 2 and 3.10 for GTK+ 3. mvg, Dieter ___ 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] pygobject documentation ?
Op 10-01-12 15:42, Jérôme schreef: Hi all. I started python and pygtk recently (a few weeks). For that I used Python 2.7 documentation http://docs.python.org/ python GTK2.0 tutorial http://pygtk.org/pygtk2tutorial/index.html Then, I decided to switch to pygobject. Two reasons for that : * The advice on pygtk.org : New users wishing to develop Python applications using GTK+ are recommended to use the GObject-Introspection features available in PyGObject. * The fact that glade, that I wanted to use as well, now (from version 3.10) only supports GTK3 (or so I understand). The resources I use are now referenced here : https://live.gnome.org/PyGObject * The tutorial : http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/index.html * A partial doc I don't really use : http://people.gnome.org/~johnp/girdocsalpha/Gtk/ * Examples I just discovered : http://developer.gnome.org/gnome-devel-demos/stable/ The most annoying is that I often find myself having to deal with the GTK3 reference manual : http://developer.gnome.org/gtk3/stable/ and guess what the python code corresponding to the C code can be. Some adaptations are trivial, like from voidgtk_window_set_title(GtkWindow *window, const gchar *title); to Gtk.Window.window.set_title(string) But it is sometimes hard to just guess the name of python constants from C constants. Like from GTK_WINDOW_POPUP to Gtk.WindowType.POPUP, for instance. Constants are actually pretty easy once you understand how they are mapped to Python. Have a look at the C docs page for all enumerations: http://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html Let's start at the top of these for convenience sake: GTK_ACCEL_MASK from GtkAccelFlags becomes Gtk.AccelFlags.MASK GTK_ARROWS_BOTH from GtkArrowPlacement becomes Gtk.ArrowPlacement.BOTH GTK_ARROW_UP from GtkArrowType becomes Gtk.ArrowType.UP You will notice a pattern: take the enumeration name, split the Gtk part and rest with a dot, then leave out GTK_*_ part from the types and append them to the previously splitted name. This approach always worked for me till now. Cheers, Timo ___ 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] pygobject documentation ?
Il giorno mar, 10/01/2012 alle 18.54 +0100, Timo ha scritto: Op 10-01-12 15:42, Jérôme schreef: Hi all. I started python and pygtk recently (a few weeks). For that I used Python 2.7 documentation http://docs.python.org/ python GTK2.0 tutorial http://pygtk.org/pygtk2tutorial/index.html Then, I decided to switch to pygobject. Two reasons for that : * The advice on pygtk.org : New users wishing to develop Python applications using GTK+ are recommended to use the GObject-Introspection features available in PyGObject. * The fact that glade, that I wanted to use as well, now (from version 3.10) only supports GTK3 (or so I understand). The resources I use are now referenced here : https://live.gnome.org/PyGObject * The tutorial : http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/index.html * A partial doc I don't really use : http://people.gnome.org/~johnp/girdocsalpha/Gtk/ * Examples I just discovered : http://developer.gnome.org/gnome-devel-demos/stable/ The most annoying is that I often find myself having to deal with the GTK3 reference manual : http://developer.gnome.org/gtk3/stable/ and guess what the python code corresponding to the C code can be. Some adaptations are trivial, like from voidgtk_window_set_title(GtkWindow *window, const gchar *title); to Gtk.Window.window.set_title(string) But it is sometimes hard to just guess the name of python constants from C constants. Like from GTK_WINDOW_POPUP to Gtk.WindowType.POPUP, for instance. Constants are actually pretty easy once you understand how they are mapped to Python. Have a look at the C docs page for all enumerations: http://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html Let's start at the top of these for convenience sake: GTK_ACCEL_MASK from GtkAccelFlags becomes Gtk.AccelFlags.MASK GTK_ARROWS_BOTH from GtkArrowPlacement becomes Gtk.ArrowPlacement.BOTH GTK_ARROW_UP from GtkArrowType becomes Gtk.ArrowType.UP You will notice a pattern: take the enumeration name, split the Gtk part and rest with a dot, then leave out GTK_*_ part from the types and append them to the previously splitted name. This approach always worked for me till now. I can confirm this holds for me too (though often with some trial and error, even after some time), but still I'm curious: is any further (possibly automatic?) step in documenting pygobject planned? In the end, introspection is about automatically transforming C functions/constants into python methods/constants, so automatic conversion of API docs should be feasible too. The descriptions could be left as they are, with the possibility of manual overriding (in particular for examples). Crazy? Or just lacking manpower? 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] PyGObject documentation
On Sun, Jun 21, 2009 at 3:08 PM, Jeffrey Barishjeff_bar...@earthlink.net wrote: The PyGObject documentation at http://www.pygtk.org/docs/pygobject/gobject-functions.html seems to have shed about half its methods recently. moved to glib namespace http://www.pygtk.org/docs/pygobject/glib-functions.html cheers -- Gian Mario Tagliaretti GNOME Foundation member gia...@gnome.org ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
