Interview: Aaron Seigo, KDE Project Lead (Sirius)

> GTK+ with freedesktop.org technologies *is* their desktop stack 

so ... which fd.o technology maps to phonon? solid? sonnet? threadweaver? ... for decibel
there is the tapioca stuff in gnome, but the kde and gnome works are based on a common spec
not just commond (let alone a cross platform integrated one), so it's a little like saying a
html widget is at the same level due to HTML being a w3c spec.

really what it comes down to is putting the APIs in front a developer and seeing what works
together, are coherent, deliver powerful desktop service integration, etc... this is one area
where KDE4 really shines already (and will do even more so with each passing release as
features continue to be added and bugs squashed in each of these frameworks). 

> Gnome-vfs libraries were made obsolete by gio/gvfs which lives in GLib.  

yes, this is a nice step, very similar in several ways to kio.

> So, to make a big distinction between Gnome applications and
> GTK+ applications is a bit of an anachronism these days. 

it's not about making a distinction between "gnome" and "gtk+" apps. it's about making a
distinction between "function that exists and is natively cross platform" and "function that
doesn't exist". i'm not making odd divisions here, but simply outlining some real differences
in features.

because unless i missed it (and who knows, maybe i did, feel free to point me to them) but i
haven't seen things like these frameworks elsewhere in the free software world presented as a
coherent, cross platform set.and that includes GNOME. 

this really shouldn't be a huge surprise since, just as with kio and the gvfs stuff, KDE is
often first out of the gate with various features. not always (see my comment below regarding
PolicyKit, for example) but often. to deny that is to ignore the actual history and timelines
of both projects. that isn't a knock on GNOME, btw; they have slightly different aims and
goals and their own interpretation of how to achieve them.

> universal APIs for which platform-native backends do the heavy lifting

only in part. this is mostly true for solid, much less true for phonon, threadweaver, sonnet
(which all add considerable value) and not accurate at all for decibel, akonadi, etc. which
implement things pretty much from the ground up.

> Solid, Phonon, and Decibel backends

solid, no; the rest, yes. people are working on the solid backends. 

> scrutiny of advocacy is also a good thing.

scrutiny is fine indeed. let's just keep it informed and civil. your comment here is a good
example of both qualities, so thanks for that =)

i *do* wish people could make positive statements that are factually accurate about free
software projects without other free software projects dragging them own. i do like how pgsql
and mysql, e.g., get along these days even though adherents of each feel their choice is
superior to the other. unfortunately in other areas such as the desktop or high level
languages (e.g. python vs ruby) it's all a bit "crabs in the bucket" at times.

for the record, i dislike it when kde supporters are similarly counter productive over efforts
in other teams. to the point where i have actually talked with some such people in person in
the past to sort things out. i'm fully prepared to not only learn from others but recognize
their successes, and i'd like to think others are capable of the same. =)

> Sneaking in potshots about the "other" desktop that flies 
> in the face of clear reality

in the interview, i  stated it as a plus found in KDE, not as a potshot at other desktops.

> justifying them via spin and semantic minutiae

i don't think that being platform native, integrating with platform specific frameworks,
moving the abstractions and support up from the realm of "builds, works, has widgets" to "has
broad desktop service integration" and doing it with a 100% free software platform qualifies
as "spin or minutiae". 

if you think it is (and it seems you do =), i would suggest looking at the code that has made
this possible and then consider your position again. the volumes of software that make this
possible are non-trivial, well thought out and compelling. i can understand how it is easy to
not realize the scope of the undertaking and dismiss it as "minutiae", but that is really not
an accurate appraisal of the results.

being able to say with 2 lines of code, "give me the number of CPUs on this system, now give
me a thread pool of that size" in a way that is both platform independent, easy to do (from
finding documentation to actually writing it) and that uses the system native facilities for
doing this is pretty impressive. and that's just one example of using just two of these cross
platform frameworks together (solid and threadweaver, in this example).

please, show me which other free software stack provides for that kind of of
feature/integration capability that is also consistent (e.g. not a patchwork of N different
separately sourced libraries) and portable. i don't think you'll find it, because it doesn't
exist outside today outside of KDE4.

i don't consider a widget and dialogs set, even if paired with nice things like xml parsing or
network stacks, to be a complete desktop stack. in fact, if you were to suggest such a thing
to companies that produce proprietary desktop systems they'd probably laugh and rightfully so.

being content with "well, gtk+/qt lets me run my GUI on these platforms" is simply not enough,
in the sense that we can do much, much better than that.

and it's not just the proprietary platforms either. a big reason there are so few f/oss apps
that have multimedia features is that it's so hard to do! the feature sets available vary from
Linux distro to Linux distro (not to mention the BSDs and OpenSolaris) and even the available
media frameworks are different between distros and over time. to me, multimedia is one
component of a desktop software stack, and i don't see another stack out there that is
portable and integrated in the same way that Phonon is in this category, allowing for things
like native DirectShow on Windows, QuickTime on Mac, GStreamer/Xine on
Linux/BSD/OpenSolaris/Windows/Mac (VLC and mplayer backends are also being worked on, btw)
with no client side code changes.

it's not a knock on anyone else's work in other areas to say, "hey, look what we've done
that's good."

if it makes you feel any better, i'm disappointed that we (KDE) don't yet have better
PolicyKit support in KDE and applaud GNOME for doing rather well with that in the GNOME
desktop. i don't feel it's a knock on KDE to recognize that work in GNOME in the least.
*shrug*

so there are strengths and weaknesses in all things. it so happens that the cross platform
desktop capabilities of KDE4 are simply one of its strengths. it really shines in this regard
due to its combination of Freedom, portability and completeness at the desktop services level
.. so expect people to be talking about it.

now, i don't expect you to be convinced by what i say here. you have already stated you don't
offer me much credibility. but i think it would be great for you to look further into these
matters as perhaps you will discover things you had not noticed up until this point. iow,
don't take my word for it, the code can speak more voluminously than i ever could.

I don't know the details, but here is what I know:
A few years ago a gtk application was an application which used gtk, a 
gnome application was an application which used gtk, the gnome vfs, the 
gnome config framework and the gnome component model (corba ?)

Is this still true today ?
What makes an application to a gtk or a gnome app ?

Alex

I think so too. I know I was one of the people who complained about the non-free:ness of QT
back in the day to the extent that I avoided KDE. But though I may wish that our platform
API:s where all licensed under LGPL, having QT under the GPL is not at all a problem for me.

I'm sure some of the people are still the same people who have simply decided to dislike KDE
(or get payed to dislike KDE), but I belive they are in a minority.

> although I have a vague memory that at least some of the KDE3 libraries were GPL, not LGPL,
but I'm no expert.

Nothing released as part of KDE 3( or 2 or 1)'s kdelibs module was GPL.  You may be thinking
of private GPL components that are not part of the platform.  

> Every major free desktop vendor 

and that's the problem I have with your line of argument.  You say free but you're talking
about proprietary development.  You're turning "Free Qt is GPL" into "Companies can't develop
legally with KDE".  There are precedents of companies performing proprietary development with
paid-for software, you'll agree, and there are also precedents of companies producing products
using GPL components.  Take NetworkManager or the Evolution client, for example.  Or MySQL, as
I said earlier.  But when it's Qt or KDE you perceive it as an insurmountable problem.

> Why bother?

My personal answer to this question is developing with the LGPL alternative is like performing
invasive dental surgery on yourself. In the dark.