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

List:       kde-core-devel
Subject:    Re: Repositioning the KDE brand
From:       Alexander Neundorf <neundorf () kde ! org>
Date:       2009-07-02 21:18:30
Message-ID: 200907022318.30991.neundorf () kde ! org
[Download RAW message or body]

On Thursday 02 July 2009, Aaron J. Seigo wrote:
> 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. 

Really ?
I mean, I can kind of understand if they say they would prefer C over C++, but 
Vala ?!?!?!?
Even we didn't go that far to invent our own language...

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