glib in kdesupport: yes or no?

[Havoc Pennington]

On Mon, Mar 10, 2003 at 02:24:39AM +0100, Tim Jansen wrote:
> This is one theory. The other is that both projects compete until
> they reached the point where one of them has so many advantages that
> it becomes compelling to use it. Just like Apache and the NCSA once
> had similar market shares, or Linux and FreeBSD.
> 
> Important for reaching this point is the speed of development. If one project 
> wastes too much time with inter-operability work, and thus slows down the 
> work on innovative features that may be more important for users, this may be 
> the end for it.
> 

Or we might significantly slow down Linux on the desktop due to
user-visible fragmentation caused by the competition, and wasted
effort reimplementing apps that already exist but use the "wrong"
toolkit.

Or work on interoperability may be a key factor in the success of the
one that "wins" because of the WINE/VCL/etc. and docs/specs issues
that I raised. I know that there are plenty of customers and OS
vendors that want to see these issues taken into account and will
count it as a factor as they decide what to support.

Or perhaps we can architect the Linux desktop much better by doubling
the expertise involved. IMHO many of the shared specs we have are
better engineered than what each project came up with on its own.

I'm not impressed with the ability of either one to "win" anyhow -
some people have spent the last 4-5+ years hoping for that to happen.
I'm sure it'll happen someday, but I still think there will always be
multiple devel platforms, and multiple versions/iterations of each
one. So docs/specs and keeping things orthogonal/extensible remains an
important goal.

I don't even see why users shouldn't have choice.  Why shouldn't there
be an EWMH spec for window managers? You have always been able to
choose your WM on X. Suddenly removing that feature is lame, there's
no good reason to do it.

The issue is very much not just GNOME vs. KDE. There are tons of devel
frameworks and apps and even desktop shell components out there not
associated with either, that are still important and are unlikely to
become unimportant.

Havoc