Re: New Bindings modules (python)

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

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.

> 
> I guess I can do PyORBit releases too if required.
> 
> > I am more concerned about the gnome-python tarball, because it seems to
> > wrap gtkhtml2 and libgnomeprint*. which are not part of the GNOME
> > Platform and therefore might not be API stable. I also wonder how
> > API-stable the bonobo stuff is. I thought I saw libwnck bindings as
> > well, but maybe that was just in cvs. Can you give me a full list of the
> > stuff that you do wrap, such as libglade, libgnome, libgnomeui, gconf,
> > etc?
> 
> pygtk: 
>   gobject
>   atk
>   pango
>   gtk
>   libglade
> 
> 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.  I am fine with that.  Point 3- may be required, occasionally,
even after API freeze.  Is it possible?

  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!

  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?)

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.

  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.