This blog post has been moved to blogger.com here: http://benjamin-meyer.blogspot.com/2006/10/netflix-prize-contest.html.

A quick update to my last blog entry with the file dialog UrlEdit widget. At aKademy we got some usability testing done against this widget and found it to be quite bad. Users were not sure what would show up in the menu when you clicked on the triangles, the triangle hit area was too small and there didn't seem to be a way to get out of the editing mode. And that was just what I remember off the top of my head. Suffice it to say that idea is dead. I am quite surprised that the Vista guys hadn't discovered this through there own usability testing. A big surprise for me was just how well Gnomes (latest) file dialog did. Users were able to quickly move around and it wasn't confusing. Perhaps I hated the early version (from several years ago) when it first came out of it so much that blinded me to the refinements they have made. I wouldn't be too surprised if we put in the gnome buttons in our dialog and found the same user response improvements.

A little bit ago GTK's got a new file dialog that shows buttons for the current directory path. There has been a lot of talk about what people didn't like. So much so that in the latest Gnome version they have included a button that will bring up a line edit so you can put in a path.

A different way of showing the current path is to put buttons with menus inside of a editable combo box. One button for each directory in the path. One problem I personally had with GTK's solution was how the buttons didn't look related to each other, but by putting them inside of a combo box it looks like a single widget.

When the mouse moves over the button it is painted (like in toolbars). When you click on the button it takes you to that directory and if click on the arrow it will show all the directories inside the selected directory.

Clicking on the white space on the right hand side or on the folder image on the left will turn the line edit into a normal editable path.

This idea (hiding the line edit) is not new, you can already see variations of it in Gnome, Vista, OS X, and Dolphin. I don't know what is the best solution and right now am between the above way and the way that OS X does it. During akadamy I plan to meet up with the usability guys to get some real evidence about what is better. If the OS X way is better don't worry you can always pull up a line edit to enter a path by hitting the '/' key.

P.S. The above application is just Qt 4 and doesn't link to KDE, but notice that Qt will pull the current KDE icon theme (Kids for the first two screenshots) to get the folder icon. A new feature in 4.2

Today was a fun day. The past week I have been putting together an article on Type Managers. The article was really meant for here as a blog entry, but it grew and grew and I ended up making a full article that I put on my website. After debating the name over and over I finally kept it the way it was. Just to see if it would get accepted I submitted it to slashdot and hey cool it was accepted. Type Manager on Slashdot. Putting it up on slashdot is a fun test of my website. I made a static html page and had apache temporarily forward the php page to the html page. The server seemed to survive just fine. What makes this even more interesting is that I signed up for Google Analytics the other day so I eagerly await to see what amusing stats it gives me tomorrow. Over on slashdot most people (like normally there) didn't care to discuss the idea, but liked to talk about how the name was a bad choice or that it was obvious. My feelings aren't hurt though sense they weren't my primary target and I got to test out some of my website stuff in the process. Now, done with the /. part of this post and on onto the real part. The reason I wrote the article was for you, the KDE developers.

Those on kdedevelopers.org might have noticed some similar polls the last few weeks asking about managers that they use. Such as How do you manager your music more then %60 use amarok and another 15% use Juk or iTunes. When I asked about photos similar results for digiKam. So people on /. can yell all they want about managing there files only on the filesystem, but that is your fringe user. I use KMail to manage e-mail, Juk for music, digiKam for photos, and akregator for rss feeds. When I used aKregator and iTunes for the first time I knew that I was seeing something special even if I couldn't put my finger on it then. Putting together the article on type managers was very interesting. For example *today* konq meets most of the file manager spec that I put together, but you wouldn't know about half of the features because the interface is so cluttered. A number of us in the last six months have discussed separating Konq the file manager and Konq the all in one viewer/web browser. Putting together this article solidifies my belief that this is the right direction to take Konq (the file manager).

The article isn't just for Konq, KMail, amarok, and digiKam. There are many other Type Manager applications in KDE such as akregator and kdevelop. One of the original goals of the article was to make the list of features that a type manager should have. This way KDE applications that are type managers can see the list and understand what they are missing that would really benefit their users.

Juk has excellent meta editing and does a fantastic job of separating the filesystem from the user, and it has a good search interface, but it doesn't have the import export functionality like amarok has. Could this be why amarok is doing better? It is almost the opposite with amarok. amarok has good search, import and export, but not good abstraction or as good meta editing (in my personal opinion). I have said this before, but just to reiterate here I plan on integrating audiocd into juk and amarok and once that is done i'll move KAudioCreator into extragear and perhaps retire it.

