glib in kdesupport: yes or no?

Havoc Pennington hp at redhat.com
Mon Mar 10 04:54:50 GMT 2003


On Sun, Mar 09, 2003 at 11:20:38PM -0500, Maks Orlovich wrote:
> > 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.
> 
> So when is the development for Nautilus, Galeon, gnome-panel, 
> gnome-control-center, and other similar apps is going to be stopped?
> 
> No, I don't really think that you should do this. I do, however, have a hard 
> time imagining a GNOME developer complaining about redundant apps with a 
> straight face. 

Keep in mind though - the problem with duplication is choice
vs. fragmentation, not the mere existence of duplication. As I said
before, people *like* choosing from multiple email clients. What they
don't like is say not being able to choose the best email client,
because of their choice of web browser. Or losing possible users due
to choice of devel platform. Or having to set up MIME handlers 6
times.

I think the open source community is inherently going to have 30
efforts in every category, just because there are lots of programmers
in the world and they all have their thing they want to try.  And in
fact users have different needs. That's not necessarily a problem in
itself, it gives users choice, and it gives us "failover" (if one
project fails we have others to pick up the slack). The problem is
when the stuff is not orthogonal/interoperable.

If the Linux desktop slows down due to duplication, it will be because
of fragmentation (because we had to provide feature completeness in
one fragment or the other rather than in some combination of the two
halves), not due to choice (if extra apps exist as an option, that
doesn't matter).

Concretely, if today a complete solution is Evolution + KOffice +
Mozilla, or something, then keeping people from using that, or
deliberately making the combination suck, while we wait for a complete
K/G-pure solution is not a good idea. Lack of interoperability would
keep people from using this set. Existence of other duplicate
alternatives would not.

It is simply not that hard to get good interoperability; the list of
todo items is very finite and very limited in size compared to the
full size of GNOME/KDE. In fact we've already solved more problems
than remain unsolved. I'm optimistic about our chances for that
reason.

Havoc





More information about the kde-core-devel mailing list