[pygtk] Re: Using python + pygtk in Desktop modules (was Re:
Revisitingthe Gnome Bindings)
Gustavo J. A. M. Carneiro
gjc at inescporto.pt
Mon Sep 27 23:04:03 WST 2004
Seg, 2004-09-27 às 16:48 +0200, Murray Cumming escreveu:
> > I am currently maintaining gnome-python, and I think we can have an
> > API stable gnome-python in gnome 2.10. In fact, gnome-python 2.6.0 will
> > be out soon, and it will be _mostly_ API stable. Of course, during
> > gnome-python 2.6.x the API will be absolutely frozen.
> > I'd just like to reserve the right to make API changes in exceptional
> > cases where the API is fundamentally broken. 99% of changes between
> > gnome-python 2.6 and gnome-python 2.(8|10|whatever) will be API
> > compatible. After that, I think we can promise 100% API compatibility
> > in the future.
> OK, that's a good way to get towards 100% API/ABI stability. Keep scaring
> people, so that they tell you about API problems. I look forward to you
> proposing it for GNOME 2.10.
Listen to him, everybody. Go find an API problem in gnome-python and
file a bug report today! ;-)
> > This reminds me, what should language bindings do about the egg
> > module? Do we wrap it or not? Do we copy-paste the C code into the
> > language bindings or not? This puzzles me...
> If the language can not easily use C code directly from applications, then
> you have to wrap it. Because libegg is not a shared library, you have to
> copy-paste the C code and statically link to that. There's no other way
> that I can think of.
> But I'd much prefer to see the effort go into moving the libegg parts into
> a GTK+ or GNOME library. If it's being used widely then it's probably
> almost ready for that.
> >>  I can imagine two objections:
> >> a) People who want GNOME to use one true runtime, such as Mono, for
> >> all
> >> high-level languages, might think that this takes us further away from
> >> that possibility. But if the one true runtime can really support Python
> >> without major changes to application code, then the ideas do not seem to
> >> be incompatible.
> > Mono can support Python through IronPython, but it has radically
> > different API than PyGTK, so that argument unfortunately doesn't apply.
> Do you mean that the implementation of PyGtk would be different, or that
> the PyGTK API would be different?
Both will be different. I think IronPython just uses the Gtk#
implementation, thus offering the Gtk# API translated from C# to Python.
Gtk# uses CamelCase, I believe. And instead of obj.connect("signal",
handler) you do obj.Signal += handler. Ugh!..
Of course, it should be theoretically possible to create a Mono GTK
implementation with the PyGTK API, but it is impractical to do so due to
the amount of effort required. Obviously, PyGTK implementation itself
is tied to Python/C, so it cannot provide a Mono implementation at the
> Murray Cumming
> murrayc at murrayc.com
Gustavo J. A. M. Carneiro
<gjc at inescporto.pt> <gustavo at users.sourceforge.net>
The universe is always one step beyond logic.
More information about the pygtk