Repositioning the KDE brand

[Aaron J. Seigo]

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

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

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

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...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090702/2b647b55/attachment.sig>