Re: Using python + pygtk in Desktop modules (was Re: Revisitingthe Gnome Bindings)

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

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.
> 
> >> [2] 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
same time.

> 
> Murray Cumming
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com
-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.