Re: New Bindings modules (python)

[Murray Cumming <murrayc murrayc com>]

On Wed, 2004-05-05 at 12:42 +0100, Gustavo J. A. M. Carneiro wrote:
> A Qua, 2004-05-05 às 12:12, Johan Dahlin escreveu:
> > > Would you like to put pygtk on the schedule?
> > 
> > Sure, but I can only answer for pygtk
> > (gobject,atk,pango,gdk/gtk,libglade) and not for gnome-python which is
> > Gustavo Carneiros area these days. I've only done the releases.
> 
>   Unfortunately I have not enjoyed enough free time to do any
> significant work lately, so I cannot in good conscience claim any sort
> maintainership status of gnome-python.

Hmm, we would need some officially responsible maintainer. If there is
no maintainer that says that it should be on the schedule then it would
be meaningless to put it on the schedule.

That might not be such a big problem though. Now that I see that pygtk
wraps libglade, I see that pygtk does provide most of what people want.
But it would be a pity if they didn't have easy access to
libgnomecanvas, gconf, and gnome-vfs as well.

I think now might be the time to call for a new maintainer(s) for
gnome-python, to stop it being orphaned. When you give responsibility,
people often take responsibility.
 
[snip]
> > gnome-python:
> >   libbonobo
> >   libbonobouiould
> >   gconf
> >   libpanelapplet
> >   libgnomecanvas
> >   libgnome
> >   libgnomeui
> >   nautilus
> >   gnome-vfs
> >   libart_lgpl
> 
>   libart_lgpl is not really wrapped.  Only a minimal subset of it is
> wrapped, for integration of the libgnomeprint bindings.  There is no
> separate python module that wraps libart_lgpl.
> 
> >   libgnomeprint
> >   libgnomeprintui
> >   gtkhtml2
> > 
> > pyorbit:
> >   ORBit2
> > 
> > There exists python bindings for libxml2, libxslt and vte, but they are
> > included upstream. I think there are bindings for gstreamer and
> > gtksourceview but they are available from other places.
> > 
> > I haven't heard of libwnck bindings.
> > 
> > For bonobo API stability issues, please contact Gustavo (putting him on
> > CC)
> 
>   Gnome-python's API is not 100% stable at the moment.  Some API changes
> that have been happening lately are:
> 	1- Addition of functions and methods;
> 	2- Addition of parameters to existing function and methods, carefully
> as to make them optional and not break applications;
> 	3- Addition of raised exception when checking parameters;
> 
> Of these points, only point 3- can be considered API break.  But usually
> these exception are raised when otherwise the function would simply
> crash, so they can't really be considered API break.
> 
>   I imagine that 1- and 2- changes will not be allowed after API
> freeze.

Yes, not until the GNOME 2.9/2.10 cycle.

>   I am fine with that.  Point 3- may be required, occasionally,
> even after API freeze.  Is it possible?

I'm not a Python expert. Will it break already-installed applications? I
guess it will not break already-installed applications if it only deals
with situations that cause crashes anyway.

Will it break compilation (if there is such a thing?) of
already-existing applications?

>   And, BTW, bonobo API of gnome-python HEAD is stable now.
> 
> > 
> > > If it's absolutely necessary then we can maybe bend the rules just to
> > > get you on board. But I'd need to know what exceptions we are making and
> > > why, so that we can communicate that to users of the platform.
> > 
> > I guess including libgnomeprint[ui] in the tarball is still a good idea,
> > but I'm all in favour of removing gtkhtml2.
> 
>   I don't mind at all removing gtkhtml2 bindings, as long as the code is
> moved into libgtkhtml2 itself.  Let's not throw it away!

Sounds good to me.

>   In general, for modules not part of the GNOME Development Platform,
> these are the things we must _not_ do:
> 	1- Remove these modules, throwing away the code; (what a waste of
> effort)
> 	2- Move into a standalone package; (who would maintain it?)

2. works for lots of other projects. You don't have to stop maintaining
it just because it's not in the same tarball.

> And this is what, IMHO, we _may_ do:
> 	1- Move the code to the respective C library module, though the same
> gnome-python developers can keep maintaining this code with the
> permission of the C module's maintainer.

I think it's much easier for someone to maintain bindings code if it's
in one of their own modules than if it's part of the underlying module.
And I don't think we want GTK+ (or libxml, nautilus, etc) to ship its
bindings along with itself - that would get crazy.

> 
>   This is just my opinion, of course, and I'm not really a maintainer,
> so...
> 
>   Regards.
> 
> -- 
> Gustavo João Alves Marques Carneiro
> <gjc inescporto pt> <gustavo users sourceforge net>
> The universe is always one step beyond logic.
> 
-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com