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

[Gleef <dzol virtual-yellow com>]

On Tue, 22 Dec 1998, Adam Rotaru wrote:
>     Hi,

Hello there!

> 
> KDE and Gnome already contributed a lot to the acceptance of Linux in
> the desktop market. And this is just the beginning! But as someone said 
> 'having two GUI's for an OS is too much'.  Well, I would say, more
> precisely 'having two proposed GUI application standards for an OS is too
> much'.

Well, we really have five.  CDE/Motif, GNOME/GTK+, KDE/Qt, GNUStep and now
UDE.  Granted CDE/Motif is not Free, and UDE is unlikely to gain much
momentum at this stage, so it's realistically three or four, depending on
how you count.  The "GNOME vs KDE war" has gained so much press people
tend to forget what the real situation is.



>  Open-source movement contributes to having more choice.
>  At first sight, the availability of Gnome and KDE seems like a great choice,
> which is good for the users. But it's not exactly like that. They should
> merge, or eventually one will win. Read more.

I disagree.


> One of the positive contributions of Open-source models is the enhanced
> choice users have. Choice is when your processor does not determine/limit
> your operating system you use, when your OS of choice does not
> determine/limit the GUI you use, and your GUI does not determine/limit
> the applications you use.  The more separate levels are things broken down
> into (basic OS, basic apps, GUI, windowmanager, desktop environment, GUI
> applications), and the more viable combinations exists between levels, the
> more choice is for the user, which is a _good_ thing.

Agreed.  The CDE vs GNOME vs KDE vs GNUStep vs UDE issue also falls in
this category in my opinion.



> KDE vs. Gnome.
> First, we have to note that both of this animals will work with _any_ X
> application, so it's not like Win vs. Mac. But apps take advantage of the
> desktopping functions only if they are written for that environment.
> Having _both_ Gnome and KDE and using the same (X) apps with both is
> possible, but it's not what we'd like in the long run.

Why not?  StarOffice's latest version is a "KDE application"; it doesn't
touch Qt, but it does all the KOM and other KDE communications.  There is
no reason why a similar thing can't happen with non-GTK GNOME
applications.  

After GNOME 1.0 comes out, I think it is not only possible, but it would
be a good thing if someone familiar with both toolkits can write a guide
to cross-environment development.  This guide would tell a developer how
their application, whether they are using GTK+, Qt, or FooLib can make use
of GNOME features if available and/or KDE features if available,
regardless of widget set.


> For choice, there must be a common standard.
> Different products/entities to be interchangable, there must be some
> common standard somewhere. The fact that pretty much every web
> browser/server combination works, is possible because there is a well
> defined (relatively simple) standard. HTTP.  The fact that X applications
> run on different X platforms is possible because of the X protocol
> standard. 
> But Gnome and KDE lacks any such common ground. As a matter of fact,
> they differ greatly exectly in what should be the common ground:

Actually, GNOME and KDE agree far more than they disagree.  We both agree
that we should be using X-Windows, but with an abstraction layer (GDK or
Qt) in case we want to go beyond.  We both agree that interapplication
communications should be handled by CORBA.  We both agree not only that
internationalization is important, but that we should use GNU gettext to
do it.  We both agree that our systems should work on any major Unix, as
well as Linux and *BSD.  We both agree that the system should be as
window manager independant as possible, to encourage user choice.  The
list goes on and on.


> The widgets.
> KDE and Gnome are not interchangable, because they disagree on the
> widget set they use.  It's perfectly OK to have a choice regarding window
> managers, for ex., if they adhere to the same standards. But because KDE
> and Gnome are different built on different widgets, there is no 
> common grounds for applications! So afterall, Gnome and KDE are not
> interchangable options -- although the functions they provide are very
> similar.

As I mentioned earlier, neither KDE nor GNOME are bound by their widget
set.  The only thing you really lose by avoiding the native widget set is
consistent themability.  So, if you write a KDE/GTK-- or a GNOME/Qt
program, it risks looking funny, and possibly having some keybinding
inconsistency.  Either of these could probably be overcome with some
effort, if it important enough to the developer.


> WHY they should merge.
> I don't want to go in predictions, that it seems pretty logical, that
> in the long run
>   - the community will choose one, and the other will slowly fade out
>     due to lack of applications
>   - step-by-step they converge, and reduce differences
>   - they merge

