pygobject documentation ?

[Jérôme]

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.

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 ?

Thanks for your feedback.

--
Jérôme
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Timo List]

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.

Cheers,
Timo
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Pietro Battiston-2]

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   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Giuseppe Penone]

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 <[hidden email]> 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   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Jérôme]

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   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Jérôme]

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   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Just Fill Bugs]

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   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Dieter Verfaillie-2]

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   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Giuseppe Penone]

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   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Dieter Verfaillie-2]

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   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Dieter Verfaillie-2]

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
file>properties 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   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Jérôme]

Tue, 10 Jan 2012 18:54:07 +0100
Timo a écrit:

> 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.

This seems to extend tu Gdk.

Besides, there's an exception when the stripped enum begins with a number, as
a python variable can't begin with a number.

http://developer.gnome.org/gdk3/stable/gdk3-Events.html#GdkEventType

typedef enum {
  GDK_NOTHING = -1,
  GDK_DELETE = 0,
  GDK_DESTROY = 1,
  GDK_EXPOSE = 2,
  GDK_MOTION_NOTIFY = 3,
  GDK_BUTTON_PRESS = 4,
  GDK_2BUTTON_PRESS = 5,
  GDK_3BUTTON_PRESS = 6,
[...]
} GdkEventType;

becomes

/usr/share/pyshared/gi/overrides/Gdk.py

class Event(Gdk.Event):
    _UNION_MEMBERS = {
        Gdk.EventType.DELETE: 'any',
        Gdk.EventType.DESTROY: 'any',
        Gdk.EventType.EXPOSE: 'expose',
        Gdk.EventType.MOTION_NOTIFY: 'motion',
        Gdk.EventType.BUTTON_PRESS: 'button',
        Gdk.EventType._2BUTTON_PRESS: 'button',    <-- see the _
        Gdk.EventType._3BUTTON_PRESS: 'button',    <-- see the _
[...]
    }

I had a hard type figuring that one out...

--
Jérôme
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[Timo List]

Op 11-01-12 21:44, Jérôme schreef:

> Tue, 10 Jan 2012 18:54:07 +0100
> Timo a écrit:
>
>> 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.
> This seems to extend tu Gdk.
>
> Besides, there's an exception when the stripped enum begins with a number, as
> a python variable can't begin with a number.
>
> http://developer.gnome.org/gdk3/stable/gdk3-Events.html#GdkEventType
>
> typedef enum {
>    GDK_NOTHING = -1,
>    GDK_DELETE = 0,
>    GDK_DESTROY = 1,
>    GDK_EXPOSE = 2,
>    GDK_MOTION_NOTIFY = 3,
>    GDK_BUTTON_PRESS = 4,
>    GDK_2BUTTON_PRESS = 5,
>    GDK_3BUTTON_PRESS = 6,
> [...]
> } GdkEventType;
>
> becomes
>
> /usr/share/pyshared/gi/overrides/Gdk.py
>
> class Event(Gdk.Event):
>      _UNION_MEMBERS = {
>          Gdk.EventType.DELETE: 'any',
>          Gdk.EventType.DESTROY: 'any',
>          Gdk.EventType.EXPOSE: 'expose',
>          Gdk.EventType.MOTION_NOTIFY: 'motion',
>          Gdk.EventType.BUTTON_PRESS: 'button',
>          Gdk.EventType._2BUTTON_PRESS: 'button',<-- see the _
>          Gdk.EventType._3BUTTON_PRESS: 'button',<-- see the _
> [...]
>      }
>
> I had a hard type figuring that one out...

You are right, this is an exception. For people new to Python+GTK
programming, this can be confusing, but for old PyGTK developers, it is
the same behaviour as before:
 >>> import gtk
 >>> gtk.gdk._2BUTTON_PRESS
<enum GDK_2BUTTON_PRESS of type GdkEventType>

Cheers,
Timo

>

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/