Just a quicky: I've noticed that many binary packages of KDE applications note in their description field that the application is "for KDE". What exactly does that mean? These apps run just fine anywhere they can be compiled, so I don't think that phrase has much meaning. It certainly can give people who don't use KDE as their desktop the impression that those applications aren't for them and lead to them missing out on some great software.
I understand the history behind such wording, but it really has lost its meaning over the years. So perhaps the packagers of the world could consider dropping the use of that rather meaningless phrase, "for KDE", from the package descriptions.
(If you're curious, it was in the description for the deb package for KFileReplace that I noticed this phrase. apt-cache displayed the message and I couldn't help but think what an odd thing that was. The app itself it pretty sweet, though. Some rough UI edges (like the edit selected string dialog is a bit of a nightmare) but generally very nice to use.)
About Me
Labels
- akademy (3)
- amarok (1)
- appeal (1)
- build system (1)
- community (7)
- crash (2)
- d-bus (1)
- dataengine (1)
- dolphin (2)
- events (1)
- family (1)
- free software (1)
- gnome (2)
- graphics (1)
- guademy (1)
- kde (52)
- kde e.v. (3)
- kde; kdegraphics (1)
- konqueror (1)
- krunner (4)
- libs (5)
- lug radio (1)
- media center (1)
- misc (1)
- openid (1)
- oxygen (2)
- performance (1)
- photos (1)
- plasma (26)
- podcast (1)
- pr (1)
- prose (1)
- release (1)
- social (1)
- solaris (1)
- techbase (6)
- travel (6)
- trolltech (3)
- web2.0 (1)
37 comments:
Perhaps we use this expression because users ask it. They want to know if an apps is kde-based or gnome-based.
Before the name was helping : an application with a "k" is for kde and a "g" for gnome. But now it's harder. Of course we could tell "kde based application"
But for people who don't understand that, it won't help. So yes "for kde" is wrong, but how could we simply say that one apps is kde, gnome, qt or gtk based in a way any user will understand ?
have you been to the KFileReplace website (http://kfilereplace.sourceforge.net/)? Look at the titlebar. I don't think it's the packagers who are responsible in this case.
I have use "KDE" as a search term in package managers to see if I'm missing out on any cool KDE-centric apps that I should install. I think, like marseillai, that the phrase helps me know if I can expect the nice KDE integration that I've come to love. I admit; I have a bias.
well, apparently that's an out-of-date website, but that's probably where the packager's blurb came from in any case
'for kde' is synonym for 'for the world" of cuz.
yes, we often do it to ourselves as well. something we need to change.
the issue really is the word "for" since it turns it all into a misnomer. "from KDE" doesn't particularly work for 3rd party apps.
right now branding ("this is a kde app") is interfering with reach ("i don't use kde, so that app isn't for me"). figuring out how to protect branding while removing the audience obstacle is the tricky question.
not sure what the answer might be right now.
Why not "From the KDE community"?
It works for all apps, provides branding and is open ended ;-)
Really, this is something bothering me as well. Like exaile, which is branded as "amarok, just that it's for gtk". Why is it only in the free software world that people are so damn obsessed with what graphical toolkit an application is using?
You don't see Windows users refusing to use iTunes because it's "too Mac OS X" or GIMP because it's "too GNOME". They simply don't care about it.
Even though I use KDE all the time, I can still run GIMP, which is a GNOME app, in it. The only thing I can complain about is the lack of visual integration into the rest of the desktop, but this could probably be solved with a compatibility mode of some sort, right (like GTK-Qt?). Why can't our efforts be put into making the desktops blend into each other, instead of duplicating each other's efforts?
I like this "for KDE" thing in package descriptions. If i search for application for some purpose and run kde, "for KDE" will mean such app will integrate well in environment, will use KIO, phonon, plasma, solid...
@Stalwart: alright, then let's put it this way: how can we tag things so you can find them without chasing other people away?
one must look at both pros and cons and if the balance isn't sufficient (i don't think it is here) then find a new solution with a better pros/cons mix.
I understand your point. But this brings me to another question:
I run KDE (instead of Gnome) for one main reason: GTK (or Gnome) apps work *fine* under KDE (just as good as they run under Gnome). I can run The Gimp, Pidgin (former Gaim), gFTP, etc.. without a glitch. And they even integrate nicely in KDE.
BUT, if I run Gnome and want to use Kopete, Amarok or K3B there, it just doesn't work nicely. They're very slow to load, look like shit unless you really take time to manually fix the look and feel (and have the knowledge to do it), they have problems with the notifications, etc...
So in part, this "for KDE" is true to some extent. And my question is: who's fault is it that KDE apps don't integrate nicely in Gnome? Is it because of the way these KDE apps are "engineered" (in contrast to Gtk/Gnome apps) that doesn't let them integrate in "foreign" environments or is it because of the way Gnome is "engineered" (in contrast to KDE) that doesn't allow "foreign" apps to integrate nicely in it? And more important, is it fixable?
Why is it only in the free software world that people are so damn obsessed with what graphical toolkit an application is using?
Well I can only speak for myself, but I like the vast majority of my apps to be qt/kde based because they are nicer to use than anything based on GTK. The file selector is not crap, I can open files over the network, the look integrates, it might use common components, etc.
On Windows I don't care so much, because all applications integrate equally poorly. Every app uses their own libraries anyway, so there really isn't a clear set of advantages to having one over the other.
Konqi: The thing is, KDE and Gnome are two separate desktops that happen to be able to run each other's software (and who share quite a few things behind the scenes these days). Making GTK controls look like Qt ones or vice-versa isn't enough. A Gnome app doesn't *feel* the same as a KDE one. You wouldn't expect an app targetting KDE to use the Gnome HIG, or vice versa.
As the author of a GTK/Gnome app, I wouldn't be the least bit offended about a KDE user looking for a Qt equivalent to it.
I guess Windows users don't kick up a fuss about consistency because they're so used to apps being inconsistant on that platform -- even Microsoft's own offerings don't look like each other (compare Windows Explorer, IE, WMP, Office, etc). I would argue that MacOS users very definitely *do* care about it.
Fortunately there is a solution to all this duplication of effort, and that is D-BUS. For example, if there was an amarok-dbus-service, it would be relatively easy to create separate Qt and GTK front-ends for it. Then the people writing the GTK front-end could go ahead and systematically remove options and functionality until all that was left were "play" and "next track" buttons a la the iPod shuffle, whereas the people writing the Qt front-end could go ahead and make sure every pixel of screen space was covered in a button of some sort, and add seven or eight configuration dialogues in case there's an option somewhere that might not be accessible to the user. Et voila, now it fits in perfectly to both desktops ;)
Lovely idea, Trystan, but with the technology KDE offers (Phonon being especially relevant here) Amarok isn't that much more than a frontend. But there's a huge amount of work in that frontend...
How about "Optimised for KDE"? People probably want to know this so they don't need to install both gtk and qt on their hard drives.
From a usability point of view it makes perfectly sense to prefer those applications that fit into your desktop environment. It's not just visualization but also the open and printing dialog etc. Therefore you would want to search for these applications.
The point is that having a "for KDE" label in a description users may get the opinion that they are not able to use that program.
I think a description "KDE based ..." would fit since it would refer to KDE as the application framework but that wouldn't help to get rid of the possible confusion with KDE as the desktop environment.
Different names for the application framework and the desktop environment would eliminate that problem but cause another problems for sure.
Superstoned:
I may be wrong, but I understood Phonon to be an abstraction layer for relatively simple multimedia functions like playing videos or recording audio. So it doesn't deal with things like looking after a music database, iPod syncing, downloading song lyrics and metadata, creating auto playlists, burning MP3 CDs, etc etc etc. I don't really see how Amarok can be viewed as "just" a front-end for Phonon. And even if it is, I still don't see why this is a problem.
As an end user, I don't really care whether an application uses GStreamer directly, or GStreamer-via-Phonon, or Xine-via-Phonon or whatever, as long as sound comes out of my speakers when I press play. There's no reason why my hypothetical amarok-dbus-service + GTK interface couldn't use Phonon for output on a Gnome system.
Anyway, that's enough of my componentisation fantasies for now.
Back to the subject at hand, Ubuntu's gnome-app-install programme uses the phrase "This software integrates well into the Ubuntu desktop" for Gnome apps and "This software integrates well into the Kubuntu desktop" for KDE apps. This seems to me to be the best way of putting it.
As an end user, I don't really care whether an application uses GStreamer directly, or GStreamer-via-Phonon, or Xine-via-Phonon or whatever, as long as sound comes out of my speakers when I press play.
As an end user I do care whether an application uses Gstreamer directly, or GStreamer-via-Phonon, or Xine-via-Phonon, because I'm tired of useless abstraction layers that eat up more RAM and CPU cycles just for the sake of platform agnosticism and other shit which are just there for "being nice to other devs" and that no end user cares about. Hopefully, soon enough Haiku will be there to save us from all this mess.
@anonymous: "As an end user I do care whether an application uses Gstreamer directly, or GStreamer-via-Phonon, or Xine-via-Phonon, because I'm tired of useless abstraction layers that eat up more RAM and CPU cycles just for the sake of platform agnosticism and other shit which are just there for "being nice to other devs" and that no end user cares about."
you know, when a plumber comes to my house i tend to stfu and let them do their job. unless, you know, i know something about plumbing. which i don't.
i'd suggest to you that you may wish to do the same.
see, Phonon allows us to:
a) be portable (think not just the mess of audio systems on linux, but win and mac)
b) be future proof (we can change underlying system API in the future, all OSes do this to us, and not rewrite any application code!)
c) by sharing single audio systems on a desktop between apps we actually save resources. (not to mention make it plausible for things to Just Work as well)
now as you can see you completely got it wrong. but that's ok because you're probably not a software architect.
may i humbly suggest, however, that since that isn't where your knowledge lies that you, as i do for the plumber, stfu.
"Hopefully, soon enough Haiku will be there to save us from all this mess."
yeah, you just keep holding your breath for a reimplementation of a decade old desktop.
sorry for the harshness, but i'm seriously tired of these atittudes and diatribes born of ignorance.
@everyone: before we do lose the entire point of the thread here: the issue is this ...
how do we keep branding positive and visible while not giving false impressions that end up limiting our user base?
the rest of the discussion here is interesting, but most of it is about a slightly different set of topics =)
cant wait for kde4!
you know, when a plumber comes to my house i tend to stfu and let them do their job. unless, you know, i know something about plumbing. which i don't.
i'd suggest to you that you may wish to do the same.
You're talking to another plumber here.
see, Phonon allows us to:
a) be portable (think not just the mess of audio systems on linux, but win and mac)
This is useless. It doesn't get the job done.
b) be future proof (we can change underlying system API in the future, all OSes do this to us, and not rewrite any application code!)
Why not settle on one OS. Problem solved. As an end user, I want to use the best OS i.e. the one that uses the least resources, which is the most secure, the most consistent (and not just at the GUI level) and easiest to use while getting the job done.
c) by sharing single audio systems on a desktop between apps we actually save resources. (not to mention make it plausible for things to Just Work as well)
Sure it saves resources. But making a decision i.e. using one audio system and implementing everything that's needed at this level saves even more resources.
now as you can see you completely got it wrong. but that's ok because you're probably not a software architect.
may i humbly suggest, however, that since that isn't where your knowledge lies that you, as i do for the plumber, stfu.
No I got it perfectly right. I touched the sore spot.
yeah, you just keep holding your breath for a reimplementation of a decade old desktop.
May I suggest you go to http://haiku-os.org, download a test image and fire up Qemu. You might be in for a surprise.
@ anonymous: Wow. I did what you suggested, and boy was I surprised. I can't believe that anybody would actually recommend trying that. It's pretty primitive.
@ aaron: What about Alan's suggestion of "Optimised for KDE"? Or maybe, "Runs anywhere--Optimized for KDE" or something to that effect? I seem to remember this discussion coming up before. It's a tough topic, no doubt.
"Why not settle on one OS"? rofl. yeah, and maybe we should all go back to letting one company decide what's best for us all... there is no "best OS" (although I've heard emacs comes pretty close ;)
I care whether an app uses gstreamer or phonon or whatever because my sound card doesn't do hardware mixing, and it's really annoying when I have to kill artsd in order to make a game work. I hope someday we can just have a nice happy sound framework where nothing has to monopolize my sound card. phonon seems like a step towards that, imho. the only thing I'm concerned about is ensuring that knotify sounds aren't lagged (it's happened sometimes with artsd).
anyways, getting back on topic... what about "built with kdelibs"? "based on KDE"? I dunno... something that indicates part of the program's awesomeness comes from using kde technology (and that there'll be a big chunk of dependencies for people who haven't installed any kde proggies yet). the anti-kde thing can be pretty silly sometimes, but at other times there are valid reasons for wanting a properly-integrated program. and I also tend to look specifically for kde programs - I liked the k naming scheme.
What about "Enhanced for KDE" ?
"You're talking to another plumber here."
then remind me to never let you near my pipes because you've got to be one of the most clueless plumbers i've ever seen.
"This is useless. It doesn't get the job done."
really. how so? describe your position. it'll be fun because it's complete bullshit, but hey ... let's watch you squirm shall we?
"Why not settle on one OS"
as soon as you've convinced all the people in the world, let me know. until then, we'll take the pragmatic approach.
"saves even more resources."
how does choosing one solution at each application save more resources than making the decision at a lower level? really, show me numbers.
"I touched the sore spot."
yes you did. you touched the "why are people such fucking idiots" sore spot. i can't help it that you're a fucking idiot, but it would be great if you'd have the decency to realize it and go somewhere else.
"May I suggest you go to http://haiku-os.org, download a test image and fire up Qemu. You might be in for a surprise."
not really. been there, done that. moved on, doing something better.
Another idea:
"Powered by KDE (technology)"
Hello Mr. President... i understand you're pritty pissed about the plumber, but there's no point in losing one's manners over such a thing.
Let's all calm down and have a nice day.
Not too cool to be out of character Aaron.
Take it easy.
/Alex
I agree entirely, I'm glad I'm not the only one. Its not just binary descriptions, but all over the Internet there is a a general impression of "here's a app for Linux" when talking about Gtk/Gnome apps and "here's a good app if you use KDE". Amarok is often described this way. Like "konqi" mentioned in reference to exile. Exile does do some things different then Amarok (tabbed playlists), I wish this was it was promoted instead of "Amarok, but with gtk".
The GUI toolkit is mostly only important to those developing it! Users shouldn't have to care much...
-Ian Monroe
Windows programs can run under both KDE and GNOME by using WINE... does that make them KDE or GNOME programs? No.
To run KDE software, you need the KDE framework installed; to run GNOME software, you need the GNOME framework installed; to run Windows software, you need the WINE framework installed.
The fact that there is currently efforts (OpenDesktop) to make mixing KDE software with GNOME software more seamless doesn't mean they aren't two different things anymore.
There is such effort even with WINE in some limited form: just for instance, the tray icon of a Windows program will show in the KDE/GNOME notification area.
Frankly i hope your word won't reach the ears of the packagers because i surely don't want any fugly KDE app sitting on my beautiful gnome desktop, no thanks.
"For kde" is a warning that help save the eyes of people with taste.
What blatantly gratuitous trolling. As I said, I think there are valid reasons for KDE apps (as well as GNOME ones) to be marked as such, but this is certainly not one.
Its a good idea to have. If users want their systems light, they probably don't want to pull in all the deps from KDE if most of their apps are gnome / gtk
Getting back to the topic, how about "a KDE app/tool for _____" or "a KDE -insert function here-"?
Like "KFileReplace is a KDE tool for batch search and replace" or "Amarok is a versatile and easy to use KDE audio player?"
To be honest, I don't really think that the problem is in the description/naming. Whether it's "for KDE" or "a KDE app" or "powered by KDE" or "made with KDE", users will always just understand it for what it is: a KDE app. That people make the presumption that KDE/GNOME apps will not run or not run properly in GNOME/KDE is the real problem. Dropping the KDE brand in favor of a more general, "cross-desktop", description seems to be the only logical conclusion to what you say is the problem. But that's hardly a solution, is it?
So "how do we keep branding positive and visible while not giving false impressions that end up limiting our user base"? By dispelling that false impression by proper information. Distros can help do that, by installing a mixed set of programs. Some already do that. But ultimately, I don't think branding is the issue. Information dissemination is probably more important.
- Jucato (not a plumber)
+ ", KDE-style"
Style being a positive word an' all.
Thinking about it a little, just "K-style" might work better.
Post a Comment