Why?  Vi and Emacs haven't merged.  Emacs and XEmacs haven't merged.  IMAP
and POP3 haven't merged.  They don't merge because the community hasn't
chosen one over the other.  The community doesn't choose one over the
other because they each have strengths and weaknesses that suit peoples
needs differently.  The same goes for CDE, GNOME, KDE and GNUStep.


> HOW they could merge.
> That's a tough question. Technically, I see a number of possibilities:
>  1) since both are GPLed, an gorup can take both, and merge them. But it's
>     very likely that such a group would consist of individuals who are
>     already involved with one of the projects.

The core GNOME apps and GTK+ library are written in C.  The core KDE
apps and Qt library are written in C++.  There is much resistance in both
development community to switching.  A code merge is highly unlikely.


>  2) gradually, more and more components become common (like font 
>     handling, screen savers, themes, internalization, etc.), and both
>     projects focus on their strenghts.

Half of your examples already are common.  Font handling is done by the X
Server; internationalization by gettext.  Themes are dependent on the
widget set, and won't be common unless the widget set is.  Screensavers
are trivial.  Many components have the same issue as point #1, GNOME will
write their components in C, KDE in C++, merging the code for a component
would be difficult.


>  3) prominant leaders from the two communities agree to converge and
>     merge (not very likely).

Nope.  It's the Mexicans vs. the Germans vs. the Bostonians (CDE) :-).


>  4) on of the projects gives up and acknowledges the other (extremly
>     unlikely, having in mind their considerable effort devoted)

Very unlikely.  Keep in mind that these projects both have considerable
momentum.  The momentum is not because of a large userbase, it is because
of a large DEVELOPER base.  As long as enough developers are working on a
project, it is very very much alive.

Look at GNUStep.  GNUStep has almost no press and very little userbase.
In fact a good chunk of their userbase has never heard of GNUStep (i.e.
your typical WindowMaker user).  In spite of this, they too have a
considerable amount of momentum.


>   I see (2) as the most probable, (3) the less coslty.

What I see as probable is (5) the protocols and components become, not
common, but standardized and interchangable.  The environments don't
merge, but it becomes easier to support either or both.


> Qt vs GTK+
> The main problem, which can't be overcome by 'gradual convergence', is
> the widget set. Which is better? Qt is supposedly better supported, now
> also free (but not GPLed, which is still perceived as a problem), while
> GTK+ is GPLed.  In nay case, changing the underlying widget set
> means a lof of recoding.

Which neither developer base has any motivation to do, so it just won't
happen.  As for which is better, people used to GTK+ seem to like GTK+,
people used to Qt seem to like Qt.  All this tells me is that both are
effective libraries, and neither has showstopper flaws.  So tell me, which
is "better", an apple or an orange?


> Balance.
> KDE and Gnome seems to be quite balanced in terms of their
> goals and functionality.  They aim at the same goals. The set of common
> features in much larger than the differences. They have about roughly
> support. That renders 'natural software selection' more difficult.
> 
> Recently, many users expressed their view that KDE and Gnome should
> merge (lus Linus, but he reportedly is not a GUI user). But users
> expressing views, without action, will not change things.
> So we need actions?

I have only heard a few users suggesting a merge.  I have heard many users
saying that either GNOME or KDE (or in some occasions, both) should go
away (these users often say it quite rudely as well).  The only vaild
argument I could think of for either a merge or going away, would be if
one project is hurting for developers because of the other's existance.
As this is not the case in the real world, I don't see any reason why
GNOME or KDE should do this.

   
> What next?

First, both GNOME and KDE have some immediate issues to be worked out
before continuing on.  GNOME is still too buggy and unstable for
primetime, and that is why the feature freeze.  KDE still has license
difficulties, and that's why they are apparently seriously considering
switching the core packages to en masse to the Artistic license (at
least this is what I hear from people who read the KDE mailing lists).

After both GNOME and KDE become viable in their own right, both systems
need some fleshing out in features, both can work on new ideas to push the
envelope of desktop environments, and we both should seriously work
towards maximizing interoperability.  There's no reason both environments
can't prosper. 


-Gleef