next level of freedesktop.org

[Jody Goldberg]

On Thu, Jul 17, 2003 at 04:39:27PM -0400, George Staikos wrote:
> On Thursday 17 July 2003 16:33, Waldo Bastian wrote:
> > >    The goal is to get all desktops to agree to this, and as Havoc already
> > > knows, glib is a huge sticking point.  You can't force the desktop groups
> > > to accept this.  Unless you intend to develop, maintain, and support the
> > > code for all these platforms, under their deadlines, coding standards,
> > > financial arrangements, and quality control standards, you have to find a
> > > real common denominator.  I think you will find that a primitive C
> > > interface is the only one.
> >
> > How is the conversion "primitive C list" -> {QPtrList,std::,...} different
> > from GList->{QPtrList,std::,...} ?
> 
>   That's the point.  It's no different for anyone except the people who use 
> glib natively.  Using primitive C puts everyone on equal footing, with API, 
> code size, and performance.

I don't understand your logic on this.  If every platform module
re-implements basic data structures internally or in their
interfaces we end up with N _additional_ sets of interfaces to map
from.

The goal here is not to force 'one true library' into all of the
projects.  That is clearly never going to happen.  However, one of the
main barriers to using any of the common platform libraries is
packaging.  KDE developers know that their users will have a certain
set of libraries available.  For them to depend on something that
uses glib is more perilous.  If we can reach some agreement to
include some of those platform level libraries in this new
desktop-base release, that hurdle is removed.

eg  kword uses libwv2 which uses libgsf which uses glib
    kspread _should_ use libgsf but doesn't (their ole support is
    suboptimal) apparently due to packing worries

The argument of whether or not to permit these platform libs in
interfaces is yet another layer.  I'd prefer to see libraries using
standard, shared, debugged, maintainer sets of convenience routines
in their interfaces than rolling their own.  Would I love to have to
map things into nspr format ? or CORBA ? obviously not.  However,
that seems preferable to mapping things into
    XrList & fontConfigList & libxml_list_t