Re: Using python + pygtk in Desktop modules (was Re: Revisiting the Gnome Bindings)
- From: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- To: Murray Cumming <murrayc murrayc com>
- Cc: Thomas Vander Stichele <thomas apestaart org>, PyGTK <pygtk daa com au>, Jonathan Blandford <jrb redhat com>, gnome-desktop-devel <desktop-devel-list gnome org>, Mikael Hallendal <micke imendio com>
- Subject: Re: Using python + pygtk in Desktop modules (was Re: Revisiting the Gnome Bindings)
- Date: Mon, 27 Sep 2004 15:38:06 +0100
Seg, 2004-09-27 às 11:36 +0200, Murray Cumming escreveu:
> Jonathan said:
> > I would love to see limited use of python in the desktop release for
> > GNOME 2.10.
>
> I'd love to see whether this idea can fly, and I like the idea of
> maintainers getting what they need for their own specific modules.
>
> We all have our different favourite languages, but I think we are all
> capable of hacking on Python even if we don't all love it [1], so I don't
> think its use would prevent contributions. And it's already widespread on
> distros, so I don't think it would be adding a big new dependency. [2]
>
> I have some practical concerns about the binding support. Jonathan and
> Thomas, in your proposed cases, would pygtk be enough for you, or do you
> need to use API that is not just in GTK+ and libglade. For instance, would
> you need API-stable gnome-vfs and gconf bindings? If those are not
> available to you, can you workaround it by using C directly from python?
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.
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...
>
> By the way, these python bindings are not necessarily unavailable, but you
> should make your requirements clear, because someone has to support them
> and keep them on the GNOME schedule.
As I said, I think we can work something out to make gnome-python
follow the GNOME release schedule. We just needed to focus all our
efforts on pygtk, to fix the last API issues before the API freeze, lest
we get stuck with an broken API forever frozen. That effort lead to
gnome-python being temporarily with lack of resources. Now that PyGTK
is API frozen, I (and not only me, I hope) can pick up development of
gnome-python.
> I realise that a Desktop module's dependencies don't need to be API-stable
> (for instance, gstreamer), but I think that a widely-used dependency
> probably should be, like any "development platform".
Agreed. Anything that offers an API is a development platform. Let's
not treat language bindings, where language != C, any different than C.
>
>
> [1] I am a strongtypist. It makes me happy.
>
> [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.
Regards.
--
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]