[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: glib dependancy in KDE3.x
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2003-03-07 18:25:12
[Download RAW message or body]

   Hi!

On Fri, Mar 07, 2003 at 11:51:13AM -0500, Maks Orlovich wrote:
> Well, if user chooses a Gtk+ application and not a KDE one, we're not working 
> hard enough. Thankfully, I don't need to use any; and I don't see any reasons 
> why people other than artists (who may need gimp) would need to as well; 
> perhaps my needs are atypical, I don't know, but if they are, this sounds 
> like a good opportunity for you to point out areas that need work.

I am doing this: we're not working hard enough in cooperation with the GNOMEs.
The evil (that users choose Gtk+ over Qt) is created in two steps:

(1) some developers don't learn C++ fast enough to see that it is a really
    good language for doing things

(2) then, they work on GNOME, and there nobody will teach them what to use C
    for and what to use C++ for

Thus, a lot of _developers_ are convinced that developing GNOME applications
using Gtk+ is the best way of getting a free desktop environment. Thus, they
waste a lot of effort on compensating the weaknesses of C instead of using C++
where appropriate.

Thus I think we're not working hard enough in the cooperation/code sharing/
interoperability area, otherwise there would be much more users using KDE
and much more developers targetting KDE.

> > That is possible in the following ways:
> >  - depend aRts on Qt
> >  - depend Qt on glib
> >
> > I think if we were to evaluate these two alternatives carefully, we would
> > find that the second is more beneficial, because again its unlikely that a
> 
> Sorry? The second alternative is IMHO just unmaintainable code bloat, since 
> glib is completely and utterly useless when you already have Qt; especially 
> since in large part it tries to work around, and is hobbled by the 
> inadequacies of C. OK, it's the choice of people who want to deal with it, 
> find; but that's definitely *not* a good reason to pollute Qt code with stuff 
> like that.

What I mean is that we need to follow the embrace and extend strategy more.
For instance, a lot of users are still using gimp, mozilla or xmms. Gimp
provides an absolutely unacceptable user experience, because it does not
integrate smoothly into the KDE desktop.

This in turn happens because we don't have a way to use Gtk+ widgets and KDE
widgets in the same process. Otherwise, one could add KDE support to the GIMP
by adding a few KDE widgets (like the KDE file selector, toolbar, tabbed
docking interface), and thus eventually convince a few GIMP developers, that
KDE provides a better platform for continuing development of a graphic
application than what they currently have.

But this requires talking with GNOME developers a lot, to convert them one-
by-one into KDE contributors. The same is true vice versa.

GNOME and KDE actually are the same project already. Both of them are aiming
at providing a free and stable desktop development platform. Thus, all of
us should invest a lot of resources into merging them, first, and then
continue to improve the result. At least as other issues (like release critical
bugs) are not more pressing, I think merging KDE and GNOME should be top
priority for any KDE developer at this point in time.

> I am not convinced that it's the case for any things that are in any way 
> relevant to this list. I /am/ convinced that's the #1 reason for using C is 
> ignorance; since it's extremely rare to see someone asked about their choice 
> respond by something that's not complete nonsense, at least in my experience. 
> Again, I may have a bad sample.

You might be right. I am hoping I am making sense at least. And for anybody
that is not making sense from your point of view, I would recommend to you
that if he's working on GNOME, try to convince him: we really need to get
C++ accepted as least common denominator for all KDE and GNOME software, and
then interoperability will naturally arise, because people will not always
be limited to use a totally insane programming environment (plain C) if they
want to write interoperable code.

> > We only should support those users optimally that want to use whatever free
> > software is best for the job, without religious attachments to what
> > language, race, country, free software project, ... is best for the world.
> 
> Hmm last I checked our stated goal was to provide a consistent and uniform 
> desktop based on the KDE/Qt libraries; and a good modern development 
> platform, not to advance the free software ideology. Did I miss something?

Its much the same thing. The best way to provide a consistent and uniform
desktop based on Qt is to make it free software. And then you can also promote
the free software ideology where possible, because it helps you to get
contributors for KDE. In fact, Qt was made free software exactly because it
was the best way to develop a superior toolkit to make it free for free
software developers.

Thus, if you are asking yourself why KDE is superior to any piece of software
out there, or why it necessarily will end up being superior to any piece of
software out there, the reason is because its free software, and following
a very open development process.

Thus, KDE will eventually eat away all other pieces of proprietary desktop
software. Its just a matter of time. This can only work because its free
software. Since GNOME was founded with the same goal (free software ; should
kill all proprietary software), they will eventually completely converge
and be assimilated by the free software movement ;).

> [1] Since glib does use tables of pointers, it faces some of the same problems 
> we do with vtables, only on a smaller scale

I was not suggesting to use gobject-2.0. I hate gobject-2.0, because it
reimplements C++, poorly, so ideally you would not write any piece of
gobject-2.0 based software. The reason people still do implement gobject-2.0
based software instead of using C++ is indeed ignorance. Thus it might make
sense to work on lightening up this ignorance whereever possible, to avoid
people from following inferior software design to achieve their goals. Because
a lot of people have good goals (like for instance getting music software
running under linux), but quite a few are using inferior tools to achieve
their goals, and thus are wasting lots of "free software developer" man
power.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
[prev in list] [next in list] [prev in thread] [next in thread]