There are other Type Managers that KDE doesn't have at all. We don't have a movie manager that I know of. There are a number of movie tools such as dvd ripper, encoding, transcending, burners, and so on. You can probably think of a few more Type Managers tha KDE doesn't have (add to the comments). So if you are looking to make a KDE application here might be a perfect idea to tackle.

One thing I noticed when looking around is that you don't want to call your Type Manager a manager on your website. Users don't want to manage music, they want to play with their files! That is why iTunes is a Music Jukebox and iPhoto is a photo organizer. The name of your Type Manager shouldn't include "Manager" in its name nor should you use the word manager when describing your application for end users on your website

Another feature that is very KDE specific has to do with the last feature I listed under Type Managers. That had to do with the interface that they provide. In OS X if you have iPhotos installed your desktop background applet will automatically let you select photos from your photo collection and in iPhotos when viewing a slideshow you can select a song to play from iTunes. This feature of Type Managers I think as a desktop KDE can really take advantage of to provide real value to us and our users.

End users like using Type Managers, they make their life easier through many different means that compliment each other. If KDE [type manager] applications integrate more Type Manager features I do believe that they will get more users.

For those who aren't on the I kde mailinglists, I have written up an article about Nine things KDE should learn from Mac OS X with pretty screenshots (hehe you know you want to click the link now).

This past week I have gotten some time to close some long standing audiocd bugs such as 64-bit issue, usability issuie and a case were audiocd would lock your cd drive. More importantly as new issues are opened I will be able to much more quickly respond. I have backported what I could to 3.4.3, which I am sure will make users happy, if 3.4.3 is released. I have begun working on changes for KDE 3.5 and 4 for audiocd and KAudioCreator. Due to binary incompatible issues with libkcddb I wont be able to do everything, but I hope to get a lot into 3.5. One patch that has been sitting in my inbox for a few months is a change for KAudioCreator to use KCompactDisc which is a new library for KDE 3.5. KCompactDisc is the wrapper of libwm and the media ioslave that behaves and looks like a normal Qt class. Sense the original version of audiocd there has been some major hacks to get around libcdparinoia's issues (bugs). So on Friday after getting in a patch in that would let KCompactDisc behave asynchronously I quickly ripped out a lot of duplicate junk in audiocd and converted it to use KCompactDisc. A few hours later I discovered that during ripping audiocd would crash... Though different methods I discovered that if I just link to libkcompactdisc audiocd would crash. Some sort of namespace pollution was occurring. After dinner I wrote a script that dumps all the symbols for the two libraries then go through each symbol in one library and see if it is in the other library. A few seconds later I had the result: new_list existed in both libraries. A nice undescriptive function name. Looking in libwm I find that new_list makes a new playlist so I changed the function name to new_playlist, updated apps that use it, recompiled and tried out audiocd. Thankfully that was the solution as I had run out of time and had to leave for a movie.

After months of waiting I finally get to announce that I am going to be moving to Norway soon to go work at Trolltech. I had my interview way back in January, but that paperwork (Visa mostly) has taken up most of the time. So for now I am busy packing.

As I can't bring everything with me I am looking to sell off my Sony 24" widescreen CRT monitor for $300 (paid $1800) and my Infiniti G35 '04 6speed Coup. If anyone is interested just e-mail me (ben ot meyerhome dat net).

In svn the idea of tags isn't the same as in CVS. To make a tag you in fact (simplified) make a copy of a revision and place it in the tags folder. This is to make it easy to get a tag as all you would have to do is checkout from the tag directory. But you could just checkout from trunk if you give it the correct revision number. If you have that revision number you can do a lot of interesting things such as determining what has changed sense the last release, see who made the most number of commits, or how many bugs were fixed (according to the svn commit logs). Unfortunettly obtaining this revision number isn't that easy as you might think.

I have spent the last few weeks using Gnome as my primary desktop to see what they are doing. One interesting thing they did was to put the panel at the top of the screen and the taskbar on the bottom. I couldn't figure out why I like it until about an hour ago when it hit me. In the top left of the panel the two menu's are text, not icons.

This blog post has been moved to blogger.com here: http://benjamin-meyer.blogspot.com/2005/02/power-of-segfault.html.