KDE 3.4 Beta 1, christened Krokodile, was released not too long ago. For those of you who have not yet taken the plunge, Eudpytula Minor has announced some Krokodile screenshots for your viewing pleasure.
Settings:/ is nice, but it is not new and not especially convenient. Is there any effort underway to replace the myriad tree in KControl center with a search-based system? I've seen screenshots of such a design (kcontrol3) but would like to see them implemented... While we're at it is there any plan to get rid of the horrible Konqueror settings dialog and replace with a tree view?
*Search* for settings? Using a textbox and a 'search' button? That sounds genuinely insane.
yeah, open the control center, and click the middle tab (top left, three tabs: index, SEARCH, help).
type your search term...
maybe this could be done better, but well, it works, doesn't it?
Maybe if you read kde-usability you would know that trees and hierarchies are not suitable interfaces. New users don't know where the hell in the tree to find their setting anyway. We could still have a tree, but it's just not going to be usable by homo sapiens.
And yes, there is already a search tab, but it is not readily noticable, it should be on the front page. Also the most often used KCMs should be on that front page. We need something like a box that says "Enter a setting you would like to change or a task you'd like to perform" and then list tasks corresponding to those words. Not just an alphabetical list like we have now.
That might have been handy for me a couple of days ago.
I thought my keyboard was broken because it wasn't pressing any keys. Then 10 minutes later, I realised it worked when I held the keys down longer. Switched keyboards and the same thing happened, so I knew it was in software.
If only I could have gone into KControl and searched for "slow keyboard", I might have found the option which turned itself on without hunting through the entire control panel thanks to keyboard settings being under Accessibility instead of Peripherals, where it SHOULD be.
Score minus one to obscure gestures which are turned on by default and make life a living hell when activated accidentally.
Slow keyboard is accessibility feature, I would always expect it to be locaetd under Accessibility. Maybe the modules should specify more than one group they belong to but that is also unintuitive, unless you somehow make it obvious that these things are the same so that users don't become too confused what the difference might be.
Anyway, if I go to KControl, click on "Search" and type in "Pomalé klávesy" (that is Slow keyboard in Czech), it does return what I need. What else do you need?
I dunno. Part of the problem is that I didn't _know_ there was such a feature, so I wouldn't have even thought I could turn such a thing on.
Such an option really should be off by default.
Typically that feature is off by default. I know it's never been turned on for me.
The gestures were definitely on by default in the 3.4 beta. They may have been on in 3.3 as well but I might just have never been unlucky enough to trigger them by accident.
Well, Settings:/ looks VERY VERY nice!!! finally.
Would be nice to see the internal screenshots of every icons.
Anyone has such screenshots? please!
Of course, you still have KControl as a "Tweak UI".
KControl3 is this ?!
> Well, Settings:/ looks VERY VERY nice!!! finally.
Finally? As in "already in KDE 3.3"?
> Would be nice to see the internal screenshots of every icons.
What? Clicking the icons starts the normal kcontrol modules.
I have never seen those screenshots before. That is the most awesome
control center I have ever seen. Man, when I use WindowsXP I don't ever
know where to find a setting. It's like digging through a random
maze of icons, popup windows, tabs, trees, and buttons
(the "Classic" style makes it easier to find stuff).
And I have a Computer Science degree from MIT...I can't imagine how
my grandma can find anything on the WinXP Control Center. I don't
know, maybe I don't have enough practice at thinking like Microsoft.
KDE is very logical, but a tad convoluted. Those screenshots do seem
like a good design. Perhaps some tweaking would be needed, but overall,
This is very true. Round here we like to bash the KDE Control Center a lot, but if you compare it to the Windows Control Center, it's a breeze to use!
Recently I got to use a Windows computer computer again, the experience with the system settings was just horrifying. I had forgotten how bad it really is.
>This is very true. Round here we like to bash the KDE Control Center a lot, but if you compare it to the Windows Control Center, it's a breeze to use!
It certainly isn't bad. I work in a Mac (OS X) environment however, and I have to admit that Apple is certainly worth looking at in terms of usability design. Their system preferences solution is simple - just right for the "typical" user.
KDE control panel stumps even me from time to time.
Yes, that's KControl3 which can be obtained from kdenonbeta/kcontrol3
Why won't this be in 3.4? It looks really good!
I have no idea.
Well then, thank you for the helpful reply :p
Dig through the kde-usability archives and you'll find the answer (basically: too big change for a 3.x release)
> Why won't this be in 3.4? It looks really good!
That was my question that started this thread!
Do you know how I can grab the CVS source through a firewall that wont normally allow ssh access? I cannot reconfigure the firewall because that's not on my machine.
Hmm, as far as I know anonymous cvs doesn't use ssh, so what's the problem? Here's a documentation how to use anoncvs, if you didn't know already: http://developer.kde.org/source/anoncvs.html
Thanks but I have already tried that. Thing is I cannot do this behind my office proxy/firewall. Is there a way to use cvs behind firewall/proxy? I tried cvsgrab that does it but does not work with webcvs.kde.org although www.kde.org is listed as working with it.
Actually setttings:/ is still a little cryptic for average users who wonder why the :/ has to be added there. The only commands with colon and other characters most users know are the smileys in chat sessions :-)
Better would be to show a list of all kio-slaves in the location bar by default, like Explorer if you wish, so that settings:/ can appear as Settings and media:/ probably can be masked as Computer etc ...
Also see my reply titled "A user-friendly suggestion" to the main article.
Worst idea ever. Was one reason for me to leave Gnome when 2.0 came out.
Just because Windows/Gnome do it like that doesn't mean KDE has to follow.
You enter one subsection - you don't see the other sections anymore.
You open in a new folder - taskbar/desktop will be clogged with unarranged folders.
Please KDE devs stay away from this crap or at least make it an *option*, not a replacement.
Don't forget, kwin from kde-3.4pre supports xorgs composite extention. So you get real opacity, real menu shadows and this looks really cool :-)
Wow, that's extremely slow on my machine. AMD Athlon 1800+, Matrox G550, Suse 9.2 with x.org 6.8.2rc2. As soon as I start xcompmgr to get drop shadows, moving windows will become annoyingly slow.
I thought the composite extension used hardware acceleration?
Well, it depends if you have drivers installed that can do hardware acceleration, like nVidia's. Hardware acceleration doesn't just come out of nowhere :).
Just the standaard mga driver in x.org which is AFAIK accelerated.
I'm using a G550 on Suse 9.2 as well. Using only the mga driver doesn't give acceleration. You would have to use DRI support, but this does freeze the machine when closing the X session. So you better don't try to activate it. It's sad to see the quality of mga support going down. My next card will be a NVidea or ATI.
nvidia and ati dont support linux very good either. I'd say buy the open graphics card (google it if you don't know what it is, or check www.kerneltrap.org).
It is most likely not accelerated for the things that xcompmgr needs for good performance.
xcompmgr does all its drawing through the render extension, so if you want good xcompmgr performance, the drivers must provide render acceleration (accelerating image composition may be enough, if memory serves; we don't do any transforms or anything yet).
The current X acceleration architecture (XAA) isn't well set up to provide such acceleration, so things are generally slow with it. Off hand, the only cards I'm sure have any acceleration are Radeons. The nv driver doesn't, and I don't know about any Matrox or Intel stuff.
The nVidia proprietary drivers use their own X server and acceleration architecture, I believe, which is why they do a much better job accelerating xcompmgr (although it's only image composition performance that's good; I tried hacking xcompmgr to do transforms on the windows and it ground my machine to a halt).
If/When Xorg switches over to Keith Packard's server/drivers, the situation will likely improve. KAA is much better set up to provide render acceleration, which can be seen by the fact that people were running xcompmgr on his experimental xserver without performance problems.
I've got some problems with xcomposite in KDE. Firstly, when I start xcompmgr up (with any settings- this happens in every case) my desktop background disappears and turns to black. Starting this from Konsole, my original Konsole window leaves an 'imprint' on the desktop behind it and the text disappears, from Konsole. If I move the window about that original imprint of the window is left on the desktop with full opacity and I can still not see any text in Konsole. Furthermore, any menus seem to loose their background colour and become transparent and gain it again if I move my cursor over the menu. The menu regains background on the whole menu except for directly behind the text. Apart from all these (major) problems, the drop shadows seem to work fine. I'm using the latest ATI drivers and have a Radeon 9600 XT. In my console that I have started X from I see a *lot* of the following:
QPixmap::resize: TODO: resize alpha data
Also, transset does not work at all.
I'de really like to get this all working and any help would be appreciated.
Why do you use xcompmgr instead of kompmgr?
I don't seem to have kompmgr.. :o
It's part of the KDE 3.4 release.
I have KDE 3.4, yet do not have it :S
Actually, neg on that- it's kde 3.3.2, looks like it's time to upgrade.
Finally a good image browser in Konqueror. I've been trying to find something like that for ages!
Continuous view and table-of-contents support in a PDF reader! Exclamation point! I like! Yay!
Kontact looks great, as usual. But, what's with the weird alignment underneath the headers? Appointments and Anniversaries & Birthdays are centered, To-dos are one tab left of centered, Special Dates are one tab right of centered, and Inbox is left aligned.
Also, Kontact looks to be getting a little cluttered. It looks like one of those apps where they're adding everything everyone needs. I just hope I can remove the things I don't want. I've been considering using a calendar and e-mail app for a while, it's nice to have a contact's list, and I might even use the to-do list (but I wouldn't bet on it), but I definitely don't need a journal, a note keeper, RSS support, or syncronization support. Can that stuff be turned off?
>Can that stuff be turned off?
Pick the ones you want.
All this stuff can be turned off, of course.
See that in the summary screenshot, there are just the default settings (no appointments, no to-do, etc.).
Can you please vote for this issue? -->http://bugs.kde.org/show_bug.cgi?id=25820
Where is this?
I'm recompiling kdeaddons to see if it appears, but I don't see in konq-plugins something that seems related to this...
On a side note: I don't understand why something like kdeaddons exists. Why aren't this plugins merged with it's application? I mean, I understand that they are optional, so a packager will split them. But why the source is in another place?
I've already found it. It's in kdeaddons, in the rellinks directory.
Rellinks is not a blogger tool. This plugin just give access to all the "link" tag in the top of the document throw a new toolbar.
I wish the icons on Konqueror get hidden by default? I wonder why anyone would want to "cut", "paste" or even increase/decrease fonts by default. I hope the Konqueror widow that is shown is not the default one. Firefox does not seem to be less functional by having fewer items on the menu bar. Konqueor as shown has the disabled icons whose purpose I do not understand. This does not help.
Couldn't agree more. If some icons were removed, there would be more real estate enabling the "location" and "google" bar to be moved to a position just beside the "stop" button.
Oh, so not only we'll not get a less crawded toolbar in konqueror, but that we're adding one toolbar more on it showed by default hehe :-). Maybe it was added only so that people test it more than they would if it were not showed by default or something?
Anyway, I really feel that the solution to the "KDE clutter problem" is just to be slicker. We already have a fairly good framework for customzing in KDE, dcop can do marvelous things!.
My proposition is to just hide automatically unused items in toolbars and menus. It's not a perfect solution of course, but it's far better than actual one. You could always click in the bottom item ">>" and show the rest. If you are curious, you can read more about it in my wish/bug report. The rest of the post will only add some ideas to what I mentinoed in that report!
Note that you could apply my idea in some other places where it could be handy. Where? In KDE Control Center, for example! You rate most used settings. Then you can do many handy things with that information:
- In an hypothetic search bar of kcontrol similar to the one in Juk, Kmail, Amarok... you could search for settings, and the returned items would be showed in order by how much it had been used before.
- You could also configure the control center to show only the 60% or the xx% of the settings in the tree by default, ordered also by how much they had been used before.
- You could also use KDE betas and versions prior to final releases to let testers send statics about their use rates, calculate the average and then ship it as default in final releases. You could also create "profiles" for that matter: programmers, casual users, multimedia ones, etc, because testers are not usually normal users. Or maybe it's not needed, who knows - only statics will show us :-).
- You could detect which handy settings are never used (i.e. becuase they could be in a place difficult to locate) so that you can fix that problems
and.. what not!!
Maybe when I finish my exams I'll try to write a proof of concept so that people understand better my approach. I've used very little C++ and never for toolkits but I'm willing to learn and already develop in C, php, bash, etc.
Thanks for your time,
Or maybe that's the worst thing one could to.
Let's be serious things like this have been tried before on other platforms - and it just doesn't work well.
The problem is not just that too many items are visible but that too many items are _there_.
Your proposal would just hide them temporarily - and worse it would hide other items on everyone's desktop.
So in the end you'd have a VERY customized desktop on all of your workers desktops even though they don't really know about it. Sit one at another workstation and he'll be lost. Or give them a new (fresh) set up and see hw they will fare.
The main problem with that is that icons and context elements or whatever will have different locations - this is bad. There is a reason why unusded context menu items are only greyed out, but still there - it adds a huge amount of time if you have to look for the option you want all the time because it shifts location depending on what you're doing.
The other issue I have is that this might just be used as an "excuse" to add yet more options and items in places where they aren't really needed.
Like so many people (actual developers, not just stupid users like me) have said before what is needed is more thought as to what option goes where and if it is really needed there.
A feature such as described here would be counter productive.
Microsoft uses this for menus, and while I'm not going to trot out any sort of usability theories as to why, it pisses me the hell off. It's always the second thing I disable, right after 'hide extensions of known file types'.