Re: Food for thought: Why (and how) should KDE and Gnome unite?

[Gleef <dzol virtual-yellow com>]

On Wed, 23 Dec 1998, Adam Rotaru wrote:
>    Hidy,
> 
> On 23 Dec 1998, Tero Pulkkinen wrote:
> 
> > If we want KDE and Gnome interoperate, the following things must happen:
> > 1) Set of libraries must be introduced that are independent of the
> >    other Gnome or KDE things, especially widget sets. These libraries
> >    must have corba interface, so that our existing common ground (IIOP)
> >    can be utilized -- access outside corba interfaces to these libraries
> >    is banned.
> 
>   Wow! Quite a bold requirement. But it's quite logical.
> Yes, only widget-independent libraries have a chance to become/survive as
> environment-independent.  An example I can imagine is a global
> configuration library, for reading/writing config files regarless to where
> they are.

As far as GNOME goes, (and to the best of my knowledge), the following
core GNOME libraries are completely non-gui, and hence cross-environment:
  glib              [originally a part of GTK+, but separated out for
                    convenience, glib is essentially a set of useful
                    functions, defines, and complex data types]
  gmodule           [I've don't know quite what this does, part of glib]
  ORBit             [The CORBA ORB]
  IIOP              [ORBit's IIOP library]
  IDL               [ORBit's IDL parser]
  gnomesupport      [Gives a more consistant cross-platform API set]
  gnome             [All the non-graphic core gnome functions.  The
                    graphic ones are in libgnomeui]
  gtop              [And associates, for implementing cross-platform
                    system monitoring]
  xml               [XML parsing library]
  
Also, libImlib is a widget-set independant but very useful graphics
display library.  libgnorba (Baboon and Goad) should probably be widget
set independant, but makes a few GTK-calls.

 
> > 2) Web pages must be created and published that has corba interfaces
> >    that are independent of the other parts of the environment.
> >    (no dependencies to the widget sets from the interface, nor its
> >    initial implementation) This allows creation of applications that
> >    are independent of the environment it runs on.
> 
>   As I understand, the CORBA parts are not 100% functional in neither
> platforms yet. Hopefully, the mico and ORBit implementations will
> understand each other (I'm still skeptical). This should definetly happen.

As I understand it, that's what IIOP is for.  The Baboon-KOM conversations
for embedded apps is the trickier bit.

 
> > I propose the following actions to implement this:
> > 1) Start a new cvs repository, independent of the KDE or gnome
> >    trees. (its requirement that any code placed to that repository
> >    is independent of the gnome vs kde split) (a volunteer needed to
> >    maintain the cvs repository/provide resources for it)
> 
>   Well, I don't have the resources - but maybe I can contribute with my
> meaningless emails :)
>   Seriously, I'd like to see that happen, but I doubt such code-sharing
> will happen in the near future.

I'm not all that clear what would go in such a code tree.  


> > 2) convince both gnome and kde programmers to start depend on interfaces and
> >    code in that repository. (so that everyone using kde or gnome must
> >    download it)
>   Logical.

Both GNOME and KDE require too many libraries as it is.  Adding another
library to either would  need some justification.  What I was thinking of
was more a cross-environment library to make a cross-environment's
developer's life easier, not everyone else's life harder.  That is, a
libkdegnome would be required by cross-platform apps, and it would
reference the appropriate non-gui bits, a libgtkkde for GTK KDE bindings,
and a libgnomeqt for Qt Gnomeui bindings.

This way a developer can pick and choose how to put their code together,
but it doesn't disrupt either core development tree.


> > 3) move best and most modular pieces of code from gnome and kde cvs
> >    repositories to the new cvs repository - co-operation of many
> >    authors of gnome and kde modules are needed.
>   Yes, co-operation needed, and stepping through boundaries...

Cooperation is needed, major upheval is not.  What you are suggesting
sounds like major upheval.


> > THere's no way widget libraries will merge in the near future. We need to
> > have code that does not depend on the widget libraries.
>    Agreed.
> 
> > If you have or know some gnome or kde module that is (mostly)
> > independent of surrounding libraries, post its name to the list.
> 
>   Is there any?

Yes, the GNOME list is above.  Most of them are dependant on glib, but
glib is LGPL (so anything can dynamically link to it), and has no user
interface impact, so it hurts nothing but a little disk space to have
libglib on a KDE system.

-Gleef