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:
> On Tue, 22 Dec 1998, Gleef wrote:
[snip...]> 
> 
> > > 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!

Well for one thing, neither has a start menu.  KDE has a K menu, GNOME has
a foot, and both are considerably more powerful than either Windows' Start
menu or the Macintosh Apple menu (or any other analagous application menu 
I'm not thinking of at the moment).

As for "they should use the same settings", it's a little vague what you
mean here.  I think that it would be a good thing if KDE and GNOME could
agree on a cross-environment way an application could add itself to either
application menu.  But something like this could be done as a shell 
script, they needn't share settings.

As for other "settings", one thing the GNOME Foot does (and I assume the
big K does also) is access the configuration of the panel.  Since the
GNOME and KDE panels operate very differently, something like that
couldn't and shouldn't be the same.


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

To my knowledge, not currently.  [Warning, I don't know enough about
CORBA, so the following description could be innacurate or misleading].
As far as I know, both KDE and GNOME wanted a faster protocol running on
top of raw CORBA for interprocess communication.  KDE produced KOM for
this purpose.  GNOME had a long delay before serious CORBA deployment, so
KOM was in use and able to be considered as a protocol, but it was
discarded because of certain design limitations that we did not want to
worry about; GNOME then produced Baboon.

I see two possibilities here.  One, if Baboon or KOM could evolve to the
point where it is clearly superior, it might be possible to port the model
to the other ORB and convince both projects to use the same thing.  I 
don't see this as very likely, but it is possible.

Alternately, a Baboon-KOM bridge could be developed so that KOM 
applications can use Baboon objects and vice versa.  I don't know how
feasible such a bridge would be, but it sounds like the sort of thing
someone will try regardless, and we should embrace it if it works :-).

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

Mico is a very powerful ORB, in fact GNOME did use Mico until ORBit was
ready. The problems with Mico for GNOME were:
  * It forced programs to be in C++
  * It is slow
  * Programs using it have a huge memory footprint
Since KDE has no problem with C++, it is easy for them to adopt Mico
across board, and work on improving its speed an memory footprint after
the fact.  GNOME's priorities were different, we wanted an ORB that could
handle C bindings, so we focused on writing a decent C ORB rather than
fixing the ORB that didn't meet our needs.


> Internalization using GNU gettext is
> agreed. But the integration could be carried further on the system level,
> like a centralized, application-independent string repository.

How?  An "application-independent string repository" would have no idea of
the context in which the string is being used, and so risks giving bad
translations often.  Gettext uses an application-specific string
repository, so that all translations are in context, and hopefully more
likely to be correct.


> Window manager independent? Nope, KDE is not. This is a major
> canceptual/design difference.

Both KDE and GNOME have a list of window manager requirements.  It is not
only possible to make a window manager as KDE-compliant as kwm, but I hear
one of them is actively working on it (I forget which one, tho).  Also,
regardless of whether or not the WM has full support, applications for
both KDE and GNOME will run under any window manager.


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

Absolutely, and you can blame the Open Group that they are not.  Since
they control both code trees, when they were developing a keybinding
standard, they could have put it in X rather than CDE.  But they
make much more money off of CDE than X, so we don't have an independant
keybinding standard.

Currently GNOME doesn't have a real keybinding standard.  We want one that
is cusomizable, for example, lets say the default cut/copy/paste bindings
for the American QWERTY keyboard are the ones from windows (C-X, C-C &
C-V).  For the Dvorak keyboard it might make more sense to have them C-Q,
C-J & C-K.  On a Greek keyboard it might be C-Chi, C-Psi, C-Omega.

 
> > 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"?

I don't think either GNOME or KDE's goal is to "become the defacto
standard Linux desktop environment".  GNOME's goal is to be a
completely Free, cross-platform desktop environment.  To quote KDE's
FAQ, "The aim of the KDE project is to connect the power of the Unix
operating systems with the comfort of a modern user interface."
Neither limit themselves to being a Linux desktop environment.
Neither have being a defacto standard as their goal.

In the Linux world, the desktop environment is not something that
needs a standard.  For 80% of new Linux users, they will probably use
the desktop environment shipped with their distribution.  RedHat and
Debian have committed to shipping GNOME.  SuSE and Mandrake have
committed to shipping KDE.  XiG has committed to shipping CDE.
Caldera will probably ship whatever seems best at the time.  Think of
it as another way distributions can get product differentiation, and
you'll see that there is likely to be a choice for a long long time.


> > 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  :)

Both Miguel de Icaza (our fearless leader), and Federico Mena Quintero
(graphics engine coder extraordinare and a core GNOME programmer) are
not only from Mexico, but they both went to UNAM.

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

I would think it would get very messy programming in either, but the
orange would be stickier.

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

Cheers,
-Gleef