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 <[email protected]>wrote: > 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 > > > > > > void gtk_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 [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/
