The KDE Project has released KDE 3.1.2, the second maintenance release of the KDE 3.1 release series. It features more and much improved translations and many problem corrections. Read the Changelog or jump directly to the download links. Those of you who wish to compile from source can use Konstruct for near automatic compilation.
Dot Categories:
Comments
the openHCI effort will likely continue on in a while. i'm currently overly busy catching up on a backlog of TODOs, and the others involved seem equally busy ATM.
i agree that there are many places in the KDE UI that are suboptimally laid out and designed. those areas should be fixed, and that takes time to do it right. this has little to do with KDE's UI guidelines, however.
"The third group, and not mentioned thus far, however, is the power user. This is the average user of Linux or most non-Windows/Mac operating systems. For power users, raw features, and configurability win [..] I think the single biggest thing in terms of usability for power users is the ability to morph the underlying system to how the user works."
This is not really true. There is a large group of experienced "expert" users (I couldn't tell how large or what is the majority) which would prefer to learn a well designed, intuitive and efficient interface instead of trying to make the interface behave as they are used to.
Some people claim that interfaces are entirely a subjective thing, but that's not really true either. Usually when discussing about it, all comes down to three simple things:
a) Convenience and ease of use (if something can be made easy to understand, there is no need to make it complicated just for the sake of it)
b) Efficiency (for example how many clicks it takes to execute a certain action)
c) Visual appearance (nobody likes to work with butt ugly interfaces and clean layouts often help finding what you are looking for)
Sometimes if you discuss a certain problem you can come up with a solution that is a perfect balance between all three areas where a preference would force you to decide between one or another.
The only really subjective thing is what you are used to. This is indeed a personal thing but in general, those people who are able and willing to learn something new, are happier people. ;) Of course it's always a good thing if you can solve something in a way that most people are used to, but trying to please everyone in this way isn't possible unless you make everything infinetely configurable and do no interface innovation at all (which could lead to better interfaces for people who can cope with change).
Of course there is one very valid reason for preferences: Different environments or abilities. For example screen resolution, monitor size, disabilities of the user, etc can all require slightly different settings. It is important that those kind of preferences are easy to find and reach and don't get drown between non-essential configuration.
Needless to say that I'm one of these people I mentioned at the beginning. Today I'm looking for solutions that "just work". When I evaluate the quality of an application, I will first try to find out how it's meant to be used instead of trying to make it behave as I'm used to. If I like how it works by default or can find an obvious way in the preferences to make it work better, then I'll stay with it. If I don't, then I will look for alternatives if possible instead of spending a lot of time trying to transform the UI into something that works well.
Something that just came to my mind is this article StarDock article about their tenth anniversary. They wrote about the original ObjectDesktop product for OS/2 and how OS/2 was mostly an OS full of functionality and flexibility, without a real plan how a user should work with it. So ObjectDesktop stepped in and "bundled" all this functionality into something very powerful and efficient (with a bit of extra functionality). It seems that it was extremely popular.
Maybe what KDE really needs now would be an effort like ObjectDesktop. :)
"a) Convenience and ease of use (if something can be made easy to understand, there is no need to make it complicated just for the sake of it)"
Agreed, but please define "easy to understand" and keep in mind that what's easy to understand for one can be misunderstood by another person.
"b) Efficiency (for example how many clicks it takes to execute a certain action)"
Agreed, but this, of course, also needs to be balanced with the importance of the certain action for a particular user. Now we know users use computers for very different purposes...
"c) Visual appearance (nobody likes to work with butt ugly interfaces and clean layouts often help finding what you are looking for)"
Beauty is in the eye of the beholder, so the interface's look better be exchangeable (which it is). I agree a clean and especially logical layouts help users finding what they are looking for, but one shouldn't think to know already what users will look for and purposely hide away the rest.
"Sometimes if you discuss a certain problem you can come up with a solution that is a perfect balance between all three areas where a preference would force you to decide between one or another."
This is what's commonly called a "sane default". Preferences should be kept easily accessible for users just in case a particular sane default isn't sane for that particular user.
So altogether while agreeing with your way of thinking I'm sorry to disagree with your conclusion, I think you mixed up "just work" (as in having sane defaults which can be changed if necessary) with "just doesn't work like I want ideally" (as in forced defaults you have to live with).
"Agreed, but please define "easy to understand" and keep in mind that what's easy to understand for one can be misunderstood by another person."
Labels are one very good example. If something is nicely labeled, you immediately know what it's supposed to do. It should always be possible to quickly learn what something will do after the user learned the basic principles of the particular interface.
"Agreed, but this, of course, also needs to be balanced with the importance of the certain action for a particular user. Now we know users use computers for very different purposes..."
Applications should serve a certain purpose and the interface should be optimized for this. There is no point in assuming that the user might want to use this media player for something else than watching videos. That's why specialied applications are great and Emacs is such a usability monster. ;)
"Beauty is in the eye of the beholder, so the interface's look better be exchangeable (which it is). I agree a clean and especially logical layouts help users finding what they are looking for"
Yes, I was just talking about layout here. Sometimes it is difficult to find a good balance between a layout that is easy to understand _and_ looks really nice (not clumsy or anything). Surprisingly, the most logical layouts are often also the most visually appealing ones. Maybe not that surprising.
"but one shouldn't think to know already what users will look for and purposely hide away the rest."
That doesn't quite have anything to do with what I wrote. However, you _have_ to make compromises somehow and if you don't even know what your application is mostly used for, then you have bigger problems than usability. ;)
"This is what's commonly called a "sane default"."
No, a "perfect balance" can be more than a default. It often requires code instead of preferences. One example that always comes to my mind is one of Gaim. In earlier versions, it had a preference for alawys showing the border around buttons or not. Disabling this made buttons in the IM window much nicer but looked completely stupid in dialogs (this was the default though). Enabling this, was exactly the opposite. :) Now this option is gone but buttons in the IM window have no border while dialog buttons have. Much better. Now you could still have this preference somewhere with one more option (like "automatic") which is enabled by default, but it's not really important anymore. So sometimes eliminating a tradeoff preference _can_ be a win for everyone.
"Preferences should be kept easily accessible for users just in case a particular sane default isn't sane for that particular user."
You are probably getting at the typical "the developer should not assume to know best" flame... :/ This is arguable, if you do your usability homework, you should actually be able to cover all use cases. So if you can do this, there is no point in adding more options and thus increasing complexity and inflexibility. I usually find that if I try to change the behaviour of an application via an option that wasn't meant to be actually used, the result is everything but useful. Case in point: I like to have labels below my icons because it makes them larger click targets and is sometimes helpful. But KDE is not meant to be used like this so when I set this option, it looks extremely horrible with Konqueror and it's "Increase/Decrease Font Sizes" buttons, they are simply too long. The other option "Text alongside icons" is even worse, especially compared to the "priority text" which would only show labels besides important icons. So I went with icons only in the end. You could argue that the solution to this would be to improve text below icons (having small labels and larger tooltips would be optimal) and text alongside icons to act like priority text and I would agree with this but my point is, that the developer should think about this _before_ adding preferences. Having preferences that aren't actually meant to be used and fully supported has rarely turned out to be helpful in my experience.
"So altogether while agreeing with your way of thinking I'm sorry to disagree with your conclusion, I think you mixed up "just work" (as in having sane defaults which can be changed if necessary) with "just doesn't work like I want ideally" (as in forced defaults you have to live with)."
I don't have to live with anything, if something is dumb, then I can go to a bugzilla or a mailinglist and complain.. err discuss about it. :) This way developers are forced to actually do something usable. And if there is a really good reason to have a certain functionality that isn't useful for the majority of people, then it can still be made optional.
People really tend to get angry about this "developer knows best" attitude but in reality, this is extremely exaggerated.
As for my "conclusion", I don't know what you are refering to, I just stated what _I_ prefer today so you can hardly disagree with that. :)
I also never said that this can't work with sane defaults which can be changed. If an application works great out of the box and is easy to configure for the important stuff, then I don't mind it having 3000 more options somewhere hidden where they never get into my way. It just has no additional value for me so I don't mind their absence in Software that is often flamed against but works great for me without all those options (you know what I mean).
"Labels are one very good example. If something is nicely labeled, you immediately know what it's supposed to do. It should always be possible to quickly learn what something will do after the user learned the basic principles of the particular interface."
I agree, but then again, what is a "perfect label"? One that uses a technical term which is specific enough for everyone to look up and get a good description for regarding it use and behavior, or one that describes the result thus making it superficially easier to understand for everyone but not helping at all as soon as someone is actually looking for the specific technical term?
"Applications should serve a certain purpose and the interface should be optimized for this."
So far I agree.
"There is no point in assuming that the user might want to use this media player for something else than watching videos."
Funnily enough I'm more used to "media players" being able to play music, not videos, so your specialization would leave me scratching my head and drop the application completely. Obviously this is no good either. =P
"Yes, I was just talking about layout here. Sometimes it is difficult to find a good balance between a layout that is easy to understand _and_ looks really nice (not clumsy or anything). Surprisingly, the most logical layouts are often also the most visually appealing ones. Maybe not that surprising."
No, it's no surprising since it's not easy to achieve. I'd even go so far and call a successful balance between a layout that is easy to understand and has a nice look art. Layout improvements are definitelly needed in KDE. Luckily enough for most KDE applications the layout is separated as .ui file easily editable with QT Designer so it should be possible to create a layout-improving-community. Lemme see whether we can realize something like that. =)
"However, you _have_ to make compromises somehow and if you don't even know what your application is mostly used for, then you have bigger problems than usability. ;)"
I disagree, people are always creative about using programs since in the very beginning there's no knownledge about how to use a program, and programs should rather serve users' expectations instead forcing them to go the "one and only true way".
"No, a "perfect balance" can be more than a default. It often requires code instead of preferences. One example that always comes to my mind is one of Gaim. In earlier versions, it had a preference for alawys showing the border around buttons or not. Disabling this made buttons in the IM window much nicer but looked completely stupid in dialogs (this was the default though). Enabling this, was exactly the opposite. :) Now this option is gone but buttons in the IM window have no border while dialog buttons have. Much better. Now you could still have this preference somewhere with one more option (like "automatic") which is enabled by default, but it's not really important anymore. So sometimes eliminating a tradeoff preference _can_ be a win for everyone."
Being mostly KDE only I never used Gaim, and what you just wrote about it let my hair stay on end since it's a very obvious consistency breaker which I'd never agree with. If a particular corner case looks bad then it's either a layout or a style issue, never an application issue. Obviously this has been "fixed" in Gaim itself, but wherever else it will appear again it will look broken again. Lack of consitency is the root of all evil.
"You are probably getting at the typical "the developer should not assume to know best" flame... :/ This is arguable, if you do your usability homework, you should actually be able to cover all use cases. So if you can do this, there is no point in adding more options and thus increasing complexity and inflexibility."
Funnily enough an increase of options and thus flexibility is often requested by users, ie. those people who are part of your very use case. And there we get back to the "the developer should not assume to know best" flame.
"I usually find that if I try to change the behaviour of an application via an option that wasn't meant to be actually used, the result is everything but useful."
If you don't use something it by far doesn't mean that nobody uses it. And there we get back to the "the developer should not assume to know best" flame. =P
"Case in point: I like to have labels below my icons because it makes them larger click targets and is sometimes helpful. But KDE is not meant to be used like this so when I set this option, it looks extremely horrible with Konqueror and it's "Increase/Decrease Font Sizes" buttons, they are simply too long."
You could switch to Chinese or Japanese, I'm sure the texts will be much shorter then. ;) But since you mention that "Increase/Decrease Font Sizes" buttons with text are too long, did you consider simply removing those buttons? (I'm assuming you don't really need them, otherwise you'd be happy about the increase of click area. ;) )
"The other option "Text alongside icons" is even worse, especially compared to the "priority text" which would only show labels besides important icons."
I don't see a "priority text" feature in KDE so far, but this sounds like a very useful feature which should be added sometime (fully optional and customizable of course). =)
"So I went with icons only in the end. You could argue that the solution to this would be to improve text below icons (having small labels and larger tooltips would be optimal) and text alongside icons to act like priority text and I would agree with this"
Great, then let's work on that. =)
"but my point is, that the developer should think about this _before_ adding preferences."
And there you miss the point: These preferences are globally available in every single KDE application on a library level, developers don't "think" about them but they are automatically added. Every KDE application's toolbar is fully customizable. Applications trying to circumvent this and thus breaking consistency are not allowed into the official KDE packages.
"Having preferences that aren't actually meant to be used and fully supported has rarely turned out to be helpful in my experience."
You are (unknowingly?) showing your ignorance if you are serious about "preferences not meant to be used", of course they a meant to be used and they do work and thus are most likely actually used. You not liking them by far doesn't make them useless for everyone else. And there we get back to the "the developer should not assume to know best" flame.
"I don't have to live with anything, if something is dumb, then I can go to a bugzilla or a mailinglist and complain.. err discuss about it. :) This way developers are forced to actually do something usable. And if there is a really good reason to have a certain functionality that isn't useful for the majority of people, then it can still be made optional."
I see, so you are saying what developers want but users don't becomes optional while what users want but developers don't gets removed? Do you see my very point here? ;)
"People really tend to get angry about this "developer knows best" attitude but in reality, this is extremely exaggerated."
For KDE I have to agree, for what I know and hear about Gnome I tend to disagree (feel free to educate me about Gnome though).
"I also never said that this can't work with sane defaults which can be changed. If an application works great out of the box and is easy to configure for the important stuff, then I don't mind it having 3000 more options somewhere hidden where they never get into my way."
This is what KDE tries to archieve while pleasing as much people as possible. Everything else is just unnecessarily provoking forkes which can be deathly considering the general lack of people willing to actually contribute in every project.
"It just has no additional value for me so I don't mind their absence in Software that is often flamed against but works great for me without all those options (you know what I mean)."
Yes, if you don't use particular options then you surely won't mind their absence either, of course. Just bad that imo it's impossible to significantly narrow down the amount of options in general this way since while a user might only use, let's say, 50% of all options, every single user most likely use a different 50% of all options.
I disagree, people are always creative about using programs since in the very beginning there's no knownledge about how to use a program, and programs should rather serve users' expectations instead forcing them to go the "one and only true way".
That's like saying there should be five ways to use a toaster. At the end I rather learn how a toaster is meant to be used than use such a monstrosity of toaster. :)
I don't want to argue about weither is the "right" way because this would be rather pointless now (it's the same old flamewar without any new arguments) so I'll keep it with saying that I much prefer to learn how to use an application the way it is meant to be used (which should be a very efficient and convenient way of course) than using an application which allows me to use it five different ways. This is my personal preference so there is nothing you can disagree with. :)
There seems to be more and more a split between those who have no problems to adjust to an application while getting simpler and usually more efficient interfaces and those who prefer to adjust the application because they don't want to change their habits. This split has nothing to with "advanced" and "newbie" users though, people are split in all groups.
I have yet to find an application which really excells in both areas without compromising one of them.
Being mostly KDE only I never used Gaim, and what you just wrote about it let my hair stay on end since it's a very obvious consistency breaker which I'd never agree with.
No, it's not. Borderless buttons are used for toolbar items, even in KDE. The buttons which have no border in Gaim are actually toolbar buttons, it's just not always that obvious for an IM client. :) So it's pretty consistent now, I just gave this as an example where choosing a sane default for a preference wouldn't cut it because both options are idiotic and it's much better to fix the problem while getting rid of the preference. If the Gaim developers would have thought harder before adding this preference, they might have found the solution earlier. ;)
Many options in traditional free software projects are added much too careless, because customizability was always regarded as a good thing and an easy way to please the users, without really considering the disadvantages and consequences.
That does not mean that all options are bad!
But since you mention that "Increase/Decrease Font Sizes" buttons with text are too long, did you consider simply removing those buttons? (I'm assuming you don't really need them, otherwise you'd be happy about the increase of click area. ;) )
a) They are useful but it looks silly. :)
b) If I wouldn't have removed loads of buttons already and be on a huge screen (1600x1200), not all buttons would be visible at once thanks to this large labels.
c) In fact, I tried to remove them but they are part of either the "" item or one of the two "ActionList" items (don't ask me which). When I select one of them, the help text tells me "You can move it, but if you remove it you won't be able to re-add it". Thanks. ;)
Another downside of the "one UI fits all" interface I assume.
And there you miss the point: These preferences are globally available in every single KDE application on a library level, developers don't "think" about them but they are automatically added. Every KDE application's toolbar is fully customizable. Applications trying to circumvent this and thus breaking consistency are not allowed into the official KDE packages.
I did not miss the point and I'm fully aware of this. I wasn't suggesting that the application developer should have to decide this but that the customization for the toolbar should be limited to a level that makes it possible for application developers to completely and perfectly support (and test!) all its modes. In the end, all I care for is that it works well, which it doesn't.
You are (unknowingly?) showing your ignorance if you are serious about "preferences not meant to be used", of course they a meant to be used and they do work and thus are most likely actually used.
You just aren't getting my point. Ok, "not meant to be used" was probably not the right wording. Let's say "not fully supported and tested" instead. This will just make the application look unprofessional and buggy, without beeing really useful for people like me who would actually want such a feature. I found that many applications which have a lot less customizability, allow me to make a lot more choices in the end because each and every preference has a reason and works reasonable well. Like the GNOME toolbar which has only three options (icons only, text under icons, priority text) which all work really well (aside from the current problems with different GNOME toolbars, which is an implementation problem) while for the generally more advanced KDE toolbar, the only option that is of real use for me(!) is changing the size of the icons which unfortunately doesn't even seem to be available as a general desktop setting (unless it's well hidden, heck the "toolbar" settings are well hidden anyway in Appearance & Themes -> Style -> Miscellaneous =)).
"People really tend to get angry about this "developer knows best" attitude but in reality, this is extremely exaggerated."
For KDE I have to agree, for what I know and hear about Gnome I tend to disagree (feel free to educate me about Gnome though).
What do you want to be educated about?
This is what KDE tries to archieve while pleasing as much people as possible.
Yes "tries". :) I'm not convinced that it's even possible without pissing off quite a few very loud persons. But if it works out, I would be just as happy about it.
Initially I just entered this discussion to say that not every advanced user prefers endless customization and that's a fact (me is proof). :) I don't doubt that there are advanced users who do prefer endless customization.
Oops sorry I wanted to preview first but then forgot about it.
> Applications should serve a certain purpose and the interface should be optimized for this. There is no point in assuming that the user might want to use this media player for something else than watching videos. That's why specialied applications are great and Emacs is such a usability monster. ;)
The line between Applications and only one interface can be quickly blurred, and has already been blurred through embedding technologies. Case in point: Internet/Windows Explorer and Konqueror. This is why "view profiles" in both applications exist, and are switched transparently. A new computer user may perhaps not even know they are using the same application when they browse the web and manage their files. This is good. Computers are a tool, and things should be task-based, imho. Whether or not an tool is implemented as a shared library that embeds in a container or an seperate application should probably not even be known by most end users.
> Labels are one very good example. If something is nicely labeled, you immediately know what it's supposed to do. It should always be possible to quickly learn what something will do after the user learned the basic principles of the particular interface.
I fully agree.. I think that toolbars in KDE applications should be paired down and "text under icon" should be enabled by default. In usability studies, Short textual representations of actions have long been shown to be far more readily understood than graphical representations, which in turn is more readily understood than longer text.
> If an application works great out of the box and is easy to configure for the important stuff,
I think a good solution to this would actually be a "first run wizard"-type of dialog that can be rerun/resumed. Hiding options is imho, not the optimal solution. Getting rid of useless options is of course, good.
In the long run, I think something completely new is needed. I think a task-based preference system for ALL apps would be good, in fact. Supposadly, a tasked based mode for kcontrol is in the works for KDE 3.2... anyone know the progress of that?
"I think a good solution to this would actually be a "first run wizard"-type of dialog that can be rerun/resumed. Hiding options is imho, not the optimal solution."
Wizards may have their place but I don't think that customization is one of them. How should you know what you want or need without using the application for a while first. :) And running a wizard each time you want to change a setting (for whatever reason) doesn't strike me as very elegant. Despite that it would be even less direct modification than dialogs without instant apply.
Hi gnome-troll!
Really sad for seeing KDE so far better?
Less is more is the message of those which haven't it!
Why are people here, so defensive when someoene even mentions another DE or OS. If I said I liked many of Nautilus's options better than Konqueor's would you jump on me too? This is logic, different programs have different features and therefore Nautilus si bound to have cool things Konqueror doesen't, like the more intuitive side panel, zoom, emblems,shadowed icon text,more logical menus (at least in stable) etc. Konqueror has many things which nautilus doesen't too, it can function as a browser (not sure if this is really such a good diea for usability though), it can split views, it has tabs, it cana cess more protocols, etc.
LEARN FROM EACH OTHER, PRETENDING THE COMPETITION SHOULD BE IGNORED IS A MISTAK!
Also, why is there a need for Kwrite, it seems like a little dumbed down KAte, which is already a verylight text editor. IMO, Kwrite should be REMOVED from KDE unless there is real resistance, there is no point for it, Kate is not a heavy app, Kwrite just confuses people since it sounds a lot like a word proecesor. IE OO Writter, SO writter, definetely does not sound slike a text editor.
BTW: Does KDE have those awesome drawers like GNOME in CVS? That's the only major things I wish KDE's panel had.
Don't feed the troll. ;)
As for Gnome alike drawers, no there aren't really any. Kicker is probably KDE's last relict from KDE 1.x days, possibly Slicker (http://slicker.sf.net/) can become a worthy replacement for it sometime.
1. I seriously doubt that he's trying to troll- just he's bringing in lots of things that have been discussed quite a bit already without perhaps reading past discussions on them.
2. kicker isn't from KDE 1.x.. it's from KDE 2.x. kicker is
3. (Going back to grandparent post) What awesome drawers in gnome-cvs are you talking about? I have gnome-cvs installed, but I haven't seen any drawers that have not been available since GNOME 1.0. Yes, 1.0.
It would of course be handy to have that in KDE, but I'm not sure if anybody ever used it much. It's cool to swallow whole apps in it though and have it as (the equivalent of) a virtual menu.
> more intuitive side panel, zoom, emblems,shadowed icon text,more logical menus
For what it's worth, I prefer konq-cvs' side panel and zooming. Emblems and shadowed icon text are cool, and kudos to anyone that implements them in Konqueror, but I consider them minor things personally.
In terms of logical menus, do you use CVS kde? If so, an actions submenu was supposed to have been commited yesterday. I have a week old CVS copy, but am compiling a fresh copy now :)
> LEARN FROM EACH OTHER, PRETENDING THE COMPETITION SHOULD BE IGNORED IS A MISTAK!
And people routinely do. Neither KDE nor GNOME would have been so great if it were not this fact.
Keep in mind that KDE and GNOME developers may not have the exact same priorities as you. Most of them (especially on the KDE side), are purely volunteer-based and work in the free time. Many of them are busy students or have full time jobs. The developers on both projects tend to listen to people, but they may not always agree nor have the time to code it. If code wrote itself, there would already be emblem support in konq.
So, what I'm trying to get at is: instead of whining incessently at every other article, you should probably start learning C++ and start coding some of the features you want! This is the best way to do it, and fits in well with Open Source development.
> Also, why is there a need for Kwrite, it seems like a little dumbed down KAte,
Please refer to kde-core-devel mailing lists a few weeks ago, or the subsequent Kernel KC articles about that. No use beating a dead horse. kwrite, kate, and kedit are here to stay for the time being in KDE. Some of them will of course, be shifted around. Kwrite and kate will no longer both be in kdebase, for example.
> In terms of logical menus, do you use CVS kde? If so, an actions submenu was supposed to have been commited yesterday.
Which is even inserted if it contains only one item. :-(
Which is a good idea considering that this keeps the menu layout consitent.
The only big problems with kicker IMO are:
1. No drawers like in GNOME
2. Not good enough drag and drop support, for example I can't drag the trash to kicker and use it.
3. backgound image is not rotated when Kicker is moved. to another position on the screen, from bottom to side for example.
4. No fake transparancy. (waiting for Xfre eis probably the best option though or all the work will go to waste).
5. No shadows. (waiting for Xfre eis probably the best option though or all the work will go to waste).
I'm sure there are a lot of other things which could be made better or included, but this is waht I rally want the most.
I also think CardDesk from Slicker absolutely rocks! I really hope to see this become part of Kicker. I really don't like anything else about Kicker expet CardDesk, but I love CardDesk, (the idea and possibilities, it is not yet fully implemented) Anyway, my ultimate KDE panel is Kicker + CardDesk.
> 1. No drawers like in GNOME
Does anyone really use these? Not many people did when this feature existed in gnome-panel in gnome 1.x. This was one of many features silently removed from gnome-panel in gnome 2.0, but silently, and unhereldly reimplented later.
> 2. Not good enough drag and drop support, for example I can't drag the trash to kicker and use it.
True. Trash- special button would be great addition to kicker.. perhaps you could write it even! submit to kde-devel when done :)
> 3. backgound image is not rotated when Kicker is moved. to another position on the screen, from bottom to side for example.
hmmmm.. i'll have to take a look at this.
> 4. No fake transparancy. (waiting for Xfre eis probably the best option though or all the work will go to waste).
Transparency support is in cvs already.
> 5. No shadows. (waiting for Xfre eis probably the best option though or all the work will go to waste).
There are patches that do this already. Perhaps one of them will be included in cvs in the future. This is even hackier than Window-shadows, btw.
Thanks for the info, Well I really like the drawers and emblems in GNOME and I would like that to be in KDE. Sorry, about the trash thing, I don't know Qt, I;m jsut starting to learn C++ though.
About the shadows and transparancy, I think its a waste of coding, it will get replaced by Xfree's whenever that comes and it sinconsistent. For example menu shadows will only show up in DE apps, not in gnome apps etc. It would be much better to code this into X.
> 1. No drawers like in GNOME
I have to agree with the other person who replied - I don't think these are really used all that much and in fact I think there was a discussion about removing them once.
> 2. Not good enough drag and drop support, for example I can't drag the trash to kicker and use it.
This is kind of a generic problem with KDE and GNOME. You can't drag trash to the gnome panel either
> 4. No fake transparancy.
This is kind of a cheap hack in GNOME, it's hardly a killer feature. Getting it to show through to applets and stuff is a PITA. Still, KDE has plenty of cheap eyecandy hacks too so this would be good to have also I guess.
> 5. No shadows.
Hmm, no panel that I know of does shadows. I think you've been fooled by people who have wallpapers with shadows "burned" on :)
Finally, yeah, Slicker looks cool....
hi kde-fans,
actually, the feature that the screensaver doesn't stop while asking for
the password is gone now. i noticed, there was a bug-report on that thing.., someone had problems because of a slow computer or something like that.
for me if there was no 3d acceleration problem, i could login while screensaver
was running. i think, that wasn't a bug, it was a feature, and there should be an option in the screensaver-dialog to select wheather screensaver should stop or keep running during unlocking the screen.
anybody who share the point of view ?
thanks,
mononoke
Personally i dont care one bit if it stops or runs while i type the pw... and yet another setting in the giu for this seems like overkill..
Perhaps a setting in kscreensaverrc tho :P (there should always be a little gold to dig out in rc-files... just so we can look more l33t the the purely click-o-rama users ;-)
/kidcat
Not yet another option, thanks.
then, maybe you better choose M$-O$..
Just one question: what do you lose when you're entering a password and the screensaver pauses during that time?
THE MATRIX screensaver stops while entering password, that's uncool!
:)
Honestly, who cares if it stops or not when entering a password, it caueses no sability problems or anything, its just a waste of coding and YAUF (Yet Another Useless Feature). IMO, it also looks beter if the screensaver is moving.
The screensaver pauses while one is typing since on slower computer it can happen that the screensaver sucks so much CPU power that it's nearly impossible to type at all. Please note that KDE is not used only on high end systems.
I'm glad you don't care that it will pause from now on. =P
If I had a computer that sucked so damb bad I would use the balck screen option or a very light screen saver.
by when we will be able to update our existing kde installation in single part ?
Could you specify "in single part" please?
/kidcat
--
hardtoreadbecauseitissolong
Duke Nukem is under GPL now.
Is there someone thinking about ... KDukeNukem ?
8-D
3d Games will be great at Kdegames !!!
I reaslise you were probably joking, but.... the engine may be Free, but unfortunately the game data files needed for play aren't.
Such thing could never be included in KDE.
I've been thinking about that many times. The code for Quake is also under GPL and i think there probably is a huge amount of game content available for free from the gaming community. Shouldn't it be possible to make a good free Quake game from the best content? Or perhaps it has been done already? (Or perhaps the textures used are under some proprietary restriction...)
Konstruct constantly fails to download anything. Bug in konstruct? Wget? Mirrors?
< cut >
Proxy request sent, awaiting response... 302 Moved Temporarily
Location: http://download.kde.org/download.php?url=stable/3.1.2/src/kdebase-3.1.2.... [following]
http://download.kde.org/download.php?url=stable/3.1.2/src/kdebase-3.1.2.... Redirection cycle detected.
make[2]: *** [http//download.kde.org/stable/3.1.2/src/kdebase-3.1.2.tar.bz2] Error 1
If you're behind a proxy you may have to configure wget for this case (env variable or ~/.wgetrc).
If you copy the link http://download.kde.org/download.php?url=stable/3.1.2/src/kdebase-3.1.2.... into konqi you will see that you can select mirroring.. i just copyied my mirror and edit the file category.mk(?) and replaced the MASTERS_SITE setting.
-ce
Thanks. That helped.
I am having problems with konstruct as well. If I try to compile kmail-crypto, the build fails on kdebase:
checking for rpath... yes
checking for KDE... libraries /opt/kde3/lib, headers /opt/kde3/include
checking if UIC has KDE plugins available... configure: error: not found - you
need to install kdelibs first.
make: *** [configure-work/kdebase-3.1.2/configure] Error 1
So, it complains I should install kdelibs first, but these allready have been installed! Any clue how to fix this?
you probably have to make qt designer look for plugins in $PREFIX/lib/kde3/plugins, you can do this with qtconfig ...
greetings,
frank
Hi,
try this:
1) mv /path/where/is/uic /path/where/is/uic.old
2) write a little script like this
!# /bin/bash
/path/where/is/uic -L /path/where/kde/plugins
3) name this script uic, make it executable and place it near uic.old
4) try the build again.
I know the last comment to this was posted ages ago, but just to say Emiliano Gulmini, your a god. Ive been searching for ages trying to fix that UIC plugin problem and that script/post has shown me what was going wrong, and fixed it! Thankyou.
Why not use qtconfig and add the missing library path via GUI?
for some reason that doesnt work.. also that script solution isnt exactly the answer either, it may make it configure, but the make scipt still cant find the plugins. its so annoying, you'd think kde would at least let you know about these things in readme file or something. maybe theres some enviroment variables or something that need to be set but whatever it is its driving me mad
Emiliano THANKS!
I found my failure.
Simply make shure qt was not coonfigured with -static flag.
I know it is off-topic, but I'm slightly enraged right now. Recently I set up an account at www.kde.com, only to find out that this site doesn't offer me anything I need when I'm registered. Thus I wanted to delete my account. I didn't find an option to do so (which would be an usual option), so I wrote an email to the webmaster.
This only gave me an quite angry reply (from an well-known KDE person) that I shouldn't use the internet if I wouldn't want to leave traces, and that he has better things to do than deleting accounts. OK, this account is no big problem for me, but nevertheless I rather like not to leave my email address at too many places.
I was thus pretty surprised, especially by the way the reply was formulated - I considered my question a perfectly legitimate one. My question: Is this kde.com really promoting official KDE policy?!?!?
I fail to see the problem. Whenever I sign up to some website (using a hotmail-account reserved for this purpose) I don't ever see a possibility to later delete my account. kde.com doesn't seem to be an exception.
OK, OK... but nevertheless I think it's a valid question. As I seemingly can't even change my email right now to something harmless...
"Is this kde.com really promoting official KDE policy?!?!?"
KDE is the name of a desktop environment. Someone (KDE e.V. [1]) has a trademark on it. kde.org appears to be hosted at Trolltech (the people who make the QT toolkit upon which KDE is built). I believe the people who run this site have a few policies regarding who gets CVS access, and they have a few policies regarding what you can do with CVS access [2]. Other than that, I don't think KDE has much along the lines of official policy.
Certainly KDE developers all have different opinions on how things should be done. KDE isn't a company where someone takes the reins and says, "you will be polite or you're fired!"
If you're not happy with that, you can set up your own KDE site (you may have to change the name) where you make the rules. Don't be surprised if noone visits it.
[1] According to the KDE myths page:
http://kdemyths.urbanlizard.com/viewMyth.php?mythID=58
KDE e.V. owns KDE copyrights and resources, and even accepts donations in the name of KDE.
...
The membership of this non-profit organization consists of and is controlled by the KDE developers. It exists only to handle the legal necessities of the project, such as handling donations.
[2] CVS commit policies
http://developer.kde.org/policies/commitpolicy.html