Repositioning the KDE brand
Aaron J. Seigo
aseigo at kde.org
Thu Jul 2 22:04:53 BST 2009
On Wednesday 01 July 2009, nf2 wrote:
> I wouldn't slag off such a technology as "inferior", like Aaron does.
you evidently didn't understand what i wrote at all. i'm going to try again,
because this is an important point.
taking a working piece of software that's written using the clean, powerful
API of Qt and rewriting it with C, even with glib, is a step backwards. heck,
we try not to re-implement in C++/Qt stuff that works that is written in
C/glib. (just look at all the glib stuff we have happily adopted.) and yet,
that "throw away what works" attitude is what the "standardize on glib" idea
another problem arises when given a choice between writing something like a
system daemon with Qt-no-gui or with glib (and you can use multiple languages
to do either). if you wish to write it with glib, fine. but i'll certainly
find myself a lot further ahead with the Qt choice. (i'd argue most people
would, in fact, but that's not relevant either.) Qt shouldn't be precluded due
to some blanket edict; that will only erode good decision making and limit the
number of people who will work on the various pieces we need.
still, we constantly see some people pushing for the lesser road of
reinvention and preventing people from using the tools that work best for
them. that's what i mean by "inferior"; something can be really good, but it
can also be less good than something else out there. something can also be
really good for a given context, and be rather inappropriate in another or
the result of the current status quo approach is lost work, lost technology
and lost cooperation.
if you want a great example, just consider that GNOME People was proposed as a
blocker for Akonadi on fd.o despite People being a complete toy in comparison.
why? yep, it's written in glib/vala and so it "trumps" the Qt/C++ option for
some people. i really tire of dealing with that kind of situation as it does
nothing but work against the goal of a great F/OSS desktop patform. perhaps
you can understand why i find your suggestion of standardizing on c and glib
to be discouraging and dangerous.
or do you want to point out to me the c/glib equivalent of akonadi? and i mean
equivalent, not something that we will have to compromise features, power or
people need to stop fixating on the tools used to create solutions and start
fixating on the solutions that get created.
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel