KDE Commit-Digest for 2nd December 2007

In this week's KDE Commit-Digest: The beginnings of screen hotplug detection in Plasma, KRunner gets history support. Fifteen Pieces puzzle becomes the first Plasma applet in the game category. A block of bugfixing in KDevelop, with various other developments in areas such as a threaded debugger. Support for inequality constraints in Step, continued progress in the port of KEduca to KDE 4. Work on printing in okular. Work on Solid-based network management through NetworkManager. Various work towards Amarok 2. Milestones reached in the BitTorrent plugin for KGet. Subsystem rewrites (SSL, SFTP) in KFTP. OpenDocument format loading and saving work in KChart. Colour work in Krita, with Krita becoming one of the first applications to be able to paint in HDR. New Oxygen-themed sound effects, Oxygen icons are optimised for small sizes. New colour schemes added for KDE 4.0. Ruby language bindings based on the Smoke2 framework. Experiments in KBugBuster and on a Plasma "applet designer" application. Read the rest of the Digest here.


I don't want to sound harsh, but the Oxygen sound theme is mediocre at best, especially when compared to Vista and OSX counterpart. Just my opinion.

By AC at Wed, 2007/12/05 - 6:00am

and your suggested improvements are?

By borker at Wed, 2007/12/05 - 6:00am

Realy #oxygen is allways open the sound theme must have been in playgroung for as long as I can remember I anounced it at a blog entery and the only feed back we got was extremly positive, and now you guys decide its mediocre???? Like where were you? and where are yours sounds giii ....

By nuno pinheiro at Fri, 2007/12/07 - 6:00am

Call me stupid (I hope I am), but are these sounds actually going to sound like this? It's dreadful! Sounds like a kid's keyboard. Please tell me the actual sounds are going to be played on something different . . . ?

Oh and I agree that it wouldn't hurt at all for them to be played faster.

By Rod at Wed, 2007/12/05 - 6:00am

Sounds that sound similar have a name to it: consistent.

there is *no* problem differentiating the sound for an error (ANY error) to a notification (ANY notification) can even figure out how serious an error is just by the sound that's played. if didn't listen to the sounds one by one and actually setted up your current KDE enviornment with them you'd realize that. (of course you don't like the sound theme, so you might be better off stopping by and pick something else that doesn't make you cringe)

yes, the error sounds are mellow, all sounds *are* mellow. it was sort of a requirement.

now as to the shattering window...I will try not to curse as I explain this:

What is so amazing about blushing when that sound is played during a meeting/class/whatever by accident, the little awkward giggle and hiding your head in your shoulders as you realize that sound is outrageously annoying to anyone in the room but you (the only one hearing it in context). Because that's really the gimmick here: can you imagine an open space with 20 or 30 KDE machines playing those sorts of sounds through the speakers? could you work? could you be productive?

as to the length of the login and log off sound it will be shortened, since it was brought to my attention that the login time into KDE is much much shorter then it used to be. also, the long login sound was a requirement from the team, since there was some musing as to creating some sort of promo for KDE based on the login sound (and then some).

kudos on being silent during the development time and speaking your mind 1 month prior to release.
the specs have been on KDE's techbase since the early development of it, the sounds available on SVN, for the first few months of development I was at #oxygen on freenode, I've always been more then keen to reply to email and welcomed any good ideas that were proposed. 1 month from better have a pretty clear idea of what you want to see changed. this is hardly the time to brainstorm.


By Nuno Povoa at Mon, 2007/12/10 - 6:00am


By shamaz at Wed, 2007/12/05 - 6:00am


By Emil Sedgh at Wed, 2007/12/05 - 6:00am

I don't know how to contact Tim Beulen, but his applet designer concept sounds a lot like something I posted recently:

It would be good to work together on this.

By Lee at Wed, 2007/12/05 - 6:00am

You can find me on irc, nickname tbscope and usually in the channels #kde4-devel, #plasma and others.

By Tim Beaulen at Wed, 2007/12/05 - 6:00am

It looks, well... tasty :)
Just one thing: is there overlap between the Tasty Menu concept "Favourite applications" and kcontrol's "Default applications", and do/should they share a common implementation?

By Rob at Wed, 2007/12/05 - 6:00am

There is no overlap.

Favorite applications list apps that you'd like to run a lot. This are your own choice of applications that you'd want to be easily accessible, so you put them in an easy to reach place or list. Think of it as "My Favorites" or "Most Frequently Used".

Default applications are the applications that the system will run for a given task. For example, if you have multiple web browsers installed, but you want one to be the default, primary browser, you set that in Default Applications. So whenever a web browser is needed/called, it will launch that browser you set.

By Juan Carlos Torres at Wed, 2007/12/05 - 6:00am

the default applications in the favourite list are konqueror and kmail only as an example, but you can put every application you want in that list, so it's a little bit different

By Mart at Wed, 2007/12/05 - 6:00am

Where can I find the code for the fifteen Puzzle applet? I'd like to take a look at it (I suspect it has a bug), but I can't find it via the websvn interface (which desperately needs a search option!).

This is where I looked:

By Cultural Sublimation at Wed, 2007/12/05 - 6:00am

Very new apps generally start in playground:

And yes, a search option in WebSvn would be heaven :)

By anon at Wed, 2007/12/05 - 6:00am

Try googleing: " appyou'relookingfor".

By Martin at Wed, 2007/12/05 - 6:00am

I don't know which bug you found, but I did find one bug/gotcha just by taking a cursory look at the source code: it seems that method Fifteen::shuffle() uses a naive algorithm to shuffle the tiles. It essentially inserts tiles at random, only making sure the same tile is not used twice. Now, if I remember my kindergarten days correctly, the Fifteen Puzzle has this interesting property that only half of random starting positions are solvable...

(The easiest way of guaranteeing that a Puzzle is indeed solvable is perhaps by simply starting from the solved solution and iteratively moving one piece at a time at random).

Anyway, has anyone ever actually tried to solve the Fifteen Puzzle plasmoid? If I'm right you should get stuck 50% of the times. (Excuse me while I file a bug report...)

By Dario at Wed, 2007/12/05 - 6:00am

All positions are easily solvable.
And yes, you're right, it is more a game for the kindergarden.
It's too easy for an adult brain.

By abc at Mon, 2007/12/10 - 6:00am

It's bad enough that the preferences panels in KControl/System Settings barely fit on a 1024x768 screen, but now even a Start menu that takes so much space? Well, as long as it's optional I'm fine with it, but hopefully that one doesn't become the default some day...

By yxxcvsdfbnfgnds at Wed, 2007/12/05 - 6:00am

If you think about it: what's wrong with a full screen start menu? It's not like you'd need to use a start menu next to another application, is it? I actually like this start menu on KDE 3. But don't fear: it is not the default for KDE 4. In fact, if I read the Digest correctly, the port to KDE 4 hasn't even really started.

By Andre at Wed, 2007/12/05 - 6:00am

1. It's configurable
2. Kickoff can take up as much space too (at least in Kickoff 3 and earlier incarnations of Kickoff 4)
3. It's not the default for 4.0
4. If it becomes the default, you know you have other alternatives existing and or coming.

I once thought that way too, that big main menus were crazy. I even thought Kickoff was too big. But after reading the Usability studies done on the menu system (by our very own Celeste Lyn Paul, no less), I got thinking differently. It's a good read, not difficult to understand at all.

By Juan Carlos Torres at Wed, 2007/12/05 - 6:00am

I just read through the presentation, but I did not see anything about bigger menu's being better. While I don't personally object to big menu's, I don't think it's a good idea to point to sources who do not support these ideas. Furthermore, I think this particular bit of research is very questionable material to use. The issues mentioned on slide 16 are very real and severaly take away from any value the research may have. Personally, I don't see a lot of substantial suggestions or pointers for the actual design of a start menu here. I think that for that, work based on averages of self-indicated preferences isn't a good method to use.

By Andre at Wed, 2007/12/05 - 6:00am

