Re: Using python + pygtk in Desktop modules (was Re: Revisitingthe Gnome Bindings)
- From: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- To: Mikael Hallendal <micke imendio com>
- Cc: gnome-desktop-devel <desktop-devel-list gnome org>, Thomas Vander Stichele <thomas apestaart org>, PyGTK <pygtk daa com au>, Jonathan Blandford <jrb redhat com>, Murray Cumming <murrayc murrayc com>
- Subject: Re: Using python + pygtk in Desktop modules (was Re: Revisitingthe Gnome Bindings)
- Date: Mon, 27 Sep 2004 16:09:33 +0100
Seg, 2004-09-27 às 17:00 +0200, Mikael Hallendal escreveu:
> >> 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.
> Hmm, I think it would be a very bad idea to copy and paste libegg into
> the python bindings and then wrap them. Since that would then be part of
> the python platform which we have to guarantee API stability for. That
> would give the python binded version a "stability guarantee" that was
> never intended for libegg.
> Ie. it would make libegg be part of the platform API which it's not, or
> did I misunderstood what you meant here?
I agree. I never thought of putting it in gnome-python. We are
considering creating a new package, pygtk-extra or gnome-python-extra or
whatever. This would be the place where it would go, along with
pygtksourcevieew, pygtkspell, and anything else that comes along not
from the gnome developer platform.
And of course the egg binding would obey exactly the same rules as the
egg C module: no API stability. This not an ideal solution, but not
much can be done. Unlike C, in python we can't exactly statically link
a module to a program.
> Best Regards,
> Mikael Hallendal
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.
] [Thread Prev