Looking for feedback on Gnome/KDE article

[Havoc Pennington]

On Sat, Dec 14, 2002 at 12:39:23PM +0300, Vadim Plessky wrote:
> as about OpenOffice: well, 2 years ago GNOME people promised to
> "disassemble OO into parts/objects, make BONOBO objects out of
> those, and assemble those objects back into one great Office Suite".
> It seems this hasn't happen.  Why?  I really curious to know thier
> answer.  If you can get some answers - pls post them back to the
> list, or send off-list.

Because no one with a clue thought that was a remotely feasible thing
to do. OO is 6 million lines of code.

I would be careful what you take to be a "promise from the GNOME
people" ;-) as there are quite a few GNOME people.

My memory is that some people thought they could build a Bonobo<->UNO
bridge, and slowly migrate to a merged UNO/Bonobo over time. That
could perhaps be done, the rationale is that UNO is about the nicest
free software component system short of a full CLR. But no one with
the faintest clue thinks OO can be quickly or easily ported to native
widgets, though it could be done with a lot of effort. And the
native-widgets GTK office people continue to work hard on their apps,
which are IMO some of the best native widgets office apps out there,
so there's definitely some disagreement on the right approach.

The existence of WINE, VCL (OpenOffice), XUL (Mozilla), GTK, Qt,
kdelibs/libgnomeui (which fork from GTK/Qt a good bit, though
libgnomeui is actively being folded back into GTK and thus shrinking,
maybe kdelibs is too), and more, just points to the importance of
well-defined library-independent specifications for
interoperability. Reimplementing everything with the One Grand Unified
Toolkit is a pipe dream. And if you ever achieved it, someone would
come along with a better toolkit anyhow. Microsoft keeps replacing
theirs, plus you have everything from OWL to Qt on Win32.

That's why we have something like fontconfig, which defines the set of
fonts that each toolkit should display; this way we transparently get
the same fonts regardless of higher-level libraries used. Mozilla, Qt,
and GTK have all adopted it, and OO will be along eventually.  By
increasing modularity and orthogonality we allow for more innovation.
We can change one part without changing all the others.

i.e. "the grand unified font system" is a much better thing to have
than "the grand unified library that does everything" - modularity
good. If we ever get the platform mostly unified, it will be by
creating a series of well-defined common specs or implementations
along the lines of fontconfig, such that the top layers such as GTK
and Qt become smaller and delegate lots of their functionality. This
gives us a gradual migration to platform consistency and de-bloat as
the right answers become clear, instead of dreaming of wholesale
conversion of huge codebases.

Qt, GTK, WINE, Swing, XUL, VCL are willing to adopt a well-specified
standard feature, when they aren't willing to link to libgnomeui or
kdelibs.

Re: fejj's advogato diary that Guillaume pointed to - nothing
revolutionary there, it's an argument that most of the core GNOME
developers have been making for years. Matthias Ettrich can tell you
that Owen and I quietly circulated a proposal for a primarily
in-process (not network transparent) cross-desktop component system 2
years ago, it's dated December 2000.

What fejj proposes is a simple dlopen() of a lib containing a GObject
- similar to KParts - which most people would not consider a
"component system" in the same way that COM/XPCOM/UNO/Bonobo are
component systems. The book "Essential COM" has a first chapter that
goes into what makes COM a "component system," if you're
interested. But this is just arguing over what words mean; the
dlopen() approach is certainly a reasonable way to get 85% of the
functionality and it's easy to implement. Nothing wrong with that.

My opinion is that the whole free desktop community should be actively
working on two things in this area for the future:

 a) a simple IPC/messaging system, DCOP-like in scope, over the next
    year or so - I would like to see us have this by Dec 2003.

 b) longer term, say 2-3 years out, a toolkit-independent solution in
    the component system or CLR space. i.e. dynamically loadable,
    fully encapsulated (no private ABI), dynamically introspectable
    cross-language objects. This is not primarily a GUI system,
    components are not primarily embedded widgets and in fact one of
    the main driving forces here is likely to be web applications.

This gives us an IPC system and a component system, which are
separate, not the same. Bonobo does not get that right.  But Bonobo
does get some things right, for example I think trying for a full
component system (handling language bindings in a fully automated way,
and fully encapsulating private ABI) is a good idea in the end.

Joel's recent comments are very appropriate. See
http://www.joelonsoftware.com/articles/LordPalmerston.html, a quote:

    The huge surface area of all these worlds of programming leads to
    pointless flame wars over whose world is better. ...  People who
    only know one world get really smarmy, and every time they hear
    about the complications in the other world, it makes them think
    that their world doesn't have complications. But they do. You've
    just moved beyond them because you are proficient in them. These
    worlds are just too big and complicated to compare any more.

Anyone who starts telling you about how GNOME or KDE or Windows or
Delphi or GNUStep or Amiga or *whatever* is the greatest thing ever in
every way, should be dismissed out of hand. We need to be discussing
the details and specifics, both pros and cons, and using all the
experience that we've gained by trying multiple approaches in various
projects. i.e. harness all the expertise of the whole free software
community. Core developers are too scarce to ignore some of them.

The faster we can drive well-understood "commoditized" problems down
into common well-documented modules, the faster Linux (and UNIX) will
move forward on the desktop.

Anyway, just some thoughts on this whole thread.

Havoc