it takes a while to get something like OpenUsability moving, but moving it is! there are around 20 projects and 6-8 usability professionals involved... here's a "fireside chat" with the people who started OpenUsability, Jan and Ellen, and a few others:
would you be happy to know that such tests are actually going on right now in a usability lab? i ask because we've got such a thing happening in a usability lab over in Europe. OpenUsability.org is turning out to be quite a great resource!
also.... don't be surprised if the control center in KDE 4.0 doesn't have exactly the same "tree on the left with 3 tabs, viewer on the right" interface.
> not actually doing the job of laying out the GUI
yes, this is exactly what XMLGUI does for menus, toolbars and even context menus (though not enough apps use it for context menus still). there are people playing around with it right now to extend it to simple dialog layouts as well.
additionally, there are APIs that apps use which allow them to say "configure the keyboard shortcuts" and the actual libraries handle all the details of that. it's exactly one line of code in a KDE app to configure shortcuts, or rearrange toolbars...
we can certainly take it further, and likely will, but we've been walking down that path already for some time.
this is, btw, one of the reasons why KioskTool works so well =)
> grabs the content and puts it in a local temporary
that's actually not related to the default browser feature at all, but to how KMail handles links. it's trying to deduce the mimetype before launching it. it doesn't just look at the protocol (since you may get any type of file via http://), but it also doesn't look to the file extensions AFAIK (which it probably should and probably will eventually)
> Human Interfeace Guidelines ought to be > enforced programmatically rather than as a
this is how many such things are already done in KDE. margin hints, spacing hints, menu layouts... there are some things that just don't translate to being put in the libraries, however. but yes, defining as much as you can in the infrastructure that applications are built on top of is a good idea.
fair enough. perhaps you'll use KDE again in the future. =) you may be interested in reading this:
http://dot.kde.org/1107931942/
> I just felt the quote was indicative of the > development mindset that led me to switch to > GNOME... which led you to feel compelled to post it to this article. heh. aaaah, slashdot! no place quite like it.
well, let's see. KDE has had a MIME system for years that works rather well. the new MIME spec, which isn't somehow obviously better, is a rather radical departure from this existing system. one might consider that writing new "cooperative" specs that ignore existing methodology is a bit brain-damaged.
not only does it mean that everyone who has a solution now has to rework their software, it means throwing away lessons learned from the existing implementations (assuming they aren't broken and need replacing, of course). instead, with a completely new spec we get to restart the learning and debugging process. such fun!
worst, perhaps, is that it means those who already have working, efficient solutions in place (in this case, KDE) have to create a migration path for their user base that is smooth and non-frustrating for the users. which means the project needs to pick when and how to do it carefully, which is rarely smooth and non-frustrating for the developers. during this transitional time, the "common spec" doesn't create a commonality at all but rather it reinforces the discrepancy for at least some time period.
i think it's _great_ that we have a shared mime spec. i also think that the execution of creating that spec was woefully poor.
so before you get all fanboyish about every single thing that hits the pages of FreeDesktop.org or any other such "let's all cooperate" concept, consider the quality and value of those contributions. getting Open Source software to work together seamlessly is a necessary endeavour and a great goal. let's do it right.
> but all this seems to be is a few more > appliKations thrown into the default KDE > install
if you actually try it out, you'll find that there are many, many bug fixes and improvements in existing applications and libraries. it's much more than just "3.3. plus a couple new apps"
> Choose the best one, and if people like > something 'different' allow them to install it > themselves
this is currently something left up to the operating system vendor/integrator/distribution. most current mainstream distros of Linux do ship KDE broken up into applications. there has been an interesting amount of conversation within the development community on how to best aid in the process without losing the benefits of definition but possible improving selection and selectivity.
it's not a trivial issue to "solve". but i'm glad its seen as one of the more visible issues (apparently, anyways), since things could be much worse. notice how nobody complains about how DCOP or other core technologies don't work, for instance?;)
one of the things about an open, participatory project is that you get all sorts of ideas and opinions. sometimes the people who choose to get involved have good ideas, sometimes they don't. most people have a mix of both over time, with some having a lot of _really_ good ideas (and the converse as well, of course).
so it's not like we can control what people suggest. in fact, when brainstorming it can be a bad thing to do so. but we don't have to, nor do we in practice, implement every single idea/concept/suggestion.
so what really matters is what gets put into CVS, not what appears on a mailing list. and no, there won't be an option in KDE Performance to cache icons.
there have been times in the past when the project got a bit crazy with the options in places without really thinking about the costs or if there were other better ways of approaching it. but that's not the general direction in the project as a whole anymore. you'll still find areas that have unnecessarily messy sets of config dialogs, but those are receding and fewer new such items are going in.
in fact, with KDE 4 we will likely be instituting a GUI review system and period in the release cycle.
in any case, since you brought it up and since you lurk on kde-optimize, maybe you'd be willing to help out with the profiling? =)
well, "intuitive" is a sham. there are no intuitive interfaces, no, not even the nipple (which is also learned.. look up "nurse latching" on google).. there are only learnable and familiar interfaces.
but since people often can't find where this particular setting it, i'd agree that it's certainly not familiar. and while it's learnable, the learning curve is apparently a bit too steep.
the Control Center is one of the things that will be massively reworked for KDE 4.0. we've been holding off until 4.0 to do that for a couple reasons, one of the major ones being not to ruin the familiarity of the control center to people who have learned it. we happen to care about our users and their time investments =)
but having a setting for default web browser that isn't immediately findable does not make KDE not ready for the desktop. if that were the case, nobody would be able to use Windows or MacOS either, both of which have nicely hidden features that are difficult to find unless you are familiar with the system.
i know i know, don't feed the trolls.. but sometimes i wonder if this seemingly common concept really isn't just a troll but a deep seated misconception.
> there's not even a simple config/dialog where > you can choose to run firefox/mozilla instead > of konqueror whenever you click on links on > other "K" apps.
in the Control Center, under KDE Components, there's a "Component Chooser" panel that's been there since 3.3 that allows you to set your default browser, email, text editor, IM client and terminal app.
you, as most of people posting here thus far, have missed the thesis of my blog entirely.
it's not about "Freeness politics", and it's not about open source (this isn't just about KDE) being on a closed source platform. nor is it about moving everyone to Linux or any other given OS.
the issue is creating long term viability for Open Source desktop software, which requires being able to develop and run that software, having a user base that large enough to be sustainable and satisfying that user base.
the whole point of the blog was that Windows, in specific, is not such a place in the mid-to-long term.
this has nothing to do with it being a closed source platform (after all, what's Solaris or AIX?) and everything to do with it being the platform of a company who competes very aggressively and effectively on their own platform.
to understand why that is the case, you may have to actually read the article;-)
but those posting about "transitional apps" or "choice" or "stupid free software hippies" are talking about something almost completely different than what i wrote about.
you can add this as a flag to the entry in the kmenu by using the menu editor (kmenuedit, also available by right clicking on the kmenu icon).
Re:Qt is almost a like a language
on
A Taste of Qt 4
·
· Score: 1
> he knows very well that KDE advocates skulking > around freedesktop.org wait for any reason to > attack
oh? has Havoc said this to you? i'd be interested in an attributable quote, since it's complete BS. of course, i doubt Havoc said or even thinks such a thing. i have a lot more respect for him than to think that. i'm not sure why you feel the need to try and drive a wedge between people on FD.o, but perhaps if you posted as yourself as opposed to an AC we would have a better idea as to your agenda and slant on things.
seriously, KDE supports FD.o and works hard with others there. this includes the non-KDE ppl involved, without whom FD.o wouldn't be the useful thing that it is.
> shitty non-standard implementation of signals
interesting definition of standard, since Qt was pretty much the first toolkit to introduce the concept of signals and slots.;) i know what you are trying to say, however: they added new tools to the language as opposed to using things like the STL. there were and are good reasons for this, which others have hinted at and you evidently are either unaware of or simply don't grasp. while you may not agree with how Trolltech decided to approach the problem, millions of lines of code and tens of thousands of happy developers think otherwise. it works and works well, which is to say that it's extensible and clean. for the pragmatically minded, that's primarily what matters.
having to? no. chosing to? yes. why? because it exists, because it's in use outside of KDE (allowing interop on day 0 rather than day N), because apps are already using it, because it has FSG support, etc, etc, etc. you seem to phrase KDE's pragmatic and generally beneficial decision as a weakness (or am i just reading you wrong?). cooperation and leveraging the good work of others is not a weakness. we could have decided to remain behind GNOME by ascribing to NIH and trying to reimplement everything ourselves, but instead we decided to join the game at a full run thanks to the opportunities inherent in open source and the good will of all involved.
thanks go to Sun, the FSG and the KDE hackers involved in this particular piece of the puzzle =) see! we can and do work together =)
Javascript is not embedded in KDE. KJSEmbed is a set of Javascript bindings built on top of KDE Javascript implementation. this is no different than, say, Python or Java bindings. where it does deviate is that it is possible for an application to embed the KJS engine and thereby use KJSEmbed internally as a scripting option should it so choose. but it isn't like KJSEmbed is loaded whenever you start up KDE, or even the overwhelming majority of KDE apps for that matter.
that said, one of the beautiful things about open source / Free software is choice. go crazy with your window manager only set up, and have fun with it! i'm glad you aren't forced to use something that doesn't fit your style and/or needs!
all the same, it's only fair to be accurate. your viewpoint on "eye candy" derivative code trying to do "what you need" rather than the apps themselves is a rather inaccurate statement on how things work. desktop environments aren't for everyone (you being an example of that), but at least you could get your derision right;-)
you can release BSD-licensed code against the Fre eQt since it's also licensed under the QPLv2. there is BSD and Artistic licensed code in KDE, for instance.
the tab redrawing on contents change is a known issue and will likely be addressed in upcoming releases. this isn't like most KDE widgets, which tend to be flicker-free.
to be fair, GNOME started 8 months after KDE. that's less than 10% time difference put into each by now, and growing less with every passing day.
as for consistency, each has their strong points in this regard. there are many inconsistencies between various GNOME apps... it's probably fair to say that both desktops have work to do here, and both desktops are getting better at it. give us another year or two =)
i will note that KDE apps rely heavily on the framework for most everything outside of custom dialog/window layouts, which is a source of great consistency between KDE apps.
in the other camp, the GNOME people have put a lot of work into hand-tweaking each app to make them comply to their HIG.
i fully expect to see both projects take cues from the other and therefore both improve in the end.
true; and most new users will also be familiar with the Windows ordering of buttons (for better or worse)... putting them in the same boat as our existing users when it comes to button order.
you're misreading the tone in my voice. it isn't one of competitiveness as framed within the fabled "GNOME vs KDE wars", but observational from an informed perspective.
> Witness your other post in this thread, calling > Gnome's button order "silliness" even though > it logically makes sense and merely points out > how other GUIs like Windows and KDE have been > doing it wrong.
i'm sorry you didn't get it, but i don't really expect most people here to do so. i call it as i see it, regardless of whether others grok it or not. you can change my mind (it happens on a fairly regular basis), but one first needs to provide a compelling, informed argument.
that is the world of Open Source _development_ versus Open Source _airmchair_ development.;)
> This is the precise reason having multiple > desktop environment projects is a bad idea.
> It's just a user preference for me. When I use > KDE, I see all the cool stuff it can do. But > when I use Gnome, I actually feel comfortable > as though this is something I could use all day > and not go insane
am i the only one who sees the irony here? or... is it arrogance: "what i like must be right."
you're right that "OK" and "Cancel" are poor terms to use on most dialogs, which is why our (KDE's) UI guidelines recommend against it and only default to it when no other direction is given from the application.
unfortunately for you, that wasn't what i was talking about.
as for sitting users down in front of KDE, i do that all the time. in fact, at the moment one of the things i'm working on (among others) is a proper statistical measure of how users of varying experience levels use the toolbar buttons in a web browser so as to tweak Konqueror's web browser toolbar configuration for KDE 3.3.
oh well, you can't be right all the time, can you, Mr. Anonymous?
which website's menus no longer work? if you can confirm it as a problem, please submit it to bugs.kde.org if it hasn't been already. if it has, please vote it up =)
Slashdot Mirror
it takes a while to get something like OpenUsability moving, but moving it is! there are around 20 projects and 6-8 usability professionals involved ... here's a "fireside chat" with the people who started OpenUsability, Jan and Ellen, and a few others:
http://dot.kde.org/1107931942/
would you be happy to know that such tests are actually going on right now in a usability lab? i ask because we've got such a thing happening in a usability lab over in Europe. OpenUsability.org is turning out to be quite a great resource!
.... don't be surprised if the control center in KDE 4.0 doesn't have exactly the same "tree on the left with 3 tabs, viewer on the right" interface.
also
> not actually doing the job of laying out the GUI
yes, this is exactly what XMLGUI does for menus, toolbars and even context menus (though not enough apps use it for context menus still). there are people playing around with it right now to extend it to simple dialog layouts as well.
additionally, there are APIs that apps use which allow them to say "configure the keyboard shortcuts" and the actual libraries handle all the details of that. it's exactly one line of code in a KDE app to configure shortcuts, or rearrange toolbars...
we can certainly take it further, and likely will, but we've been walking down that path already for some time.
this is, btw, one of the reasons why KioskTool works so well =)
> grabs the content and puts it in a local temporary
that's actually not related to the default browser feature at all, but to how KMail handles links. it's trying to deduce the mimetype before launching it. it doesn't just look at the protocol (since you may get any type of file via http://), but it also doesn't look to the file extensions AFAIK (which it probably should and probably will eventually)
> Human Interfeace Guidelines ought to be
> enforced programmatically rather than as a
this is how many such things are already done in KDE. margin hints, spacing hints, menu layouts... there are some things that just don't translate to being put in the libraries, however. but yes, defining as much as you can in the infrastructure that applications are built on top of is a good idea.
fair enough. perhaps you'll use KDE again in the future. =) you may be interested in reading this:
... which led you to feel compelled to post it to this article. heh. aaaah, slashdot! no place quite like it.
http://dot.kde.org/1107931942/
> I just felt the quote was indicative of the
> development mindset that led me to switch to
> GNOME
well, let's see. KDE has had a MIME system for years that works rather well. the new MIME spec, which isn't somehow obviously better, is a rather radical departure from this existing system. one might consider that writing new "cooperative" specs that ignore existing methodology is a bit brain-damaged.
not only does it mean that everyone who has a solution now has to rework their software, it means throwing away lessons learned from the existing implementations (assuming they aren't broken and need replacing, of course). instead, with a completely new spec we get to restart the learning and debugging process. such fun!
worst, perhaps, is that it means those who already have working, efficient solutions in place (in this case, KDE) have to create a migration path for their user base that is smooth and non-frustrating for the users. which means the project needs to pick when and how to do it carefully, which is rarely smooth and non-frustrating for the developers. during this transitional time, the "common spec" doesn't create a commonality at all but rather it reinforces the discrepancy for at least some time period.
i think it's _great_ that we have a shared mime spec. i also think that the execution of creating that spec was woefully poor.
so before you get all fanboyish about every single thing that hits the pages of FreeDesktop.org or any other such "let's all cooperate" concept, consider the quality and value of those contributions. getting Open Source software to work together seamlessly is a necessary endeavour and a great goal. let's do it right.
> but all this seems to be is a few more
;)
> appliKations thrown into the default KDE
> install
if you actually try it out, you'll find that there are many, many bug fixes and improvements in existing applications and libraries. it's much more than just "3.3. plus a couple new apps"
> Choose the best one, and if people like
> something 'different' allow them to install it
> themselves
this is currently something left up to the operating system vendor/integrator/distribution. most current mainstream distros of Linux do ship KDE broken up into applications. there has been an interesting amount of conversation within the development community on how to best aid in the process without losing the benefits of definition but possible improving selection and selectivity.
it's not a trivial issue to "solve". but i'm glad its seen as one of the more visible issues (apparently, anyways), since things could be much worse. notice how nobody complains about how DCOP or other core technologies don't work, for instance?
one of the things about an open, participatory project is that you get all sorts of ideas and opinions. sometimes the people who choose to get involved have good ideas, sometimes they don't. most people have a mix of both over time, with some having a lot of _really_ good ideas (and the converse as well, of course).
so it's not like we can control what people suggest. in fact, when brainstorming it can be a bad thing to do so. but we don't have to, nor do we in practice, implement every single idea/concept/suggestion.
so what really matters is what gets put into CVS, not what appears on a mailing list. and no, there won't be an option in KDE Performance to cache icons.
there have been times in the past when the project got a bit crazy with the options in places without really thinking about the costs or if there were other better ways of approaching it. but that's not the general direction in the project as a whole anymore. you'll still find areas that have unnecessarily messy sets of config dialogs, but those are receding and fewer new such items are going in.
in fact, with KDE 4 we will likely be instituting a GUI review system and period in the release cycle.
in any case, since you brought it up and since you lurk on kde-optimize, maybe you'd be willing to help out with the profiling? =)
well, "intuitive" is a sham. there are no intuitive interfaces, no, not even the nipple (which is also learned.. look up "nurse latching" on google).. there are only learnable and familiar interfaces.
.. but sometimes i wonder if this seemingly common concept really isn't just a troll but a deep seated misconception.
but since people often can't find where this particular setting it, i'd agree that it's certainly not familiar. and while it's learnable, the learning curve is apparently a bit too steep.
the Control Center is one of the things that will be massively reworked for KDE 4.0. we've been holding off until 4.0 to do that for a couple reasons, one of the major ones being not to ruin the familiarity of the control center to people who have learned it. we happen to care about our users and their time investments =)
but having a setting for default web browser that isn't immediately findable does not make KDE not ready for the desktop. if that were the case, nobody would be able to use Windows or MacOS either, both of which have nicely hidden features that are difficult to find unless you are familiar with the system.
i know i know, don't feed the trolls
> Is there some way to merge the burning and
> playing application for media files inside KDE
both JuK and amaroK support burning of playlists. right click on the playlist, select "Burn to CD".
> there's not even a simple config/dialog where
> you can choose to run firefox/mozilla instead
> of konqueror whenever you click on links on
> other "K" apps.
in the Control Center, under KDE Components, there's a "Component Chooser" panel that's been there since 3.3 that allows you to set your default browser, email, text editor, IM client and terminal app.
> The guy that made the original comment is just
... i would've started years ago. ;-P
> so full of himself.
FINALLY!
you have no idea how long i've been trying to get people to understand just how arrogant i truly am.
had i known all it would take is some idle moments spent blogging, well, sheeee-it
you, as most of people posting here thus far, have missed the thesis of my blog entirely.
;-)
it's not about "Freeness politics", and it's not about open source (this isn't just about KDE) being on a closed source platform. nor is it about moving everyone to Linux or any other given OS.
the issue is creating long term viability for Open Source desktop software, which requires being able to develop and run that software, having a user base that large enough to be sustainable and satisfying that user base.
the whole point of the blog was that Windows, in specific, is not such a place in the mid-to-long term.
this has nothing to do with it being a closed source platform (after all, what's Solaris or AIX?) and everything to do with it being the platform of a company who competes very aggressively and effectively on their own platform.
to understand why that is the case, you may have to actually read the article
but those posting about "transitional apps" or "choice" or "stupid free software hippies" are talking about something almost completely different than what i wrote about.
konsole --noxft
you can add this as a flag to the entry in the kmenu by using the menu editor (kmenuedit, also available by right clicking on the kmenu icon).
> he knows very well that KDE advocates skulking
;) i know what you are trying to say, however: they added new tools to the language as opposed to using things like the STL. there were and are good reasons for this, which others have hinted at and you evidently are either unaware of or simply don't grasp. while you may not agree with how Trolltech decided to approach the problem, millions of lines of code and tens of thousands of happy developers think otherwise. it works and works well, which is to say that it's extensible and clean. for the pragmatically minded, that's primarily what matters.
> around freedesktop.org wait for any reason to
> attack
oh? has Havoc said this to you? i'd be interested in an attributable quote, since it's complete BS. of course, i doubt Havoc said or even thinks such a thing. i have a lot more respect for him than to think that. i'm not sure why you feel the need to try and drive a wedge between people on FD.o, but perhaps if you posted as yourself as opposed to an AC we would have a better idea as to your agenda and slant on things.
seriously, KDE supports FD.o and works hard with others there. this includes the non-KDE ppl involved, without whom FD.o wouldn't be the useful thing that it is.
> shitty non-standard implementation of signals
interesting definition of standard, since Qt was pretty much the first toolkit to introduce the concept of signals and slots.
having to? no. chosing to? yes. why? because it exists, because it's in use outside of KDE (allowing interop on day 0 rather than day N), because apps are already using it, because it has FSG support, etc, etc, etc. you seem to phrase KDE's pragmatic and generally beneficial decision as a weakness (or am i just reading you wrong?). cooperation and leveraging the good work of others is not a weakness. we could have decided to remain behind GNOME by ascribing to NIH and trying to reimplement everything ourselves, but instead we decided to join the game at a full run thanks to the opportunities inherent in open source and the good will of all involved.
thanks go to Sun, the FSG and the KDE hackers involved in this particular piece of the puzzle =) see! we can and do work together =)
Javascript is not embedded in KDE. KJSEmbed is a set of Javascript bindings built on top of KDE Javascript implementation. this is no different than, say, Python or Java bindings. where it does deviate is that it is possible for an application to embed the KJS engine and thereby use KJSEmbed internally as a scripting option should it so choose. but it isn't like KJSEmbed is loaded whenever you start up KDE, or even the overwhelming majority of KDE apps for that matter.
;-)
that said, one of the beautiful things about open source / Free software is choice. go crazy with your window manager only set up, and have fun with it! i'm glad you aren't forced to use something that doesn't fit your style and/or needs!
all the same, it's only fair to be accurate. your viewpoint on "eye candy" derivative code trying to do "what you need" rather than the apps themselves is a rather inaccurate statement on how things work. desktop environments aren't for everyone (you being an example of that), but at least you could get your derision right
you can release BSD-licensed code against the Fre eQt since it's also licensed under the QPLv2. there is BSD and Artistic licensed code in KDE, for instance.
the tab redrawing on contents change is a known issue and will likely be addressed in upcoming releases. this isn't like most KDE widgets, which tend to be flicker-free.
to be fair, GNOME started 8 months after KDE. that's less than 10% time difference put into each by now, and growing less with every passing day.
as for consistency, each has their strong points in this regard. there are many inconsistencies between various GNOME apps... it's probably fair to say that both desktops have work to do here, and both desktops are getting better at it. give us another year or two =)
i will note that KDE apps rely heavily on the framework for most everything outside of custom dialog/window layouts, which is a source of great consistency between KDE apps.
in the other camp, the GNOME people have put a lot of work into hand-tweaking each app to make them comply to their HIG.
i fully expect to see both projects take cues from the other and therefore both improve in the end.
true; and most new users will also be familiar with the Windows ordering of buttons (for better or worse)... putting them in the same boat as our existing users when it comes to button order.
> You seem way too competitive over this issue.
;)
you're misreading the tone in my voice. it isn't one of competitiveness as framed within the fabled "GNOME vs KDE wars", but observational from an informed perspective.
> Witness your other post in this thread, calling
> Gnome's button order "silliness" even though
> it logically makes sense and merely points out
> how other GUIs like Windows and KDE have been
> doing it wrong.
i'm sorry you didn't get it, but i don't really expect most people here to do so. i call it as i see it, regardless of whether others grok it or not. you can change my mind (it happens on a fairly regular basis), but one first needs to provide a compelling, informed argument.
that is the world of Open Source _development_ versus Open Source _airmchair_ development.
> This is the precise reason having multiple
> desktop environment projects is a bad idea.
> It's just a user preference for me. When I use
> KDE, I see all the cool stuff it can do. But
> when I use Gnome, I actually feel comfortable
> as though this is something I could use all day
> and not go insane
am i the only one who sees the irony here? or... is it arrogance: "what i like must be right."
you're right that "OK" and "Cancel" are poor terms to use on most dialogs, which is why our (KDE's) UI guidelines recommend against it and only default to it when no other direction is given from the application.
unfortunately for you, that wasn't what i was talking about.
as for sitting users down in front of KDE, i do that all the time. in fact, at the moment one of the things i'm working on (among others) is a proper statistical measure of how users of varying experience levels use the toolbar buttons in a web browser so as to tweak Konqueror's web browser toolbar configuration for KDE 3.3.
oh well, you can't be right all the time, can you, Mr. Anonymous?
Aaron J. Seigo
which website's menus no longer work? if you can confirm it as a problem, please submit it to bugs.kde.org if it hasn't been already. if it has, please vote it up =)