Re: Proposing gnome-python for inclusion in GNOME Bindings

Ter, 2004-10-12 às 20:48 +0200, Murray Cumming escreveu:
> On Mon, 2004-10-11 at 16:33 +0100, Gustavo J. A. M. Carneiro wrote:
> >   I'd like to propose gnome-python for inclusion in Gnome Bindings.  For
> > those who don't know, gnome-python offers convenient
> > wrappers for most APIs in GNOME Developer Platform, including the
> > following modules:
> > 
> >         gnome, gnome.ui, gnome.canvas, gnome.vfs
> >         gconf
> >         bonobo, bonobo.activation, bonobo.ui
> 
> Great. Well done for getting to this point.
> 
> Are those bonobo bindings really ready for API stability? I know that
> the C++ bonobo bindings are not, but maybe it's easier for you.

  Yes, bonobo python API is stable.  I used it in gnome-osd, for
example.  Also use it in some other stuff (gnumexp).

  Hm... :|

This reminds me, the bonobo and gnome.vfs bindings require pyorbit.  But
pyorbit is James Henstridge's thing (well, actually everything pyxxx is
really james' thing, but...:).  I volunteered to maintain gnome-python,
not pyorbit.

  James, any thoughts about this?  Would you like to:
	a) propose pyorbit to gnome bindings and keep maintaining it;
	b) propose pyorbit but request a volunteer to maintain;
	c) none of the above.
  I suppose I could maintain pyorbit too, if necessary to include it in
gnome bindings, and no one better wants the role. 

> 
> For instance, do you have lots of examples for them, and are they being
> used much?
> 
> > It also has bindings for some desktop modules:
> > 
> >         gtkhtml2
> >         gnome.applet
> >         nautilus
> >         gnomeprint, gnomeprint.ui
> 
> These can not be API-stable because the underlying C libraries are not
> yet API- or ABI-stable. Nor are they in the GNOME Platform, so they
> don't make sense for GNOME Platform Bindings.
> 
> What happened to your plan to split gnome-python up into more modular
> parts? It's well known that I am against including half-stable modules
> in GNOME Platform Bindings, because I want to say simply "all of these
> modules are API-stable and ABI-stable". None of the GNOME Platform
> modules contain large unstable API, for instance.

  Nothing happened to that plan.  We need to discuss in pygtk list the
exact form of splitting.  What I would prefer is to split desktop
modules away from gnome-python and keep only developer platform modules.
Honestly I don't like the one package per wrapped library approach very
much.

> 
> Note that some distros already split gnome-python up anyway, in order to
> have a sensible dependency tree, so that, for instance,
> pymurraytexteditor does not depend on nautilus. But distros don't do
> this in a consistent way. By doing it in the source tarballs, you would
> create more consistency in the distro packages, which is what developers
> actually use. 

  :-\

  We could study a mixed approach.  Have both individual
pygconf,pygnome,pygnomeui, etc.. tarballs, and also a single tarball
gnome-python containing the same thing, using recursive (nested)
configures.  Something like what gcc does, where you can grab the whole
gcc with all languages, or just the languages you need.

> 
> >   I think gnome-python is the perfect complement for pygtk, if one wants
> > to write a full featured GNOME application in the Python programming
> > language.
> >
> > PS: I remind everyone about the new cvs module, gnome-python/pygnome-
> > hello, demonstrating how to make a GNOME application using pygtk and
> > gnome-python.  Suggestions to improve it are welcome too!
> 
> Thanks, but I don't see any use of the #! technique that we discussed,
> in order to depend on a single version of Python, in order to avoid
> breaking the application when Python is upgraded.

  Please look closer.  I assure you it's there.  Special effort went
into that particular feature.  You can even select which python ABI
version you want to use in configure.ac.  Hint: look at pygnome-hello.in
and pygnome-hello, in the toplevel dir.

  Regards.

-- 
Gustavo J. A. M. Carneiro
<[email protected]> <[email protected]>
The universe is always one step beyond logic