We run into this misconception fairly regularly and it's understandable why from a historical perspective: KDE started out as a "desktop environment project". But come on ... we've only had a fairly clear distinction between desktop and applications for how many years now?
But wait .. it's not clear! Otherwise I wouldn't read stuff like this:
"Amarok sure inspires a lot of KDE-envy for Gnome users. Unfortunately, it doesn’t fit in well in Gnome: It’s written for a different desktop environment, uses a whole different toolkit, and requires a lot of extra libraries to run." - Free Software Magazine, article
The article goes on to pimp Rhythmbox which is all well and good. Use what you want, I say. Make educated decisions and you'll come out further ahead, I also say: If you're suffering from "Amarok envy" and it's the use of KDE libraries that puts you off ... it's time for a re-think.
Let's take the author's complaints one point at a time:
- "It’s written for a different desktop environment": no, it's not. It's written using libraries that come from the KDE project, Qt Software and a handful of other projects. It has nothing to do with a desktop environment, which is something you log into and not an application framework. If Firefox runs on Windows ... is it written for Windows? hmm....
- "uses a whole different toolkit": Sure does, and what's the problem with that? With Qt4, it blends rather seamlessly if you use the Qt4 Gtk theme style. Button order is even swapped on dialogs to fit in with GNOME's idea of proper button order. If you're worried about memory usage, unless you're suffering away on a machine with 256MB of RAM you're worried about all the wrongs things.
- "requires a lot of extra libraries to run": unlike Rhythmbox? *cough* Looking at Amarok's CMakeLists.txt it taps into taglib (very popuplar lib among various players), libgpod (which drags in glib and gdkpixbuf optionally), musicbrainz (Rhythmbox uses this, too), nepomuk, loudmouth, curl, libxml2, openssl ... in other words, stuff you probably already have on your system and of those you might not, are pretty tiny in and of themselves. The only exception to the tiny part would be the Qt and KDE libs, but having those around (and they aren't exactly huge in terms of disk space) opens up a lot of application options to you beyond even just Amarok.
So Amarok fits just fine, and does so on many platforms that are more exotically different from the KDE desktop than GNOME is. So why does this attitude persist?
It's tempting to just say, "Well, the person who wrote that article was obviously not qualified to write such an article." or "People who aren't down with the KDE project will grasp at any straw to make excuses for avoiding applications that run just fine elsewhere." There may even be shades of truth in there, but it's probably not the whole picture. Not only does it ascribe way too much actual intention to the probably honestly mistaken user, it avoids this bit of truth:
When it comes to public perception,
we hold our reputation in our own hand.
we hold our reputation in our own hand.
That is why marketing and communications exists as a discipline: to share with others in a convincing manner what your strengths are, what your unique points are, what your attributes are .. even what your weaknesses are.
So can we blame anyone but ourselves when people wander about saying and writing silly things like the above? No. Public perception starts with us. This does not mean it's a simple task, one we will always succeed at or one that can be accomplished in a day, a week or even a month. It's often a fairly arduous task that takes application over the long haul, but which in the end can be successful.
In this particular case, I believe we need to stop promoting the KDE desktop as "KDE". Now that we have a really solid application development platform, tons of applications (and application suites) that stand on their own as well as a desktop environment, it's no longer wise to keep the term "KDE" as a shorthand for "that thing you log into that the KDE team writes".
It's too confusing for the consumer, who gets tangled up in the distinction between desktop and applications. (In part, this happens because our integration is so terrific that it's obvious that these apps work well together, to the point that maybe they even require each other!) It gives people like the writer of the aforementioned article an excuse (and perhaps even a valid one) to further spread that confusion.
Quietly, I've been pushing for some changes here and there. At the beginning of this year, we changed the "What is KDE text", as can be seen in press releases and on kde.org: it used to say that KDE was a modern desktop environment, now it says that KDE is an international team that creates Free software. This change in language was not accidental.
Such subtleties are not enough, though. It's obvious and evident given the continued popular misconceptions about the relationship between the KDE workspace and KDE applications that it's not enough.
I've quietly floated a proposal to start using our public communication to make it much more clear where the lines are drawn. In particular, I want to see the KDE workspace marketed under it's own KDE sub-brand. Just as we have "Amarok" or "KOffice" as brands beneath the KDE umbrella (which is not the KDE workspace!), I want to see a brand for the KDE workspace applications so that we can refer to them as something distinct so as to clarify the waters around the meaning of "KDE". This can give us a base on which to build a clear and consistent set of lines around the dev platform (which probably also deserves a brand of its own), the workspace and the applications. They are all "KDE", they all work really well together, share so much technology with each other .. but are also separable and individually valuable pieces. The workspace itself really doesn't deserve to hog the name "KDE" to itself.
While these lines are all pretty obvious to most of us close to KDE, it's painfully obvious it isn't to the world just beyond our own village.
The Marketing Working Group have taken my proposal under consideration and have drafted a somewhat lengthy position proposition out of that proposal. I've been waiting for a bit to see it hit the light of day, though I must confess that every day that passes in which I read another article confusing "KDE" and "the KDE workspace" I grow a little more impatient.
51 comments:
There are some GTK+ apps I use, but I mostly use KDE/Qt apps.
In my opinion, I can't see how this author could compare the two applications, especially when Amarok wins many awards. Amarok is beautiful, and if I were him, I would be quite embarrassed to post screen shots of Rhythmbox, while dissing Amarok.
I am sure that if the review's author were using doing a review of Rythmbox from, say, Kubuntu or some other KDE-based distro, he would be saying the same exact things about all the gnome/gtk things needed. It is still sloppy reporting, though it highlights the perceptions some may have.
Subtle and not so subtle differences in behaviour between Gnome and KDE widgets, will mean that there will always be people trying to stick entirely to one toolkit or the other.
People who don't mind the small (mostly small) context switch that this requires will not care about the underlying toolkit. Fortunately Windows is a mine field of different toolkits and inconsistent control behaviours, so converts from there will most likely not even notice.
On the other hand, little things like buttons and combo boxes are consistent on Windows whatever the toolkit.
On the third hand QtGtkStyle will help there. If it's done right (I've not tested it), it could completely close the gap. If the NokiaTrolls missed out on some details, eg. default widget spacings and margins, then people will still notice the barely perceptible differences and continue to refer to KDE and Gnome applications under separate umbrellas.
I've heard, that instead of tray icons, new KDE apps will have plasmoids behaving alike.
Will these apps provide tray icons also, for cases like running outside of kde desktop ?
I agree that the article is really bad. However, there are still some major consistency issues with running kde/qt apps on gnome.
1. the QT4 gtk style is awesome. However, it is only available for bleeding edge users right now. This is just a time issue. Also some kde4 apps don't work properly with it. An example I had trouble with was dolphin. I couldn't get the gtk style to apply.
2. This is mostly an ubuntu issue, but it takes way too much fiddling with setting in order to get amarok to work with pulseaudio. The default gnome audio stack and the default kde4 audio stack (which amarok uses) are difficult to get to work together well. I would rejoice to see a single audio stack that kde and gnome would standardize on and eliminate these issues. I was hoping that having kde replacing arts and gnome replacing esd at the same time would have fixed this. A stable phonon backend for gstreamer will fix this.
3. I am not sure about this, but I think amarok/kde uses strigi, while gnome uses beagle/tracker. Having one desktop search daemon is bad enough. Two is terrible. I don't care how fast your computer is. Another possibility for standardization.
Disclaimer. I started with KDE, and now use gnome. I prefer gnome's emphasis on making stuff "just work". An example of this is amarok1's support of removable media. Amarok took fiddling, while rb just detected and used the media players. I understand that amarok2 and solid are fixing this. On the other side, I would love to see gnome rewritten in C++ with QT. About the same amount of work as the writing and port of gtk3. Perhaps we can get the linux version of QT4 released under lgpl?
Thanks for your work! I look forward to the day that gnomies can take full advantage of all of the wonderful work that the kde people do and vise versa.
@mxcl That's true. Actually the main reason I dislike new Gtk apps is the icons; obviously now that we have the same naming scheme for icons thats fixable too though. It takes some doing by the distros though.
However, I really do think Aaron is correct and that the main difference is a perception that we are mostly responsible for creating. (Perhaps combined with the OCD-ethic of some Linux users when it comes to installing libraries.)
Well, I've seen the same problem in Gnome-related articles/bloggs/forum posts so it's certainly not unique to KDE (for example, some people are under the impression that Firefox is Gnome app - apparently because of Gtk).
And as far as different toolkits go...I wouldn't go as far as to claim the different toolkits can be made indistinguishable from an end-user point-of-view so sometimes there is a point in trying to stick to one toolkit.
For example, right now on my system I have to deal with at least 4 different file selectors (KDE4, KDE3, Qt4, and Gtk) depending on the program used. No problem for me personally (even if it's a pet peeve of mine, and the reason why I try to use KDE4 based apps only as far as it is possible. Yes, even pure Qt apps tend to stick out a bit even if one disregards the fileselector), but a nightmare from a support point of view.
Okay, nightmare is probably too strong a word but I do think that a coherent environment is a BIG plus when it comes to general usability, and especially for people less tech-savvy.
@claydoh: "doing a review of Rythmbox from, say, Kubuntu or some other KDE-based distro, he would be saying the same exact things about all the gnome/gtk things needed"
which is an issue the GNOME team may want to do something about, or not.
Qt/KDE developers have done a huge amount of work to make things work well everywhere, and the marriage between desktop workspace and application is pretty thin. it's something we can help others to understand and thereby expand our audience.
@mxcl: "people will still notice the barely perceptible differences and continue to refer to KDE and Gnome applications under separate umbrellas."
i agree with most of your comment, but on this point i think it's useful to ask "which people will still notice?". i don't think it's the vast majority of people, and yet there's still this massive "KDE apps on KDE workspace, Gtk+ apps on GNOME workspace" mentality out there, primarily amongst GNOME users; it's a matter of popular "wisdom" not an actual issue people would care about otherwise.
visual issues also don't touch on the library excuses, which are just another aspect of these things.
i believe we can smooth this over with decent communication without diluting the workspace brand and thereby expand our audience.
(i used that phrase twice in this comment didn't i? *sigh*)
it's amazing how when someone says, "my excuse is foo" and you say back, "well, that's not really an excuse and here's some decent reasons why" that the first person will often reconsider their position, even if it is arguable to some finite point
(e.g. "is the spacing between the widgets perfect?" i say: "who cares? if you do, great, but most people don't. what's more important to you, a consistent 10 pixels of space in all windows (versus 8 in some places) or really great features that let you get the most out of your computer?")
it's really just a shame that people who offer such ridiculous detail items as reasons for picking application A instead of B are given enough merit in our community to be taken seriously in a "magazine" article.
@IvanIdea:
Desktop search applications are an example of something that does belong under the as-yet-unnamed "KDE Workspace". Like no one is saying that Gnome users should feel free to use Plasma; desktop search is similar (though there is there dbus standards that might make this less true).
As far as pulseaudio: we used to have a fine crossdesktop audio solution and it was called ALSA. :D PulseAudio issues are details though, probably phonon-gst helps here.
I agree with you. KDE has some awesome applications. I'm a Gnome user myself who often uses a KDE application here and there.
I also think this is one of your best blog posts ever! Keep up the good work.
The critical point though is that GNOME and KDE have co-evolved as mutually exclusive frameworks, sadly. I know that's not how it should be, or even how it is today _technically_ -- but that's the perception that occurred back during their early years, and that perception still exists.
Any casual computer user's mind is boggled when you mention there are two comprehensive desktop different environments for *nix. Especially when you see clones of applications between the two! "I really like this application that environment has. Why don't I have one on _this_ environment?" OR "Why do they have their own [GTK version of KDE program X]. Why don't they just use [KDE X]?"
Distributions don't help, especially since KDE programs are in distinctly different branches from GNOME/GTK ones. The average user wants to install Amarok. He doesn't want to know why he's having to install a completely different GUI.
The defacto reality is noncooperation between the environments on an application level (this doesn't apply to backends and libraries -- it's getting a lot better). But this can't be undone overnight by a few subtle text changes, but Aaron's right -- starting with changing KDE's own perception of _itself_ is a good place to start.
But as long as distributions continue to draw the line between KDE components and GNOME components, users will never feel comfortable about mixing them.
(PS. I personally run Amarok 1 myself under GNOME. Love it. Can't waiting for KDE 4.2.)
@ajuc: "I've heard, that instead of tray icons, new KDE apps will have plasmoids behaving alike."
you heard wrong. we'll replacing certain stand-alone systray icons with plasmoids.
for apps-with-systray-icons (a different class of animal) we want to transition from the current broken system to a better one that operates similarly but without the brokenness. we *should* be able to translate fairly transparently between the two.
btw, what does this have to do with this blog entry? =)
@IvanIdea:
1. it's mostly a timing issue, but then we have had the Qt Gtk style for KDE3/Qt3 as well.
2. yes, that is an ubuntu issue. Amarok1 and KDE4 as a whole are both able to adapt to media systems. forget about ubuntu not contributing enough to the kernel (or whatever today's grip is), when they can't even get their own distribution continuity together there's something wrong. they can get away with it because there isn't the expectation that it should all work together, which goes back to my gripe with with common popular attitude. people ought to look at amarok not working perfectly on ubuntu with default settings and say, "Ubuntu, you suck. There is no reason for this." instead, people just shrug and go, "oh well, it's a KDE app... i guess i shouldn't expect so much"
3. yes, we tend to use strigi. we have attempted standardization, the result in Xesam. go ask the individual search projects why they all feel the need to exist. beagle isn't an option for us and tracker really wasn't on the scene.
when used as a daemon, Xesam should be used, with the daemon being part of the "workspace". when used as an app-local indexer (e.g. as a sort of fancy embedded db) it's not an issue.
we could also talk about nepomuk here, but there is no analog for it outside of Nepomuk ... let's see if GNOME adopts it eventually or pulls a NIH.
"I prefer gnome's emphasis on making stuff "just work"."
this is a good example of what i mean when i talk about marketing and forming people's opinions. GNOME's tool hardly "just work" any more than anyone else's, but they've created the impression they do.
you give a supporting example of media players in rb (then acknowledge Solid, which is cool; Solid has already become much more pervasive in KDE4 than HAL or other such things in GNOME, btw)
but that's just one example. i could point you to printing configuration and support or any number of other issues. the GNOME team does good work in many places, but their Apple-alike "just works" mantra is more marketing than justified.
"Perhaps we can get the linux version of QT4 released under lgpl?"
perhaps consider that part of the problem with Gtk is that it's licensed under the lgpl and therefore has no business model to support it, something that a topic as boring and complicated as a toolkit probably needs to be top notch?
"I look forward to the day that gnomies can take full advantage of all of the wonderful work that the kde people do and vise versa."
nothing stops you from doing that today.
@jonas: "even pure Qt apps tend to stick out a bit even if one disregards the fileselector), but a nightmare from a support point of view."
the KDE file selector is now loaded in Qt4 apps. neat, huh?
as for nightmare from a support POV ... while not perfect, it's certainly manageable. there's a company out in Redmond who has this really popular desktop that has tons of popular apps for it which look rather different from each other in many wonderous ways. somehow they manage. ;)
@Jud: you win "best comment" award. seriously, you absolutely nailed it from start to finish.
and yes, if we can alter how we see ourselves first, then project that through our communication .. then maybe we can also get the distributions to adopt similar thinking as well.
""It’s written for a different desktop environment": no, it's not. It's written using libraries that come from the KDE project, Qt Software and a handful of other projects. It has nothing to do with a desktop environment, which is something you log into and not an application framework. If Firefox runs on Windows ... is it written for Windows? hmm...."
I know few people who would say that Firefox is written for Windows . The same people have said that if Firefox runs on Ubuntu, it is written for ubuntu and so on it is part of Ubuntu operating system.
And they even said that K Desktop Environment is written for Kubuntu Operating System because it is ported to Kubuntu and many other "Linux based" Operating Systems.
So as what they say, all you KDE developers are Operating System developers who work with hundreds of different Operating Systems.
Needles to say I started to laugh when I heard first time these words. I know that it is easy to say "Amarok is written for the KDE" because people does not exactly know what KDE is. Same as they dont know what is Operating System.
Mayby we should call KDE as Operating System or as Mediaplayer because it has technology for such things (Solid etc.)
The thing is, even when Qt apps make an effort to look like they fit in with a Gnome desktop, they still "feel" foreign. KDE users may make fun of Gnome devs and their HIG nazi-ism, but the fact is they've done a very good job of creating a bunch of apps that all look and feel alike. Rhythmbox and Banshee both fit in; Amarok most certainly does not.
However, I don't see the divide between "Gnome apps" and "KDE apps" as being a problem, or even a bad thing. To perpetuate a stereotype, Gnome users like things simplified, whereas KDE users like to feel in full control of everything. And that's fine. What we need to do, and what is now happening to an extent, is to allow as much as possible to be shared under the surface, to prevent too much duplication of effort.
What I would one day love to see would be a fully "Gnome-ish" GTK front-end and a fully "KDE-ish" Qt front-end both connecting to an "amarok-dbus-service". Who knows, maybe one day...
@Tristan: i absolutely accept there are people who love everything to be identical and perfectly the same. they should be free to keep their ordered little world in the exact order they wish. (i get it: i'm a little OCD myself and fetishize after design processes.)
but i do not accept that those people should be setting the overall tone and content of the conversation.
i do not accept that those people should insist that others do as they do, or else they are somehow doing it wrong.
that's the state we are in right now, and it's time the OCDers stopped running the asylumn.
your stereotypes represent a small fraction of humanity and i reject their validity as anything other than a personal preference a few of us share. most of our users are not at all like what you describe.
to add to the meme of 'who cares if KDE & Gnome apps work slightly different': I really can't imagine this being important. Windows users have to manage this all the time, and I've never heard them complain about it. The apps on their platform all work wildly different - even the ones created by Microsoft. Compare the UI of MSN, Explorer, Internet Explorere, MS Office, Wordpad, Mediaplayer... Each of them uses totally different ui paradigms. Yet everybody screams how usable windows is, and how much Linux has to catch up.
And about the 'gnome users like things simple, kde users like to be in control' - I think KDE 4 is already proving you can both have it simple & be in control. Sure, that's not everywhere in KDE, yet, but in many area's you'll see it's true.
Uh,
ok I think I disagree with Aaron.
Sure saying "It's written for KDE" or "It's as KDE application" is a somehow missleading simplification.
But it is propably the best one we got for widespread use.
OK, the reality is: There is something like the "KDE plattform", which is KDE libs+kde runtime. It uses Qt4.
On top of that there is the KDE workspace as well as the applications. And that is the point: Apps and workspace can used without the other.
The correct statement for apps so should be: "It is written for/with the KDE libs/plattform which make it integrate well with the KDE desktop/workspace but it also works great on any other desktop env."
Does that make anything more easy?
No. This fact is quite well known. I know a few Ubuntu users with Gnome as desktop. They install KDE apps without even thinking about such things.
People who really care are the ones who know the difference between KDE workspace and the unterlaying dev plattform. They are powerusers.
Most of them like either KDE or Gnome for their great integration of apps into the desktop.
I only use non KDE apps when there is no other option. Thats because my workflow depends on things like KIO. Or the favorites in the KDE file dialog which well link to sftp servers and so on.
There are more examples. (kwallet i.e). Only KDE apps give me the full power what KDE as a whole is.
Apps and workspace are not the same but to get the most of it you have to use them together.
So for me it is "It is written for KDE but and/but runs on every desktop/workspace" is more or less correct, when you want something simple enough which still emphasizes that KDE apps and desktop are a good team.
Integration is what KDE makes different and unique. Everone knows already that you can use KDE apps and Gnome and the other way.
So what really needs to be done is work more closely toeghter with Gnome.
But as long there differences in Gnome and KDE, things in KDE which Gnome doesn't provide (and well, I hope that will be for a long time) most people will always prefere KDE apps on KDE workspace.
A little change in marketing will not change that. It either will get ignored but average users which already now are using KDE apps on Gnome without even thinking about it or it will promote things already known by power users.
But it will not change the integration "problem" (its KDEs strength don't hurt that in marketing)
And go to #kde you will learn that even for average Ubuntu users it is vital to somethimes understand that a KDE app is a KDE app.
From time to time there is the question how the KDE settings app is called, because they are runing Gnome and a KDE app. Some settings for them are in "system settings"
So maybe the best we can get is "Amarok is written with KDE technology, runs everwhere where you can get KDE libs and works best/its optimized for KDE workspace/desktop.
I just prefer "Amarok(or xyz) written for KDE" and on websites targeting a unexperienced users with the additon: "but runs on every other desktop like Gnome or even Windows"
So only change marketing things when they don't harm the understanding of KDE as well integrated plattform.
@DanielW: "This fact is quite well known."
so then .. why did someone come into #kde just last week and ask if Krita would run in GNOME?
they weren't a power user, but they were at least aware enough to know about IRC.
and then we have the example of person who wrote that article for Free Software Magazine.
i really think it's time for us to pull our heads out of the sand (i know, it's warm and comfortable and we all know each down there =) and honestly assess what the world around us actually thinks about the KDE brand. not what we think about it, not what we want them to think about it ... but what they actually think about it.
"Integration is what KDE makes different and unique."
that's definitely a big part of it, yes.
"So what really needs to be done is work more closely toeghter with Gnome."
the entire FOSS desktop ecosystem should work more closely together. that's a separate and orthogonal topic, however.
"But as long there differences in Gnome and KDE, things in KDE which Gnome doesn't provide (and well, I hope that will be for a long time) most people will always prefere KDE apps on KDE workspace"
only if those difference rely on the workspace. there are many that are completely, 100% and wholey separate from the workspace.
you sort of make my point here that confusion in this area exists ;)
"But it will not change the integration "problem" (its KDEs strength don't hurt that in marketing)"
this isn't about downplaying integration, it's about destroying the myth that the apps are locked into the KDE *workspace* (plasma, kwin, etc).
we will always promote the workspace as well of course. (hell, that's where i spend 90% of my hacking time, so i hope so! ;)
we just shouldn't promote the workspace as the all or nothing thing it is currently widely perceived as. the idea that "the workspace *IS* KDE" is one i find pretty disrespectful to all the libs and application developers.
so what i'm proposing is that "KDE" is an umbrella under which a whole universe of software exists: coherent application development libraries, a modern and innovative workspace and several suites of really impressive apps. those things are all equally KDE ...
think about in terms of Microsoft Windows, Microsoft Office, etc. or Apple Mac, Apple iTunes, Apple iPod.. right now we have KDE KDE (platform + pillars), KDE KDE (workspace), KDE KDE (included apps) and KDE KOffice/Amarok/etc (which try and stay away from getting too stuck to the KDE label, and guess why?).
i hope you can agree that KDE KDE, KDE KDE and KDE KDE is a pretty stupid naming scheme. the confusion that ensues is pretty expected at that point ;)
i'd much rather see "KDE" be used only as a the umbrella brand and not use as a synonym for any specific part.
"it is vital to somethimes understand that a KDE app is a KDE app."
i'm not suggesting brand dilution or anything that would lead to that. it's not about downplaying the KDE brand or the connection between KDE and applications. the idea is to *properly position* KDE as the umbrella brand which means separating it from being synonymous with the workspace and app devel platform.
then it's much easier to much more accurately and even vigorously promote the KDE connection.
"So only change marketing things when they don't harm the understanding of KDE as well integrated plattform."
agreed, and it's not what i'm suggesting in the least.
I like the idea of using KDE as a cover term for the community and all the projects and using something else for the desktop. However, KDE Workspace is not distinct enough.
How about Plasma Containment Something? (Replace Something with a meaningful noun.)
@Arisztid: "KDE Workspace is not distinct enough."
i agree; i just didn't want to suggest a name until there's at least consensus on the idea that we need one.
i can only paint so many bikesheds at once! ;)
There is a second problem, which I'll describe in a second. (Er...ha.)
I'll admit I consider myself smart enough to get this Linux stuff to work, to fix problems when Fedora breaks, and to compile stuff.
But even I (maybe a typically competent Linux user, sub-developer class) wonder with a pinch of doubt if I can actually run such and such a KDE application under GNOME.
Amarok is a good example. I know the system updates pull in the necessary dependencies, but it leaves a few out, too, like Python-KDE3 and a few other libraries very handy for that application. I've learned which I need, but I had to do it manually, only trusting the system to do 75% of the work.
As long as that's the case (and I figure OpenSUSE's package management -- since they're both RPM -- is comparable in competency) I wouldn't expect ANY user to feel comfortable trying to add KDE apps, piecemeal, to a GNOME system.
So this is the second problem. Can KDE apps run outside of KDE? Certainly. It's more than just a desktop environment.
But maybe that's a problem too. You can't treat the apps as both DE-agnostic and especially customized for one DE (that is, KDE) at the same time. A sort of Janus view of them, if you will.
Sure, the KDE framework can work under any environment. But the problem is, it's radically different from any other environment -- KIOslaves in particular. Trying to manage files in Nautilus while watching Amarok monitor them using KDE libraries that may or may not work with Nautilus, is a little nervous. Forget about simple things like trusting in Drag-and-Drop, or copy and paste. I end up using a sort of barebones functionality -- because quite frankly, GNOME isn't KDE, and KDE is where KDE apps are meant to thrive.
So to develop truly DE-agnostic KDE apps...I don't know how I feel about that. Do you _want_ the benefits of an integrated environment, or not? You may not be able to have it both ways. Trying to expect completely different desktop frameworks to get along with each other is a gargantuan task, and it occurs _nowhere_ else (as far as I can tell) in computing than under Linux. If you try too hard for interoperability, you lose essential pieces of the user quality experience -- because let's face it. I've never heard of a developer of a KDE application foregoing KDE framework components to use GNOME ones for his GNOME audience.
Windows. Sure, there's QT and GTK and all sorts of libraries and frameworks ported, but pretty much, they all run on top of Win32 API. Copy-and-paste is going to work. If you want it to work on Windows, you have no choice but to...well, make it work with Windows.
But with Linux's fragmentary DE beginnings, there is no such luxury. I can easily understand the trepidation of those who feel uncertain mixing both environments.
I am sorry for this post, but I think it's pretty accurate. It may be unrealistic to think that the KDE ecosystem can nurture both KDE-specific and not-really-KDE-at-all (KDE-lite?) apps at the same time, without diluting the value to the end user.
Or, put another way:
There is not a clear distinction between which apps are VERY integrated into KDE, and which are not.
And if there was...would it be worth it for the KDE world to maintain two different sets of apps?
That is what must happen. You'll notice that KDE tries very hard to port it's entire framework to Windows, to Mac OS, etc...
You know what it doesn't port to? GNOME. It's mapping the frameworks to other environments, but not GNOME. (Not to defend GNOME -- they don't go the other way, either).
But that means you're not even trying to directly integrate with GNOME (not freedesktop -- GNOME specifically!) frameworks (like mapping KIOslaves to GVFS -- it's probably not even possible!) and GNOME applications (like the address book).
That's why, I think, for the immediate future, KDE and GNOME apps will always run like second (or third) class citizens in the other's environments.
I can't blame that decision. But it's an important reason why integration efforts will only go so far as long as you specifically IGNORE integrating intentionally into GNOME, or deintegrating from KDE-specific frameworks.
A desktop-agnostic KDE application may be an oxymoron.
@aaron:
Ok, you are right. Making the three(?) parts more distinguishable and clearer communicate these things could help.
I think I missunderstood you because most of the other comments where about using GTK apps with the KDE desktop and KDE apps with the Gnome desktop.
There is even an other layer of confusion. People often see parts of the kde-* modules as being KDE and extragear-* not being KDE.
I also think having the KDE workspace/desktop in the same KDE module (kdebase) as parts of the plattform is not helping here. kdebase-runtime and kdebase-workspace should propably somehow get reorganised.
And yet you are right there is confusion. I told some of my Windows using friends, that they can/will be able to use KDE on Windows.
I should have said: "You will be able to use KDE apps on Windows"
But for that one need to know what a KDE app is. And I think that should be well known. So when some website writes a review they clearly should say it is a KDE app or it is written for KDE +(something) .
Their is another problem. When one say a KDE app it could again mean two different things:
1. A application written using the KDE technologies
2. A application made and released by the KDE project public represented by the e.V. (that normaly implies 1)
An example for 1 would be krusader. For 2 Amarok, K3B, Dolphin ...
That distinculation is not that importent only in where to get support, where to report bugs...
Btw: Krusader website says:
"Krusader is an advanced twin panel (commander style) file manager for KDE and other desktops in the *nix world"
That is also mixing things but at least makes clear it can be used without the KDE desktop...
You would like to see that changed to something like
"Krusader is a an advanced twin panel (commander style) file manager written for the KDE platform and can be used with any desktop" ?
I don't think that is really better...
Btw: Gnome is doing it better as KDE already in communcation:
From there What is Gnome page:
"The GNOME project provides two things: The GNOME desktop environment, an intuitive and attractive desktop for users, and the GNOME development platform, an extensive framework for building applications that integrate into the rest of the desktop."
http://www.kde.org/whatiskde/ tries to say the same. But I think it could to better.
But all that will not change the fact that Gnome (and other desktops) users will stay away from using KDE apps if there are similar "native" apps, even if they otherwise would like the KDE app a little more.
At least for me that is true in the other direction.
And now I feel like writing a lot, but saying nothing...
I had one good point when I started writting this but it forgot it :-/
There is definitely a KDE development platform, I know that.
But it doesn't directly integrate into GNOME, only indirectly (and arguably not so great).
KDE is trying hard to directly support Windows and Mac OS.
But on Linux, it's like Israel and Palestine, so to speak -- KDE and GNOME both want to be treated as respectable entities by all the other desktop environments, but they won't recognize and directly work with each other.
Rather, they only work _beside_ each other, in a way where what common interoperability they support is never specifically made clear.
(I really do apologize for posting so much. I have thought about this for some time.)
@Jud: all KDE applications are very integrated into "KDE"; and there we go with the taxonomy problem.
your example of managing files with Nautilus while Amarok monitors them is a good example: both applications work with the operating system underneath. neither has their own special file system kernel driver (to take it to the absurd ;), and so when you move a file with Nautilus, Amarok sees that move.
mapping gvfs<->kio shouldn't be necessary at all for this very reason. as long as we use standardized URIs and rely on the operating system to do the operating system's job (such as provide file watches), we're all good.
as for things like address books and what not .. there is fragmentation there, indeed. this doesn't matter one wit for applications like Amarok, Okular, etc, though, does it? nope =)
i'd love to see the GNOME project adopt Akonadi (as do some of their own, as a matter of fact, so there is hope! =), and then the address book issue would be one more thing behind us.
but again, the integration issue is a separate, orthogonal (though important) issue. just because two apps don't use the same addressbook doesn't mean they can't be run side by side.
the fact that when you use a bunch of KDE apps together you get really tight integration bonuses between them is a benefit of using KDE technologies. but it's a bonus, and extra, an additional reason to use them. it says nothing about using only one or two select ones, and it indeed says next to nothing about the workspace they run in.
with KTorrent in KDE4, you can drag and drop torrents to plasma and get cool desktop widgets. sure, you don't get that if you run it in GNOME or KDE3, but otherwise it manages torrents just wonderfully.
somehow the added bonus of integration has come to be seen as part of that all-or-nothing deal. if you don't use the integration features, the apps aren't worthwhile.
while there are probably a couple apps like that out there we could point to, the majority aren't like that at all.
and the workspace in particular is often the most agnostic piece of all: nearly all the integration happens at the library level, not the workspace level. plasma is changing that, but those pieces are still just bonus features.
Good thinking Aaron... now, persuade app authors to get rid of all the damn "Kthisthatandtheother" names and you'll be getting somewhere.
That and the python tendency to "PyFooBarBaz" really get my goat. Actually the Py* stuff is worse, as there is never any reason for a simple user to care what language their favourite tool/app is written in.
With the Kapps, there might once have been a reason for the "Knaming". Now, however, it's annoying and I think actively harmful - as it promotes the attitutdes you're talking about here.
@DanielW: "People often see parts of the kde-* modules as being KDE and extragear-* not being KDE."
yep. another thing to improve on.
"I also think having the KDE workspace/desktop in the same KDE module (kdebase) as parts of the plattform is not helping here. kdebase-runtime and kdebase-workspace should propably somehow get reorganised."
yes! step one was to move those pieces into runtime, workspace and apps. (much easier to reorganize inside of kdebase first; i wasn't confident we'd get support for dropping kdebase and creating three separate modules before we proved the runtime/workspace/apps split)
step two will be to move them into their own modules, probably when we switch up the vcs we use (e.g. to git).
but yeah, you're getting the picture very clearly here =)
"When one say a KDE app it could again mean two different things:"
yep =) this one is harder to solve, though, and i'm not sure we have the resources to do so. thankfully, as you note, it's mostly limited to bug reporting and what not.
there may be some reflection on the quality of the KDE brand by these apps, but i don't think it's a huuuge issue at this point.
"Btw: Krusader website says:"
yes, that's pretty common actually. shows that such clarification is needed.
"Gnome is doing it better as KDE already in communcation"
yes, they've been promoting a split amongst their offerings for a while now. they have had the benefit of a more marketing oriented culture combined with lower integration levels. those two things in combination helped them clearly recognize and communicate they have different components.
but GNOME doesn't have proper names for the different pieces either. so while they've done a better job, they are also in a similar situation. the whole "GNOME Mobile" thing muddies it even further for them, really. what *is* a "GNOME based device" and what does that mean in relation to "GNOME" (the desktop)?
"But all that will not change the fact that Gnome (and other desktops) users will stay away from using KDE apps if there are similar "native" apps, even if they otherwise would like the KDE app a little more."
probably, at least for some. i wouldn't assume it would be a majority of them, however, and i'd especially look to other platforms like Windows and Mac where this clarity in messaging will be even more important, or as we embark into the mobile space ourselves ...
@Arisztid: "KDE Workspace is not distinct enough."
Plasma?
Akonadi with the Evolution data server in GNOME would be fantastic.
I second the "non-stupid-K-names". One of the things I love about KDE 3.5 is the ability to change the Application names system-wide to their Description names.
So for example, KSnazzlePages becomes "Address Book" just like it ought to. (I know, the names aren't really that bad. :) -- ...Well, okay, some of them actually _are_...)
It would be wonderful if that kind of aesthetic was prevalent throughout KDE4. For example, if Kicker had an option to NEVER show the real App name.
Instead of "Amarok / Music Player", I'd merely see Amarok, or perhaps Kicker could use the second line of text for the tooltip description "Music Player / Manage and play music." Much more pleasant.
One thing I would love -- the KNotify alerts! If only they could use the Description name as well. So I would have popups from the "Music Player" and "Messenger" as opposed to "Kopete" [never got that name either.]
In addition, it would mean that if the default KDE programs were changed (ex., Banshee for Amarok) -- the end user naming aesthetic in menus and notifications is still consistent. Helps very much with integration.
I think _that_ would be an excellent way to improve usability of GNOME apps on KDE, for example. And even KDE apps on KDE. :)
@IvanIdea
Phonon has xine and gstreamer backends, and and they both can play nice with PA, either directly or with PA's fake alsa interface. Theoretically, it should be pretty simple.
@Tristan
What I would one day love to see would be a fully "Gnome-ish" GTK front-end and a fully "KDE-ish" Qt front-end both connecting to an "amarok-dbus-service". Who knows, maybe one day...
You mean like XMMS2 and MPD? Yeah, I know they don't (yet) do everything Amarok does. But as they start maturing, maybe we'll get there.
> "It’s written for a different desktop environment": no, it's not.
> It's written using libraries that come from the KDE project, Qt Software and a handful of other projects.
> It has nothing to do with a desktop environment, which is something you
> log into and not an application framework.
Sorry, I have to disagree on this one. It's not the libraries that matter, but *shared configuration*.
I get quite a few questions from users who are running running KMess 1.5 (a KDE 3 app) under GNOME.
It's about things like:
- preferred browser setting is ignored. (we had to guide people to install kdebase, or hack ~/.kde/share/config/kdeglobals to fix it)
- list items have single-click to activate them.
- sounds are not playing. (people have to install kdebase to get KControl to configure artsd)
Slightly related:
- no "now playing" information for Gtk-based players (fortunately being fixed with MPRIS)
- GNOME taskbar doesn't seam to blink on notifications (?)
The library doesn't matter indeed, and sharing all configuration would be impossible. But there visible settings could be fixed. For the same reason I try to use as much KDE apps as possible, but that's a poor situation to begin with.
@jospoortvliet: Windows is indeed a mess of toolkits, and different visual designs by Microsoft. :p They do get one thing properly shared: fonts and widget colors. That alone makes most toolkit differences invisible for people. I'd love to see Linux adopt that.
@Diederik: KDE3 is not KDE4 =)
single click comes from the style (so using the gkt qt style addresses that issue)
phonon solves the multimedia issue (well, at least on our end, distros still have to make sane decisions; but in kde3 that wasn't something they had the freedom to do)
i tried to fix the preferred applications settings some two years ago but the GNOME developers refused. it was in a face to face meeting sponsored by red hat out in boston; i was less than impressed.
so other than that item in your list. we've done what we can to fix these these things (and i have half a mind to just implement the preferred apps solution i had in mind in kde whether or not anyone else actually takes advantange of it)
so now that kde4 is this wonderful flexible beast ... i want to see our marketing match that.
Just with regard to Aaron's comment above about OCD.
I would just like to express my opinion that while obsessing over minor GUI problems can cause unnecessary problems, it can also fix many problems. In terms of being OCD about GUI design and pervasiveness - I think its critical to widespread acceptance. To use an overused example, look no further than Apple. One cannot argue that they have consistency of GUI design, and this is a real selling point for Apple. All common people agree that Apple 'looks the best'. I just felt that Aaron was perhaps lowering the importance of exceptional GUI design and pervasiveness. I may have mis-read you Aaron, but I feel its very important. And I think my opinion is backed by popular vote.
BTW Aaron, great post, I loved it.
I've already integrated it into our discussions about KDE's web presence and online community over at #kde-www. I feel that this would be our most effective medium to improve a proper perception of KDE.
@Sam: OCD is great for some things (design, as you note) but can really get in the way of others.
very few things in life are universally good or universally bad, and OCD is no different.
i'd also be wary of overstating Apple's popularity with their single digit market share. the iPod is their only truly killer product; their computers are growing in sales but it has very little to do with their interface consistency ... nor will i go into just how consistent their interface is or isn't =)
@Aaron,
"the KDE file selector is now loaded in Qt4 apps. neat, huh?"
VERY neat! Just a question: since when? Or is this slated for KDE 4.2 (or a later Qt version)? My installation of KDE 4.1.2 using Qt 4.4.2 certainly does not (well, it does work like that in smplayer but that is the odd one out) behave in that manner.
As far as manageble goes, well. That depends on what you mean by manageable. Neither Windows (whatever version you compare with) or MacOS X is ideal in the consistency department either. It is rather ironic that not even Microsoft's own programs can stick to one UI paradigm...programs using the KDE framework are doing a lot better in that regard for sure!
And I wouldn't be honest if I didn't say this: my pet peeve grew out of the frustration of having to try to explain why a ftp/smb/nfs shortcut available in Kate and Dolphin is not available in Scribus, Inkscape and Gimp a couple of dozen times more than what's healthy for my blood-pressure...or to the users I'm doing my best to support (using KDE 4.1.1).
@IvanIdea:
ad 1. (QGtkStyle), blame your distribution, Fedora 9 ships a qgtkstyle snapshot in the stable updates.
ad 2. (PulseAudio), that's also a distribution issue (as you correctly guessed). Fedora sets up PulseAudio by default even in KDE. Amarok works with it just fine. Interestingly, Phonon-GStreamer is the one package we're having problems with at the moment: while GStreamer supports PulseAudio just fine, and you can set up Phonon-GStreamer to use that if you know what you're doing, it fails to work out of the box (and the relevant setting is not exposed in System Settings). So for now we're defaulting to Phonon-Xine and we'll be working on fixing Phonon-GStreamer.
@Aaron:
> the KDE file selector is now loaded in Qt4 apps. neat, huh?
Even if the app isn't loading the KDE 4 libs at all? Doesn't that override only work if the app is already linking in kdelibs?
"the KDE file selector is now loaded in Qt4 apps. neat, huh?"
Yes, especially seeing the KDE file selector in Qt Designer using the Cleanlooks style is very neat. :( I'm a GNOME user, but I work with Qt. I installed KDE4 out of curiosity, and the KDE file selector made me uninstall it. It should be really tied to the Oxygen style, not overwrite it globally.
@Nick "Good thinking Aaron... now, persuade app authors to get rid of all the damn "Kthisthatandtheother" names and you'll be getting somewhere."
I dont see K used in name stupid. In contrary it is informatiove that Application is using KDE libraries.
As long the applications does not have backend and frontend and frontend could be coded for Qt or GTK+ etc, the naming should not be samekind.
Gnome started first doing this by leaving the G off. But it just ended up there that many users does not know wich one it is. So Package managers should now tell right away witch toolkit application use if you dont reconigze it from name.
So K is not stupid, if it is well implented like Amarok and Krusader.
What Krename should come? just a "rename"? What does "Cheese" tell for user? No one has never ever got idea it would be Gnome's webcam software. Everyone has tought it has someting to do with food.
The Application name should tell right away what it is. This does not fit for Dolphin (or Krusader and Amarok) but it should. But because we can not have 50 different application named as "File-manager", we need to have personal name, what again is against usability.
So, why not call the default applications as "Kfilemanager" and "Gfilemanager"? Much better than "Filemanager" and "Filemanager" or "Dolphin" and "Nautilus". (have you notices both filemanagers has something from "sea"?)
I like KDE because it is well integrated. Because when you make applications by using KDE libraries, you get powerfull applications. Even that it would be used by Gnome users.
@Kevin Koffler: yes, that's true; the app does need to pull in the libs, at which point all qfiledialogs magically become kfiledialogs
@luks: you had the kde widgets loaded in designer, didn't you? =)
in any case, it's impressive that you prefer the Qt filedialog ...
@ZeroUm: "Plasma?"
Yes, Plasma would be probably a good name for KDE Workspace but then Plasma proper should be renamed Plasma Shell or something like that.
but then what about plasma on the screensaver? plasma-mid? other future plasma shells?
@chani: perhaps something like: "Plasma Desktop Shell", "Plasma for Mobile Internet Devices", "Plasma Screensaver Widgets" ... doesn't exactly trip off the tongue, but then i don't think these are names the user will ever need to concern themselves with.
KDE4 has a unique name for its workspace: Plasma. Most of my friends will not confuse KDE with the KDE workspace.
Some questions: will Firefox, use Kwallet to store passwords? will Firefox add RSS feed to Akregator? Will Firefox use Proxy settings in KDE3 Kcontrol or KDE4 systemsettings? the answer is no, no and no.
Then we could say Firefox is not KDE application and "it is written for a different desktop environment, uses a whole different toolkit, and requires a lot of extra libraries to run."
And that actually is the truth.
It is okay to indicate Amarok does not fit well in gnome, however, it seems that amarok uses no KDE-workspace-specific features. That is the point.
@pansz: "KDE4 has a unique name for its workspace: Plasma."
yes, this is new with KDE4 .. we don't always reflect this reality yet in our marketing though ...
"Most of my friends will not confuse KDE with the KDE workspace."
that's good news =)
"Then we could say Firefox is not KDE application"
correct
"and "it is written for a different desktop environment,"
it's not really written for any specific desktop environment. then again, neither are KDE apps.
all the features you mention where firefox doesn't integrate with the KDE dev platform are not desktop environment issues but library/framework issues.
" uses a whole different toolkit,"
which is pretty well totally irrelevant to most users, so why bring it up?
"and requires a lot of extra libraries to run."
not really; it uses things that were already on my system. =)
"It is okay to indicate Amarok does not fit well in gnome,"
that's a matter of opinion, not fact.
"however, it seems that amarok uses no KDE-workspace-specific features. That is the point."
it's certainly an important point, yes.
Having spend several hours to read all the comments. I am surprised to see so many changes in KDE4 simply to make KDE apps run better in other desktop environment.
Well, instead of spending efforts on making KDE apps run better in non-KDE, Why not spend more efforts on making non-KDE apps run better in KDE?
If most great non-KDE apps run better in KDE and integrate better into KDE workspace, then we could have a much more simple answer to those who like both gnome apps and kde apps: just use KDE as your workspace and you will have good user experience with both gnome and kde apps.
Isn't that a great idea to promote KDE?
@pansz: "instead of spending efforts on making KDE apps run better in non-KDE, Why not spend more efforts on making non-KDE apps run better in KDE?"
well it's actually more about making KDE apps run better with other software, not so much in other desktops/workspaces.
using DBus allows us to use things like HAL, for instance, and Phonon allows a KDE4 app to run side by side with any other app and share the underlying sound system.
this essentially accomplishes exactly what you suggest here:
"If most great non-KDE apps run better in KDE and integrate better into KDE workspace, then we could have a much more simple answer to those who like both gnome apps and kde apps: just use KDE as your workspace and you will have good user experience with both gnome and kde apps."
i think this is where we are heading, to be honest.
of course, we like to have our cake and eat it, too: we'd like our friends using Windows, MacOS, GNOME, etc.. to be able to easily use KDE applications as well ... perhaps that's how they come to like KDE apps in the first place.
and KDE apps will always work best together, and the workspace is one such KDE application. they just also work fine outside of the KDE workspace =)
I really like this post and the idea behind it.
A good way to start would be to review all KDE websites and correct them.
For example:
The phonon site states:
"A new era of writing multimedia-enabled applications in KDE is about to begin. It's time to push to new limits."
As long as sites look like that you have to forgive Lennart in his first post to think of Phonon as something KDE-specific. ( In his second post he was just ignorant though .. )
Bottom line: Amarok is a great application, full of great features most people expect of an application of that type, shows off the pretty good development infrastructure KDE has, and if it doesn't fit in with another desktop environment you feel joined to then it is simply hard cheese. Whine at the Rhythmbox developers for not being able to keep up, or the Banshee developers for not being able to keep up or make the applications stable. I have experienced no love whatsoever from Gnome in accepting non-Gnome or GTK applications and getting them to integrate better with Gnome.
Expect to hear more complaints of that type over the next few years. If you can't support your application developers to do great things that users like then you have a problem - and it's your problem and no one else's.
Those of us who are in the support trenches do not disregard how different Gnome and kde apps truly are.
Aaron's message is basically that people should lower their expectations and give up some integration in exchange for good-enough applications. The truth is that there are many environments where integration is really the key:
1) Thin-client and LDTP clients benefit from having as many loaded shared libraries as possible in terms of memory consumption. Since many people use the services offered by one big server, maintaining a homogeneous set of libraries and sticking predominantly to a desktop environment helps.
2) When you are teaching users the benefits and beauty of desktop linux such as the ubiquitous support for all kinds of protocols under konqueror, thanks to KIOs, these users freak out when they go and try to open a remote file in a gnome app and it doesn't work. You know why?
Because it isn't the aesthetics that matter most to them, it's the broken experience and broken expectations that matter to them.
3) There is, in my opinion, too much political correctness with regards to the differences between Gnome and KDE. While useless barroom brawls will get us nowhere, being truthful about the fact that KDE is a very different platform would actually benefit the projects and bring it a new wave of potential users. When I am introducing somebody to Linux, they do want to know the differences between the two environments. Stating that they both work pretty much alike and that you can run applications from one environment in the other, while true, does them a disservice, because it presents to them a very partial picture of the actual technical differences between the two and it makes choosing one or the other seem irrelevant, since "they are pretty much the same".
The reality is that differences run deep and that there are substantial differences in the quality of the software produced by both projects.
Finally, not being clear as to what KDE advantages really are, i would say not being loud and clear leaves distributors with the idea that they should go with the flow, rather than with what they know to be the superior choice.
Post a Comment