RE: Announcing: Project Ridley

["Banginwar, Rajesh" <rajesh banginwar intel com>]

I am really glad to see the intention of keeping the ABI same even with
3.0 release. 

As we are going to include GTK 2.4 or 2.6 (based on distro feedback;
e.g. Redhat ships with 2.4) in the first release of desktop module of
LSB, having ABI compatibility even after platform consolidation is a
welcome decision. 

We are currently in the process of defining the set of ABI to be
included in LSB. It will be helpful if gtk+ community can provide the
feedback as to what interfaces should be kept out. Should we exclude any
interfaces in addition to the ones currently deprecated in 2.6? We are
planning on publishing the list of these interfaces over next few weeks.

Thanks,

-Rajesh

> -----Original Message-----
> From: gtk-devel-list-bounces gnome org [mailto:gtk-devel-list-
> bounces gnome org] On Behalf Of Havoc Pennington
> Sent: Sunday, August 21, 2005 9:31 AM
> To: Roger Leigh
> Cc: gtk-devel-list gnome org; Jonathan Blandford; desktop-devel-
> list gnome org
> Subject: Re: Announcing: Project Ridley
> 
> On Sun, 2005-08-21 at 14:05 +0100, Roger Leigh wrote:
> >
> > One thing I (as an end developer) would like is for libgobject to be
> > merged with libglib
> 
> That's off the table since it would break ABI ...
> 
> > I currently find the split to make some tasks impossible (for
example,
> > I recently wrote a GUnixSignalSource to inject UNIX signals into the
> > mainloop, but without it being a GObject, I couldn't implement it
> > completely).
> >
> 
> You should have been able to link to libgobject and write it as a
> GObject though ?
> 
> > Something else I would also like (but can implement separately
> > initially) is a GObject-based container library which implements
> > STL-style container and iterator interfaces.  This would allow the
> > current list/hash/vector etc. types to be implemented as GObjects
with
> > a standardised iterator interface, allowing the use of generic
> > algorithms etc.
> 
> It would probably be hopelessly inefficient, since GObject is a bit
> heavier than a base object in Java or Python ...
> 
> > Another thing I would be interested as an extension to the above is
> > specialisation (or rather, restriction) of containers to particular
> > GTypes.  If for example, we had a call such as
> >
> > GType
> > g_type_specialise(GType type, ...)
> 
> I think at some point you should accept you're coding in C ;-) if we
> just reimplement Java/C#/Python poorly, it's not that useful ...
> 
> Havoc
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list