Mea culpa on the wrong resource. I made a research before on studies done with different menu systems, this one was one of the sources. Unfortunately it seems that I have lost the others. Some of the points I do remember are the following (I will just try to recall straight from memory, so don't quote me on these):

1. Fitt's law, giving you a larger target area, or something like that. :D
2. User use the main menu (K Menu, GNOME menu, Start menu, etc) more than just to launch apps. They use it browse for installed apps, go to important system locations (system, places) and settings (control center), or log out. Basically the main menu is a portal to their computer, not just a simple menu like the File or Edit menu in applications.
3. Important information (or apps) at a glance, without having to go through horizontal cascading menus (this seems to be bad, usability-wise, still trying to research on that).
4. When users use the main menu, they totally focus on that menu, not the other windows on the desktop. Just as you wouldn't want your current focus of attention to be as painfully small as possible, there is not reason (aside from "minimalistic" preferences) that the main menu should be just as small.

These factors (taken together) lead to an implementation of a main menu that is (reasonably) large enough to accommodate such information. At least that's how I understood what those studies say. Unfortunately, I lost almost all my resources except that one.

>> Furthermore, I think this particular bit of research is very questionable material to use. The issues mentioned on slide 16 are very real and severaly take away from any value the research may have.

The study was done by a usability expert, a member of, an Information Architecture student, a member of the KDE 4 HIG working group, and one who does usability for a living. Forgive me if I trust her work and methods more than any other person who shouts "usability".

By Juan Carlos Torres at Wed, 2007/12/05 - 6:00am

But as André mentioned, the "Limitations of Study" slide (no. 16) do take away from the value of the research. Notably:

-Number of survey participants were not statistically significant
-GOMS modeling is limited in its application
-Method of delivery may have limited participation, and
-the time constraints.

Sure, she does it for a living, etc. but even she acknowledges her study is incomplete and lacking. It's better than nothing, and probably better than the average person could come up with (with the same constraints), but it's not infallible.

The main problem I see with a large menu is searching for information, as in scanning it with your eyes. Professionally typeset documents - books, etc. - tend to have narrower regions for information. As far as I understand, this makes it easier to read and retain information, because you can see an entire line - all the immediate context - without moving your eyes.

By Soap at Wed, 2007/12/05 - 6:00am

Well, in kde3, tasty menu doesn't take ALL my screen, and it's a shame. I installed it because it seemed to fullfill this, but was disapointed.

So I tried to maximise it, but it would automaticaly scale down...

So I returned to old Kmenu.

By David at Wed, 2007/12/05 - 6:00am

Right click -> configure -> set width and height to 100%.

By Martin at Wed, 2007/12/05 - 6:00am

I wanted to have a menu that takes a fixed amount of screen rather than the minumum possible like the default kmenu, where if there is a garzillion of installed applications some subcategories can grow to be much bigger than tasty menu is.
btw, the default is 70% of the screen width and 70% of screen height, in 1028x768 it's still pretty usable setting 50% and 50%
but after all it's a matter of well, taste :)

By Mart at Wed, 2007/12/05 - 6:00am

TastyMenu hasn't even started a port to KDE4, has never been part of the primary KDE trunk, and isn't likely to be the default anytime soon. It is just an option out there.

Frankly, I don't care for the look, and scroll-bars within a start-menu just bother me. They are my least favorite part of the Vista menu. Again, I think some people design for what will look good, as opposed to what works well from a usability standpoint.

WMP 10 and 11 look great in a screenshot, but are a pain to use. Many design elements of Vista go along these lines, including the new menu. It looks cleaner to have the menu take up a set amount of real estate and not spill all over the place. But it is simpler to navigate and unfold the menu as you need it, rather than go over to the scoll bar, go back to the menu, go back to the scroll bar, etc.

By T. J. Brumfield at Thu, 2007/12/06 - 6:00am

Now that KDevelop 3.5 is mentioned, I wonder what happened to KDevelop 4. doesn't give a lot information about its current status.

By yxxcvsdfbnfgnds at Wed, 2007/12/05 - 6:00am says the port is done and work on a development releases is going on.

By Sebastian Sauer at Wed, 2007/12/05 - 6:00am

You can
* read the blogs of Andreas Pakulat or Adam Treat(for example):
* read (not everything is related to kdevelop of course)
* read kdevelop-devel mailing list archive :

good luck

By shamaz at Wed, 2007/12/05 - 6:00am

i really like the way tasty menu works. one thing i don't like about most GUIs is that you get a lot of popups (menus, message boxes, etc) which should be as few as possible. for example in many applications (kde or not) when an error occurs you usually get an error box that stops the flow of your work. at least for the non-critical errors there should some kind of bar or something that lists everything that happened. (this is also useful if you get many errors/warnings and you can't remember them)

By voicu at Wed, 2007/12/05 - 6:00am

initially i started as kickoff hater, but after using it for a while in opensuse (kde3) i find it absolutely essential. it's really an all in one place for information/devices/application in your system.

the only place kickoff seems annoying is finding application like the old win95 start menu.

but there is a much better and easier way..

just type "player" (or part of the name) to find all media players.. or type "browser" to find all browsers installed, which is the fastest way to find an application by name or by application type.

