From kde-core-devel  Thu Jul 02 21:04:53 2009
From: "Aaron J. Seigo" <aseigo () kde ! org>
Date: Thu, 02 Jul 2009 21:04:53 +0000
To: kde-core-devel
Subject: Re: Repositioning the KDE brand
Message-Id: <200907021504.54138.aseigo () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=124656875804833
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1288993.eejBgUEXNz"

--nextPart1288993.eejBgUEXNz
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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=
,=20
because this is an important point.

taking a working piece of software that's written using the clean, powerful=
=20
API of Qt and rewriting it with C, even with glib, is a step backwards. hec=
k,=20
we try not to re-implement in C++/Qt stuff that works that is written in=20
C/glib. (just look at all the glib stuff we have happily adopted.) and yet,=
=20
that "throw away what works" attitude is what the "standardize on glib" ide=
a=20
gets us.=20

another problem arises when given a choice between writing something like a=
=20
system daemon with Qt-no-gui or with glib (and you can use multiple languag=
es=20
to do either). if you wish to write it with glib, fine. but i'll certainly=
=20
find myself a lot further ahead with the Qt choice. (i'd argue most people=
=20
would, in fact, but that's not relevant either.) Qt shouldn't be precluded =
due=20
to some blanket edict; that will only erode good decision making and limit =
the=20
number of people who will work on the various pieces we need.

still, we constantly see some people pushing for the lesser road of=20
reinvention and preventing people from using the tools that work best for=20
them. that's what i mean by "inferior"; something can be really good, but i=
t=20
can also be less good than something else out there. something can also be=
=20
really good for a given context, and be rather inappropriate in another or=
=20
broader context.

the result of the current status quo approach is lost work, lost technology=
=20
and lost cooperation.

if you want a great example, just consider that GNOME People was proposed a=
s a=20
blocker for Akonadi on fd.o despite People being a complete toy in comparis=
on.=20
why? yep, it's written in glib/vala and so it "trumps" the Qt/C++ option fo=
r=20
some people. i really tire of dealing with that kind of situation as it doe=
s=20
nothing but work against the goal of a great F/OSS desktop patform. perhaps=
=20
you can understand why i find your suggestion of standardizing on c and gli=
b=20
to be discouraging and dangerous.

or do you want to point out to me the c/glib equivalent of akonadi? and i m=
ean=20
equivalent, not something that we will have to compromise features, power o=
r=20
maintainability with.

people need to stop fixating on the tools used to create solutions and star=
t=20
fixating on the solutions that get created.

=2D-=20
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

--nextPart1288993.eejBgUEXNz
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkpNIPYACgkQ1rcusafx20OfJQCdGKXCy6v+70HmvNnWCB248SdD
11kAn20kItW4TtNwNkSg9MRzV0fBDi+i
=+adN
-----END PGP SIGNATURE-----

--nextPart1288993.eejBgUEXNz--