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

[Adam Rotaru <arotaru cs sfu ca>]

On Tue, 22 Dec 1998, Gleef wrote:

> > 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.
   You're right. I also tend(ed) to see the world in binary. Maybe because
these are the two that expressly aim at becoming 'the de-facto Linux
desktop standard'.

> > 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.
   Yes, but there should be a minimal set of features that *all* options
within a level fulfil. Example: Some browsers can show colored tables.
Most of the browsers can show Gifs. All browsers can show HTML text. 
I'd like to see something similar in the desktop arena.
  It's good that Gnome has a start menu similar to the one in KDE. But
they should use the same settings!


> > 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.  

   Can a "KDE application" StarOffice CORBA-communicate with a "Gnome
application" Gimp, for example? Because they should. And they should
cut-n-paste, and drag-n-drop. So all these should be defined in a standard
way. That's important, and not whether it's written in C or C++.

> 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.
   
  Thanks for pointing that out. But this list *should* grow more!
OK, nobody disputes X. CORBA is a common denominator, but its
implementation is not. KDE uses mico, while Gnome decided that that's not
powerful enough, so they did ORBit. Internalization using GNU gettext is
agreed. But the integration could be carried further on the system level,
like a centralized, application-independent string repository.
  Window manager independent? Nope, KDE is not. This is a major
canceptual/design difference.

> ... and possibly having some keybinding inconsistency.
   Ideally, keybindings should be application and GUI-independent!

> 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.
   Vi and Emacs have different secondary goals. IMAP is more powerful than
POP3, but POP3 is more widely used. Also, one could argue that IMAP has
more objectives than POP3 (like storing the mails as well).  So similar
applications/protocols/etc with identifiable differences in objectives
can coexist happily.  But what if both entities try to become "the de
facto standard Linux desktop environment"?

> 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.
  Agree.

> Nope.  It's the Mexicans vs. the Germans vs. the Bostonians (CDE) :-)
   I didn't know about the Mexican connection.  The German one was
apperant quite quickly  :)


> 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.

  Indeed. This is the common view emerging from the replies
I got. But I already assign number 5) to the 'no getting closer'
possibility, so I'll renumber them, with your being 3) now, and getting
the 'most probable' attribute!
 
> 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?
   Is there any developer who actually programmed in both?

> 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

  All right, let's hope for an increasing interoperability, with both
projects alive.
  cheers,
   /Adam/