kickoff for kde4 needs a few improvements like in kde3's version and it will become one of the most loved application of kde4.

hopefully implemented by kde4.0

1. resizeable kickoff like kde3.
2. clicking on applications button/tab will bring to the Top-Level of application menu.

other usability feature i would like to see is:

1. the right-left sliding is rather slow and hence visually annoying.. it can be sped up or no slide-animation or some fast fade-in animation would be nice.

2. the < top-level back bar on the left, should blink to inform the user that the parent menu is on the left side.

3. and a dolphin like location-bar on top for "application tab/button" should be implemented for kickoff4 too, which allows quicker access to top-level folders/menus. when implemented, users can know where in the menu they are.

thanks aaron, and kde4 team for making kde4 cool :)

ps. just before you jump to slaughter kickoff, please use it with opensuse's kd3 for at least a few hours.. and feel the difference ;-)

By Asif Ali Rizwaan at Thu, 2007/12/06 - 6:00am

I agree. In fact they just added the "old" style menu back as an option in svn.

I found that I could no longer stand it. I much prefer kickoff now.

By JackieBrown at Thu, 2007/12/06 - 6:00am

Step 1 - Click in field.
Step 2 - Type in "player"
Step 3 - Wait two seconds for it to search
Step 4 - Look through the list for mplayer, kplayer, etc.
Step 5 - Click on the entry you need.


Use a standard menu, hover to kplayer in about 2 seconds.


Hit Alt-F2 and type kplayer

Kickoff is easily the worst of these three options. Again, you say search is a big benefit. openSUSE proved you can add search to the old style menu. Raptor and Lancelot will have search. People aren't hating on search. Add search options for those who want to use them. It is the clicking, and navigation style of Kickoff that is horrible. There is no reason why you can't have the preferred old navigation style, and also include search.

And the other thing that gets me is how we've sacrificing usability in one of the most commonly used part of the entire desktop for what? Search within the menu is something I can't imagine will get a lot of use in the long run. If you are new to Linux and KDE, and need to find an FTP app, it might be useful to search for what FTP apps you have installed with your distro. But in the long run, eventually you'll know what FTP app you have, and just start it rather than searching for it every time. And if we're conditioning people to search every time, well that is just stupid.

How did I live without search before? I just hovered and navigated to the appropriate hierarchy of the menu and just looked at what was installed.

By T. J. Brumfield at Thu, 2007/12/06 - 6:00am

my friend, the 3 methods you've talked about applies to:

1st - to the newbies to KDE/unix
2nd - to ex-windows users 9x or 2k or xp
3rd - experienced Linux/Unix users who knows the name

should the menu only work for one type of user base? experts as you are or should also consider the not so informed users about menus and computers?

search helps the new users
old menu style - application tab - for intermediate users
alt+f2 (with search) -> for experts.. who has better memory remembering odd names of application.

anyways, i appreciate your concern.. take care :)

By Asif Ali Rizwaan at Thu, 2007/12/06 - 6:00am

Aaron, why did you implement it?!? Do not listen to all those who are whining about plasma... history in Krunner dialog is absolutely useless, because in KDE3 we didn't have the results preview as we have in KDE4, so history was needed. Now with history support in KDE4 we have 2 visual ways to complete the same task competing in the same tiny windows.

I hope you get my comment right, I'm not whining, I just think that history's absence wasn't a regression at all.

By Vide at Thu, 2007/12/06 - 6:00am

"I just think that history's absence wasn't a regression at all."

And its addition isn't a detriment. I'm a big fan of adding handy little features, *especially* if they do not clutter the interface or make things harder for "new" users. Thanks Aaron!

On this topic - I hope someone could be persuaded to re-add the "Add Place" to the right-click menu in the Places sidebar in the File Dialogue, which was apparently removed for "usability" reasons. The functionality is still there - you just have to *drag and drop* a folder onto the bar rather than the far more discoverable act of right-clicking on it (I only found out that the functionality had not been removed completely by reading the mailing lists!). Not many new users even right-click on that sidebar, and I'm sure very, very few would be confused by a single entry saying "Add Place". *sigh*

By anon at Thu, 2007/12/06 - 6:00am

I am using kde4daily to test as evolving development kde4 and I am really impressed.

My most sincere congratulations to all the team.

By Jesus R. Acosta at Sat, 2007/12/08 - 6:00am