LWN.net Logo

Interview: Aaron Seigo, KDE Project Lead (Sirius)

Interview: Aaron Seigo, KDE Project Lead (Sirius)

Posted Mar 28, 2008 18:47 UTC (Fri) by chr_reisinger (guest, #41249)
In reply to: Interview: Aaron Seigo, KDE Project Lead (Sirius) by ajross
Parent article: Interview: Aaron Seigo, KDE Project Lead (Sirius)

AFAIK Gtk on Mac requires X11. Qt 4.X and KDE 4.X programs are native applications, and Gimp,
Wireshark or Inkscape, arg Gtk+ and not Gnome apps.


(Log in to post comments)

Interview: Aaron Seigo, KDE Project Lead (Sirius)

Posted Mar 28, 2008 19:35 UTC (Fri) by alexl (subscriber, #19068) [Link]

Interview: Aaron Seigo, KDE Project Lead (Sirius)

Posted Mar 28, 2008 19:54 UTC (Fri) by ajross (subscriber, #4563) [Link]

Gimp, Wireshark or Inkscape, arg Gtk+ and not Gnome apps.

Right, this is the nitpicky distinction that annoyed me. By the same logic, .NET applications are not "windows" applications and Carbon applications are not "Macintosh" applications because they don't use the same set of toolkit libraries as some other applications that we already call "windows" or "mac" apps.

It's just silly. Sure, you can define the argument that way and be "logically" consistent. But it's fundamentally meaningless. Gimp, Wireshark, Inkscape, et. al. interact very well with the "desktop" in a cross platform way, and use the "official" Gnome means to do so. Pedantic argument about their "Gnomeness" isn't helping anyone here. These apps are first class citizens on a Gnome desktop, and arguing otherwise is just plain misleading.

Thus, my disappointment (sorry, Aaron) in seeing that kind of argument show up in print (metaphorically in print, that is), from a very influential source, and in a context where technical discussion instead of marketing spin would have served us all better.

KDE4 is cross platform now, and that's really cool. Sneaking in potshots about the "other" desktop that flies in the face of clear reality (I've known people who have been using Ethereal/Wireshark and Gimp on windows for years) and then justifying them via spin and semantic minutiae is very much not cool.

Interview: Aaron Seigo, KDE Project Lead (Sirius)

Posted Mar 28, 2008 21:27 UTC (Fri) by aseigo (guest, #18394) [Link]

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

Interview: Aaron Seigo, KDE Project Lead (Sirius)

Posted Mar 29, 2008 10:38 UTC (Sat) by jordip (subscriber, #47356) [Link]


And for the curious, the two lines aseigo refers to, are not a quick hack or a special case
but part of a larger multipurpose API
Should look like:

int procs = Solid::Device::listFromType(Solid::DeviceInterface::Processor).count();

Weaver::instance()->setMaximumNumberOfThreads(procs*2);

I can not speak about differences between KDE API and GNOME API, never used seriously none of
both. If someone can write some equivalent GNOME code, a silly comparison can be done :P.
I have used Qt and GTK+ and Qt really really beats GTK+. 

GNOME moves really fast (the 6 month release schedule was a great idea), it has a clean and
simple interface and it is pretty stable. If I had to deploy an corporate environment I'd use
it. 
But KDE seems like the future for me, in 4.1 and 4.2 the several WIP components will be put in
place. And starting from 4.3 (where I think things will seem mature) will be much better than
anything. 

gtk - gnome distinction

Posted Mar 29, 2008 1:10 UTC (Sat) by aleXXX (subscriber, #2742) [Link]

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


gtk - gnome distinction

Posted Mar 29, 2008 12:12 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

The distinction is becoming less meaningful over time as more of the "GNOME" technologies are
getting incrementally merged into base level libraries like GTK and glib. 

Refer http://live.gnome.org/ProjectRidley. 

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
Powered by Rackspace Managed Hosting.