As Sebas' mentioned recently, I have been working on a new implementation of the Kickoff start menu/application launcher. It is currently functional, although I have not started work on some of the presentational aspects yet (such as the background and tab styling). Hence no screenshots in this post. If you are testing KDE 4 on a system with KDE 3 installed, then in the case of applications for which both KDE 3 and KDE 4 versions are available, only the KDE 4 version will be shown. The search view is currently limited to application searches, but I hope to have Strigi searching working soon. Ideally query handlers will be shared between the launcher and the run dialog.
The new Kickoff can be found in trunk/playground/base/kickoff-rewrite-kde4/ and it currently builds both as a standalone application ('kickoff') and a Plasma applet ('Application Launcher' in the 'Windows and Tasks' category). The Plasma applet is a simple KDE logo button which pops up the menu when clicked on.
Hopefully Kickoff will ship with Beta 3 next week.
This new implementation is being done from scratch using Qt 4 / KDE 4 frameworks. This is the first time I have made any real use of some of the new KDE 4 libraries; they are great to work with and a few little extras have been added as a result. For example, one minor detail I added compared to KDE 3's Kickoff is that in KDE 3, the 'My Computer' tab always has an icon of a tower desktop system. In the new KDE 4 Kickoff the icon will change to a laptop or a tower depending on what kind of system it is being run on - and that is done with a couple of lines of code.
Finally, feedback is always welcome. If you are an OpenSuSE/KDE user who uses the Kickoff menu on a regular basis, feel free to add your thoughts to this post's comments :)
25 comments:
Hi Robert!
I'm currently missing the ability to order the Kickoff tabs in the KDE3 version although it should be able to lock the tabs in place to prevent accidental moving of them.
Other than that, thanks for the work. I'm looking forward to continue using Kickoff in KDE4.
Now we just need someone to reimplement kcontrol...
-Erunno
Glad to see someone's working on porting kickoff to KDE4. I used it on both OpenSuse and kubuntu. Judging by the number of distros it has been ported to I guess quite a lot of people actually like it !
The two "complaints" (read: places with room for improvement) I would see are:
1) the sysinfo:/ kioslave does not work (on kubuntu, that is) and I think it is actually pretty neat. I hope this gets ported as well
2) the application menus which slide in and out: I'd like to have a breadcrumb widget on top (a la dolphin) to quickly change categories and know where I am in the "application tree"
Other than that, search definitely needs to be linked into the new menu but that's apparently on the TODO, especially with strigi now available it should be quite powerful :-)
Can't wait to try that out (in beta3 ?)
Hi,
I'm loving Kickoff but I'm frustrated by the time it takes to switch between tabs. If I don't use the menu for awhile then whenever I click to use it, it will take a second or two to go to any tab other than Favorites. After that tiny bit of waiting, switching between tabs is almost instant, but that doesn't align with how I tend to use menus (and I suspect that others will say the same). I rarely look for something more than once in a short period of time and thus I rarely see the tabs switch almost instantly.
Even if my pet issue with Kickoff doesn't get fix or is seen as nitpicking, I will still love it. Kickoff isn't different to be different; it's different to be better.
-roasty
why isn't kickoff only a plasma applet?
Doesn't it make sense to use only the menu-DataEngine of plasma for such menus?
niko
> why isn't kickoff only
> a plasma applet?
Because it requires only a few lines of code to create an additional standalone application which is easier to work with for testing and debugging purposes.
> Doesn't it make sense to use
> only the menu-DataEngine of
> plasma for such menus?
No. There is no such 'menu data engine' available that I can see.
> No. There is no such 'menu data engine'
> available that I can see.
oh - I didn't know that...
although i think it would make sense - so others could easily create kickoff/kmenu-like menus and don't have to create a fork.
I've used the Kickoff menu since the very first time it was ever made available, and life with it has only become easier and more dependent on it ;-).
My family can also work with it a lot more easily and can navigate around things properly. All that usability testing has really paid off :-)
Great to hear it's being ported.
Hello,
Thank you for your great work. I am using Kickoff on OpenSuse. I really like kickoff and find it the best menu from what I've ever seen. The idea of organizing different stuff ("Apps", "Places", "Favorites" ...) into menu tabs is great.
Please keep on your great work.
Thanks
> so others could easily
> create kickoff/kmenu-like menus
> and don't have to create a fork.
Yes, that is a sensible goal. Both the models (which provide the tree of favorite,recent,all applications) and views (the list view for favorites etc. and the iPod-style scroller for applications) are designed to be re-usable.
i realy hope you are going to work on the usebility of this thing a bit. the features it adds to a normal menu are all nice, but the application menu itself is just unusable in the kde-3 version.
its way to slow to navigate through the menu. up-buttons or scrollbars just don't belong in a menu!!
so what i would like to see:
- the minimum height of kickof should be dependent on the height of the top level of the applications menu.
- make it a real menu! folders/sublevels open to the side, not inside of kickof.
those changes would make scrollbars and back/up-buttons unnecessary. it could even be optional, though i can't see why anyone could like it the way it works right now.
the current implemention favors form over function. i don't think thats acceptable for a core component like the start menu.
i tend to disagree regarding the opening of folders/submenus. i do some computer training at times (for windows), and for users inexperienced with the mouse the start menu of windows is near to unusable. the reason for this is that the sublevel closes when the mouse doesnt hover on it. this simply cannot happen with the kickoff approach. regarding the scrollbars. in a usual menu, the height varies with the number of subfolders, so the location of items vary as well. even worse, depending on the size of the menu, it opens either to the top or to the bottom. admitted, you get the whole level at a glance, but this might not always be an advantage. kickoff feels just more ordered in my opinion. perhaps try to use the search function more often if you need fast access to a specific item.
I'm a long time computer user and have no problems with the mouse and targeting submenus. But I still like the in-place scrolling much more than opening additional submenus. It is less mouse moving and it is still easier to target the items. The only thing that still bothers me here is that I have to move the mouse to target the side button to go back to previous level. So here is my suggestion:
Would it be possible to bind the going back to previous level with the Back button on some mice? The same one which goes back one site in web browsers. This way there would be one mouse movement less.
Andre: if you point at the search feature, i don't think you got the point of an application menu ;).
the application menu is meant for browsing through your applications. something the current kickoff implementation isn't really good at.
scrollbars are a great example. why whould you need scrollbars in a menu? scrollsbars hide things. thats completely against the usecase of a menu.
the location of entries varys in kickoff just as well. its even worse: to access these new locations, you have to scroll. with a conventional menu its just a flick of your hand. a conventional menu shows you everything, so you even know if its worth to move your mouse at all.
and after all, computer users need to work with menus anyway. so the greater learning curve just isn't an argument. you can't use kword if you don't understand/mastered menus.
also, a conventional menu could be driven by mouseclicks instead of mousein/out events just like kickoff - and still be much faster, because of the absence of back/up-buttons or scrollbars.
to summarize: an application menu like that of kickoff for kde-3 may be easier to master, but its much slower to use, for every usecase of a menu.
browsing through it is a pain, with at least twice as much clicks (ideal situation, without any scrolling) and no overview over the hierarchy. making it much harder to grasp the concept of the menu as a tree.
finding a known application at a known spot is also never faster than with a conventional menu - and again, with scrolling, its much slower.
in the end, a conventional menu profits from anhencements like a search function just as much as the kickoff menu. so i really can't see an improvment.
also, a search function can't (or at least shouldn't) repleace a menu for finding known applications, because most people can remember the position of the application in the tree or the icon much better then the correct spelling of the name. the fact that most people can't type as fast as they move the mouse doesn't help either.
Awesome. Thank you for working on this. I always liked the kickoff menu, and I was worried that KDE would ignore all the usability work that has been done on it, and go in a completely different direction with that plasma raptor thing. A menu is important, and it needs to be good (although I'm just going to use krunner for everything anyway).
I hope that kickoff can be configured much better ways than right now. I mean how to apply a style for it. How to organize big tabs bottom. How to remove elements from menu (like all mounted system partitions and media:// or remote://) or add there more.
I have linux installed to use 5 partitions /boot, /, /home, /tmp, /usr and all those i can see on kickoff, it's not nice. And when i plug two of my external hard-drives, they get added to kickoff but under all these other links to partitions so i need to scroll down to open my drive. It's not good for usability. I suggest that all other partition infos can be removed (even those remote:// and media://) and there would only be found those really added devices like memory sticks and memory cards or hard-drives.
I just dont get it why suddenly linux has turned to be windows2 with showing mounted partitions as places where to save things as that is power of *nix to not show them as C:\, D:\ or E:\
I hope these get's removed from KDE4 and Kickoff.
And it would be nice if you could drag applications to other places in list easily.
> finding a known application
> at a known spot is also never
> faster than with a conventional menu
If it's an application that you use frequently then the idea is that you add it to the Favorites list. I personally find that I rarely needed to visit the Applications menu after a few days use because my set of 7 or 8 frequently used applications were all in the Favorites menu.
In general I do not plan to make fundamental changes to the way Kickoff works because it is a design that has been properly tested and I do not have the means to test whether any such changes would 'break' the design. Incremental tweaks such as enhanced configurability, better keyboard navigation, better search etc. are within the scope of the project.
Reading some of these comments it seems as though some perceive the only difference between Kickoff and the old K-Menu as the tree menu vs. the iPod-style scrolling display for the application view. From what I recall of Stephan's presentation at Akademy last year, the emphasis was much more on favorites and recently used for extended, regular use. The changes to the application menu were, I think, largely about discoverability.
> And when i plug two of my
> external hard-drives
I have already fixed that particular problem. Removable storage and fixed storage are separated, with removable storage listed first.
@Robert Knight
but thats not the point, again! favorites, search and whatever else you provide can't replace a real menu. thats why its still there! and more important: those things work with a conventional menu just _as well_.
if the application menu never was the main "thing" of kickoff, i don't understand why you wouldn't even think about adding a conventional menu as an option. reading your post, i get the idea you wouldn't even accept patches, to not break the concept...
i say it again: those favorites work just as well with a conventional menu. if the favorites are the main big thing about kickoff, it wouldn't lose anything.
my problem is: the usecase where a application menu ist needed the most is where the kickoff menu has the most problems, compared to a conventional menu. sure you can use the search, or the favorites. but you still need at least something to browse through your applications. and the kickoff menu is simply much much slower at browsing, without providing any real benefit over a conventional menu.
i'm still waiting for an argument why scrollbars or up-buttons are needed in a menu. i don't think hiding stuff helps discoverability one bit ;).
I actually don't see a problem with scrollbars as they are on of the most common items you'll encounter in a desktop environment. As an added benefit the limited viewport provided by the submenu structure is also much less intimidating. The worst I can think of is my Windows XP menu on my work laptop where my employee installed about 50 applications which become visible all at once once.
And from personal experience I can attest that people (in that case my girlfriend's mother) who haven't done much work with the mouse encounter huge problems with aiming so a disappearing / collapsing menu is very frustrating to them. As already explained in this thread Kickoff deals with it very nicely by making the menu more independent of the mouse position and movement.
Dear anonymous, I can't lose the feeling that you're armchair-quarterbacking here a bit. Real usability tests have been used as the foundation for Kickoff's design so unless you can provide some solid data yourself that shows that your version is an improvement to the current design I don't see enough reason why arbitrary changes to the concept should be introduced.
-Erunno
in what way do scrollbars solve the problem of badly organized menu items? they simply don't. just like they don't speed up browsing through all of your applications.
you really need numbers for that!?
and, as i allready said, conventional menus don't have to be driven by mousemove events, they could be driven by mouseclicks just like the current kickoff menu, and still be faster.
again, i don't see why anyone would need numbers for that. just use common sense, or your mouse and see for your self. the more things you have to push, the more time it takes.
up-buttons and scrollbars slow things down.
and, if you read my posts again, you'll find i even gave you numbers. browsing through the kickoff menu takes at least twice the clicks as a standard menu driven by mouseclicks.
Kickoff menu is great!
I find moving through the menus to be very easy and intuitive.
As a heavy user of Bookmarks, I have many submenus and the existing structure of bookmark menu is unwieldy with many folders and bookmarks.
I would love to see the same thing for the bookmarks.
Current Kickoff tabs are:
Favorites
Applications
Computer
History
Leave
Is it possible to add a "Bookmarks" tab also?
-Mike
Just a few suggestions from me:
1) The one thing I really miss in Kickoff is a way of opening the "Run Application" window; though the search box at the top can work as an alternative, it seems to have trouble with items that aren't in the menu at all.
2) I'd have to suggest allowing customization of the Computer tab somewhere (obviously not where Joe User is likely to find it), simply because it'd make it somewhat easier to configure for different potential configuration systems.
"udging by the number of distros it has been ported to I guess quite a lot of people actually like it !"
I made a loose attempt to port Kickoff to Fedora, but it didn't work out. There's too much of a difference between the KDE configurations of Fedora and openSUSE to make it work.
Hi Robert,
kickoff draw the header of applications with the previous and current index
es.:
Internet
More Applications (bold)
Is it possible make headers clickable?
es.:
root | Internet | MoreApplications
so we can click only one time to came back to the root of menu.
Thanks for all.
How can I have kickoff in italian?
I posted my comments regarding KickOff's UI on my web site. I hope someone can make KDE 4 usable to us spatial memory people before the next Kubuntu is rolled out...
> I posted my comments regarding KickOff's > UI on my web site. I
Hi Meta,
Thanks for the critique. I am no longer involved with Kickoff myself. I you have not already done so, the best place to send this to get attention is panel-devel@kde.org.
Two of the main items of criticism in your report, the inability to resize the menu, the Applications tab not returning to the top level when the menu is hidden and then brought up again are known 'bugs' in the KDE 4 implementation and not part of the original design. I believe the latter has been fixed.
The difficulty of finding how the back arrow to go up the menu is something I have seen echoed in several reviews. It was something which none of the developers (myself included) encountered or thought about. The arrow is the same as in the KDE 3 implementation - there might be something subtly different about their version which I missed or perhaps it has the same problem?
I don't think a discussion of how to fix this have been started yet. I would suggest opening a bug report against Plasma / Kickoff would be the best way to keep the issue visible.
The blog entry you linked to argue that "[KDE developers] believe that there is nothing wrong with this new launcher" was not actually written by someone involved with the development but rather a user/commentator who happens to be syndicated on Planet KDE
Post a Comment