Bug 150883 - please provide alternative to kickoff for KDE 4
Summary: please provide alternative to kickoff for KDE 4
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 153747 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-10-16 09:14 UTC by kavol
Modified: 2007-12-09 21:45 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
compile output (2.20 KB, text/plain)
2007-12-03 07:11 UTC, David Broome
Details
the work Robert did in branches/work/kickoff-simple-menu as patch against trunk/KDE/kdebase/workspace/plasma/applets/kickoff (17.59 KB, patch)
2007-12-05 21:57 UTC, Sebastian Sauer
Details
Additional work to get it better integrated into kickoff (15.22 KB, patch)
2007-12-05 22:00 UTC, Sebastian Sauer
Details
kmenu as own applet (19.45 KB, patch)
2007-12-05 23:12 UTC, Sebastian Sauer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kavol 2007-10-16 09:14:20 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources

Hello,

from the recent news, it seems like the default system menu for KDE 4 is going to be Kickoff with no other options. However, there is a lot of users which do not like Kickoff. The reasoning varies, the biggest concern is that it slows down access to the list of applications a makes this somehow less synoptical. So, for that, classical menu like K-Menu should be an option.

I do not object against Kickoff - I agree that it is a great improvement for many users, but there is still a _considerable_ number of users who would not benefit of it, so it would be very nice to have an alternative.

I'll try to explain why Kickoff is of no benefit for me. (Note: I'll use the word "click" for any selection using mouse, even if "hover over" would be sufficient in the default configuration - this is no big difference and it would make additional concerns which would be out of scope of these examples.)

Feature 1 - Favorites
Kickoff: click to open Kickoff, click to select from list = 2 clicks, easy pointing
me: put favorites on panel = 1 click, easy pointing
other common behaviour: use icons on Desktop = 1 click if visible, otherwise 2 clicks or dragging the covering window and then 1 click, pointing not so easy (need to remember positions better)

... Kickoff does not help me, somehow comparable to "Desktop" approach

Feature 2 - Applications
Kickoff: 2 clicks to get there, do not see everything at once, having to click forth and back if I do not select the right category at the first try
me: Kmenu - 1 click to open, easy browsing, having an overview so navigating quickly even if I miss the right category at first
other approach: Tasty Menu looks like an usable compromise

... Kickoff _badly_ slows me down

Feature 3 - My computer
I cannot judge, I have no use of this, I would open Konqueror (Dolphin) directly for this (if Krusader/Konsole+mc is not available ;-))

Feature 4 - Recently used
Kickoff: 3 clicks, easy pointing
me: I do not use this (sometimes, I select from recently-used menu of the application)

... Kickoff is a winner here (I do not know about any better alternative)

Feature 5 - Leave
Kickoff: 3 clicks (is that intentional that it brings me to the same "off" dialogue as the method below?)
me: lock/logout applet = 1 click, in KDE3 KMenu for other things (3 clicks), in KDE4 right click on desktop (2-3 clicks)

... on average, Kickoff loses

Feature 6 - Search
Kickoff: 1 click, move hand from mouse to keyboard to type, and optionally move back to mouse, 1 click (note: I do not see opening Kickoff by keyboard as a typical use-case)
me: Alt+F2, type

... I do not know the exact difference between KRunner and Kickoff, for running applications and URLs I find KRunner sufficient, I do not search for documents

So, in general, Kickoff does not help me in any single task (I do not do the one in which I see Kickoff as a winner), I would use it only for accesing the applications via the tree menu (when I do not remember the name so I cannot use the search) but for this it is much worse than the classical Kmenu.

Please note that my points are not in contradiction with the SUSE usability study that is used as an argument for Kickoff - the study simply does not deal with the task I need the menu for: starting an application (if I do not know the name so I cannot type it in Konsole or Krunner/other search). This is the only thing I would need Kickoff for, but Kmenu performs better in this task.
Comment 1 kavol 2007-10-16 09:37:02 UTC
err, why this has assigned product kchart? - somebody please correct this
Comment 2 Robert Knight 2007-10-16 13:19:12 UTC
Changed product to 'plasma'.  CC myself.
Comment 3 James Richard Tyrer 2007-10-16 13:38:20 UTC
Don't assign it to AJS

I vote for K-Menu since it won't require anything but porting.
Comment 4 Robert Knight 2007-10-16 13:48:44 UTC
James,

Kickoff is compiled as a plasma applet so I'm counting it as part of plasma.  kdesktop was a separate application which kickoff is not part of.
Comment 5 Sebastian Sauer 2007-10-16 14:31:13 UTC
Who did disable the voting-feature for this report and could we plase re-enable it? Thanks in advance :)
Comment 6 James Richard Tyrer 2007-10-16 16:33:53 UTC
Continuing to have K-Menu is an alternative to kickoff.

Actually, it is a Kicker applet, but IFAIK, Kicker hasn't been ported (yet).

So, I guess that K-Menu isn't part of KDEsktop, but it certainly isn't part of Plasma.  I don't think that you should expect an alternative to kickoff under plasma since plasma isn't near finished and the clock is running.

I have no idea why it isn't possible to vote for this bug. :-(
Comment 7 Sebastian Sauer 2007-10-16 17:15:02 UTC
reassign to product "Kicker" since it seems at all Plasma-products voting is disabled.
Comment 8 Sebastian Sauer 2007-10-16 17:30:14 UTC
Seems votes got lost if the product changes. So, I would suggest to leave it in that category even if kicker is gone for 4.0.

Also, as Robert pointed out, Kickoff is just a plasma applet what means, that we can expect quit a few alternate solutions. But nevermind I guess the point the reporter made is, that it would be important to have at least one alternate (KMenu would be really cool in my eyes too :) already in at 4.0 rather then 4.1.
Now it's open to discuse if it makes sense, why not just wait for it, everybody is able to write one now, etc. Anyway, in my eyes even if noone does the job for 4.0, we still allow everybody to vote and allow them to show that way that's an important (or not so important) task for them. At the end it's all about listening what our users like to have :)
Comment 9 Robert Knight 2007-10-16 22:44:52 UTC
> So, I guess that K-Menu isn't part of KDEsktop, but it certainly 
> isn't part of Plasma.

It very likely would be if written for KDE 4.

There are two parts to Kickoff/KDE 4, the user interface and the various models which the UI displays (for favorites, recently used things, the system, leaving and of course, applications).  If there is sufficient demand for a hierarchical K-Menu (as per KDE 3) it would be sensible to implement it as an alternate UI on top of the Kickoff models.  This would avoid duplication.

As the programmer I am not the best person to discuss the Kickoff design with (as opposed to the implementation), that is best done with the team at Novell.  However I can offer comments on some of the issues raised in the original report:

> starting an application (if I do not know the name so I cannot type it 
> in Konsole or Krunner/other search

If the search works as intended, you can find an application using it without knowing what it is called.  At present the generic name and keywords associated with each application are searched in addition to the actual name.  So searching for "mail" will find all the mail clients on your PC.  Searching for "irc" or "chat" should find suitable applications.  Whole words are not required either.  "ppp" or "dial" should find kppp for example.  The current implementation is incomplete so it does a simple phrase search rather than separating the query up into words and looking for matches, but that is an implementation issue.

The KDE 3 implementation searches by binary name as well, this is something which the KDE 4 implementation does not yet do.

> (note: I do not see opening Kickoff by keyboard as a typical use-case) 

I do.  Or at least, the keyboard handling is implemented with this in mind.



Comment 10 kavol 2007-10-16 23:07:50 UTC
> But nevermind I guess the point the reporter made is, that it would be
> important to have at least one alternate (KMenu would be really cool in my
> eyes too :) already in at 4.0 rather then 4.1.

yes, exactly

> Now it's open to discuse if it makes sense, why not just wait for it

I think it is important because KDE 4 is highly awaited, and it would be sad to disappoint part of the user and potential user base - I mean, I can live with it, but it won't be good for demonstration or how to say

from the web, I got the feeling that SUSE users are not so much impressed and they frequently switch from Kickoff to Kmenu, so KDE 4 which is expected to bring many improvements would bring also a step back for them, which may leave a bad overall impression (together with other issues that will probably arise in .0 version)

there is a number of "fresh" people (users trying KDE 4 svn) who have concerns similar to mine

and there always be a number of people, who simply do not like new things

it may somehow slow down KDE 4 adoption, which I do not see as a good thing - marketing is getting important these days ...

I cannot tell the numbers, whether there are 10% or 5% or how many users who would prefer something else, but if you take 5% from the number of people using KDE, you can see that still you would please _a lot_ of people
Comment 11 kavol 2007-10-16 23:55:40 UTC
> If the search works as intended, you can find an application using it without
> knowing what it is called.  At present the generic name and keywords
> associated with each application are searched in addition to the actual name.

this is a great feature, but it has some limitations -

1) you have to know what you want to find
2) you have to use the right words from the set of synonyms (if you are able to name the thing correctly ... is newbie expected to look for "irc", or would he use "chat" - well that is part of Internet Relay Chat, but what if he just want to "talk"?)

the second one, although quite complex, may be solved by the machine

but the first one is human "failure" ... if you would like to see what programs are installed you can hardly try to type something random and look if it gets some results

my specific use-case is to pick some "pseudorandom" game if I want to kill some time - simply typing "game" would bring a looong list of which I would be tired ... browsing the menu until something catches my eye is much nicer - I tried this with Kickoff and I really do not like the menu implementation, I am missing the overview of the structure and I do not like returning the mouse to the arrow (rectangle) to get one level up; finding ksudoku (yes, in this case I could just type but I wanted to try) took me ages (isn't that 'board' - oh, it's missing category ...)
Comment 12 Sebastian Sauer 2007-10-17 02:58:49 UTC
@kavol my question where more to be meaned rhetoric but your answers are imho very logical and do make a lot of sense :)

So, as reminder (probably to myself or whoever runs into this);
the last revision Kicker was available in the repository before it was removed seems to be r515257. The interesting part, the KMenu, was located in /home/kde/trunk/KDE/kdebase/kicker/applets/menu and while there seems to be quit some magic in there, the code doesn't seem to be so much. Well, but I guess beside the menu itself also the menueditor would be needed which seems to be in /home/kde/trunk/KDE/kdebase/kmenuedit.

Beside porting that code (imho into a plasma applet would make most sense since 1. it was a kicker-applet before and to adopt it to a plasma-applet may easier then to put it into kickoff and 2. looks more logical to don't bind them together but try to just extract those code that is needed for a kmenu and have it as standalone KDE4 plasma-applet rather then putting it into something that was not that much ported at all) there may still some open questions like;
* is that really the last version? well, seems it was not ported at all. So, may better to take it from the 3.x-branch rather then from the rev I found above)
* I am pretty sure there are some more points/sideeffects here like e.g. adopting reading the desktop-files or stuff like this, that may result in much more work then just the port alone.

In any case it would be nice to know Aaron's opinion here (hint, hint, ping, pint :) if 1. if makes sense to think about such an action at all and 2. what points I probably forgot about aka additional time-eaters and 3. ?!?! since he probably knows most about that codebase.
Comment 13 Robert Knight 2007-10-17 13:41:21 UTC
> you have to know what you want to find

If you don't know what you are after, then surely speed and the number of clicks is less important than discoverability?  This is an aspect where Kickoff has an obvious advantage because it has more room to display information about each item.

> finding ksudoku (yes, in this case I could just type but I wanted to try) 
> took me ages

I'm surprised.  Without actually watching a user at work it isn't easy to know exactly what is going wrong unfortunately.

> you have to use the right words from the set of synonyms

I'd like to turn that around.  The application's keywords needs to include the words that users are likely to search for.  Presented this way, I'm sure that problem is solvable.  In Kickoff/KDE 3 it works quite well for me personally.

> the last revision Kicker was available in the repository before 
> it was removed seems to be r515257

Last night I wrote a QMenu-based model-view which displays a hierarchical K-Menu style view of the Kickoff application model.  It is only ~200 lines of code.  I think that would be a much better approach if a decision was made to include a KDE-3 style menu.

Comment 14 kavol 2007-10-17 14:40:22 UTC
> If you don't know what you are after, then surely speed and the number
> of clicks is less important than discoverability?

of course 1 or 2 seconds multiplied by, say, 10 menu categories do not matter, whether I can play something less-than-half minute longer ... but it gives completely different feeling

let me use an example you've certainly heard about a lot - GUI effects

there are people who like it, they use the latest compiz-fusion and they spend many hours by browsing the web for new themes and tweaking the appearance of their desktop

then there is a second group, who tried compiz/beryl/whatever, they said "wov, nice!" and then uninstalled it ... just because watching window burning for the first time is funny, but watching it always is annoying even if it takes only 1 second more than to simply let the window disappear

I am in the second group ... the time does not matter, it's just the feeling "I have to wait until it burns"

simply put, it's not that I do not want the speed just because I do not need it

> This is an aspect where Kickoff has an obvious advantage because it has
> more room to display information about each item.

this is a matter of personal taste ... I do not need much more info than name and 2-3 words describing the application (like "Psi - Jabber Client"), so expanding to next line(s) would actually make the things worse, less compact
Comment 15 Sebastian Sauer 2007-10-17 20:58:27 UTC
> Last night I wrote a QMenu-based model-view which displays a hierarchical
> K-Menu style view of the Kickoff application model.

Great thing! :)

> if a decision was made to include a KDE-3 style menu. 

maybe a mail to panel-devel@kde.org and/or opensuse-kde@opensuse.org ?
Comment 16 Sebastian Sauer 2007-10-17 23:13:35 UTC
>> Last night I wrote a QMenu-based model-view which displays a hierarchical 
>> K-Menu style view of the Kickoff application model. 
  
> Great thing! :) 

Thinking again about it, I guess my reaction was underrated. The initial feeling I had while reading it was; "yes, that's why I love KDE so much"
So, thank you so much, Robert!
Comment 17 Aaron J. Seigo 2007-10-19 06:07:47 UTC
Robert: could you please just commit this to extragear so we can be done with it? please close this bug when you do. thanks.

and for everyone trying to play usability person in this thread: i understand you may like to keep your workflow if only because people hate change (i'm not innocent there either), but maybe hold off on the general usability punditry. kickoff has actually gone through a good amount of testing and i'm quite satisfied with it as a solution. i know there are those who don't like it, but they tend to belong to a specific demographic.

just install Robert's menu based thing from the extragear package and be happy.

aaron, who really dislikes justification arguments.
Comment 18 James Richard Tyrer 2007-10-19 07:58:29 UTC
Users are entitled to their opinion and we should value their input.
Comment 19 kavol 2007-10-22 20:41:06 UTC
> just install Robert's menu based thing from the extragear package and be happy.

please, where is is exactly? - I see nothing appropriate within http://websvn.kde.org/trunk/extragear/ (and subdirs)
Comment 20 Robert Knight 2007-10-22 21:56:25 UTC
> please, where is is exactly?

I haven't committed it yet.  I will make sure that a note is made in the commit digest when it is.
Comment 21 Ariszló 2007-11-11 00:31:02 UTC
> If you don't know what you are after, then surely speed and the number of clicks is less important than discoverability?

Discoverability is exactly where an "old-school" menu tree gives more clues to the user than Kickoff's Applications menu that hides all but the active directory of the menu tree.

> Last night I wrote a QMenu-based model-view which displays a hierarchical K-Menu style view of the Kickoff application model.

That's great news. Thanks a lot for taking the trouble!
Comment 22 Robert Knight 2007-11-11 04:20:14 UTC
>  Discoverability is exactly where an "old-school" menu tree gives more clues ...

Well I'm afraid that experimental evidence disagrees with you there.  You can read details about the tests and the results here:  http://en.opensuse.org/Kickoff
Comment 23 Ariszló 2007-11-11 15:23:58 UTC
> Well I'm afraid that experimental evidence disagrees with you there.

No, it does not. None of the tasks directly compare Kickoff's Applications tab with the traditional K Menu. Most tasks at http://en.opensuse.org/Kickoff/Results_taskcompletion are search-oriented and they only show that Kickoff's search feature is cool. No one is denying that.

Also note this diagram:
http://en.opensuse.org/Image:Sample30_my-startmenu.png

As you can see, the relative majority of users are most familiar with the Start menu of Microsoft Windows. Windows users do not normally develop skills to use a well-organized applications menu because they never see one. People who are skilled in desktop search but not in browsing a menu will necessarily perform better in search-oriented tasks.
Comment 24 Sebastian Sauer 2007-11-12 04:45:20 UTC
Just as hint;

The great implementation Robert wrote could be tests atm with;
1. cd kdebase/workspace
2. svn co 
https://yoursvnusername@svn.kde.org/home/kde/branches/work/kickoff-simple-menu
3. echo "add_subdirectory( kickoff-simple-menu )" > CMakeLists.txt
4. recompile with "cmake -DDEBUG" && restart the kde4-session && open konsole && run "kickoff --simple-ui"

Now, I did promise to write a unittest for it since we need it to be sure that the implementation keeps on to work even if the underlying functionality changes. So, while I started already to work on it ( http://kross.dipe.org/kickoff-kmenu-tests.tar.gz ) I just realized that there exist http://labs.trolltech.com/page/Projects/Itemview/Modeltest now which is exactly designed for such things :-/

Looking at the README of http://labs.trolltech.com/images/9/9f/Modeltest-0.1.tar.gz I wonder a bit if to just write some testdata for it would fullfit the requirment of a unittest for it and would allow to move it out of playground to extragear or to whereever this could land?!
Comment 25 Sebastian Sauer 2007-11-12 04:53:27 UTC
re my prev comment (which has quit a lot of typos);
wouldn't it be an option too to merge that functionality into kickoff itself to allow to somehow use it direct without an additional package? Looking at Mandriva 2008, that's exactly what they did there (iirc left-click opens kickoff and right-click the kmenu).
Comment 26 Robert Knight 2007-11-12 12:22:07 UTC
> now which is exactly designed for such things :-/ 

I hadn't seen that, it sounds ideal.  

> wouldn't it be an option too to merge that functionality into kickoff itself

Sure.  It would then be a simple option on in the Settings dialog for the menu (or perhaps the right-click menu as per SuSE's implementation).  
Comment 27 David Broome 2007-12-03 07:11:03 UTC
Created attachment 22294 [details]
compile output

I think svn checkout is missing some files.

I like the new kickoff, just wanted to see the options.
Comment 28 Ariszló 2007-12-03 11:28:43 UTC
Why not unite the best of both the K Menu and Kickoff? Four of Kickoff's tabs facilitate tasks but navigating through its Applications tab is a nightmare. Why not have an Applications tab that inherits the advanced technology of K Menu's hover-over Applications tree breaking through the walls of the Kickoff box rather than sticking to Kickoff's old-school click Next/Back dialogs?

Or even better, why not have both: Kickoff's old-school click-click dialogs could be the default for pda's to save screen space and the hover-over menu tree could be the default for desktops or high-resolution laptops?
Comment 29 kavol 2007-12-04 14:28:19 UTC
the steps from comment #24 fail for me :-(


make[2]: *** No rule to make target `/krunner/org.freedesktop.ScreenSaver.xml', needed by `workspace/kickoff-simple-menu/screensaver_interface.cpp'.  Stop.
make[1]: *** [workspace/kickoff-simple-menu/CMakeFiles/plasma_applet_launcher.dir/all] Error 2
Comment 30 Michael 2007-12-04 16:03:19 UTC
> the steps from comment #24 fail for me :-(

Change line 23 in workspace/kickoff-simple-menu/CMakeLists.txt
> set(screensaver_xml ${KDEBASE_WORKSPACE_SOURCE_DIR}/krunner/org.freedesktop.ScreenSaver.xml)
to
> set(screensaver_xml ${CMAKE_CURRENT_SOURCE_DIR}/workspace/krunner/org.freedesktop.ScreenSaver.xml)
Comment 31 Sebastian Sauer 2007-12-05 21:57:38 UTC
Created attachment 22370 [details]
the work Robert did in branches/work/kickoff-simple-menu as patch against trunk/KDE/kdebase/workspace/plasma/applets/kickoff

The patch above is nothing else then to integrate the great work Robert did in
the branch into the trunk. No additional changes where made by me.
Comment 32 Sebastian Sauer 2007-12-05 22:00:21 UTC
Created attachment 22371 [details]
Additional work to get it better integrated into kickoff

The patch above does go one step future and tries to integrate the kmenu better
into kickoff.

Requirement;
* you need at least the sourcecode of the kickoff-applet which is at
http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/kickoff/
* you need also up-to-date kdelibs+kdebase sources (aka either compiled from
sources or packages provided by your distributor that where created after
2007-12-02). So, the easiest way is if your distributor does provide weekly
builds like SUSE does or if you are gentoo-user :) Another way would be to wait
some days till KDE 4.0 RC2 got released and till your distribution provdes
packages of them. If that's the case you may only need to recompile the
kickoff-applet itself.

Get it running;
1) download the kickoffkmenu2.patch
2) apply the patch with: cd kdebase/workspace/plasma/applets/kickoff && patch
-p0 < kickoffkmenu2.patch
3) recompile kickoff

Play with it;
if you press the CTRL-key during clicking on the big blue K that normaly starts
and shows up kickoff, the kmenu will be displayed while without CTRL-key
kickoff will be displayed.

Remarks;
* This is work in progress and I know that the CTRL-key solution sucks, but it
was just the easiest way to integrate it.
* It would be nice if someone could take a look at it to see if it goes into
the correct direction since without feedback I am not that much motivated to
continue to work on it (inherited from my dislike to work for the trash ;)
Comment 33 Aaron J. Seigo 2007-12-05 22:06:31 UTC
suggestion: in kickoff/ there is an applet/ subdir. how about adding a simpleapplet/ subdir, put the code for the simple version in there, linking against the same core code as applet/ itself and with its own .desktop file. that way we, rather easily, get two menu applets that are separate and individual.

the difference code wise between the two applets would be that one would have the MenuView as its private member, and the other would have the Launcher.

this would be a simple matter of `svn cp applet simpleapplet`, making those couple of changes and adding simpleapplet to kickoff/CMakeLists.txt

with that small change i'd be happy to see it committed to svn.
Comment 34 Sebastian Sauer 2007-12-05 23:12:50 UTC
Created attachment 22373 [details]
kmenu as own applet

Attached is a patch that implements the kmenu as own applet.

still TODO;
* split to have core+ui as shared lib
* unittests
* ?

offtopic;
KDE4@Linux can behave really wired if the root-hd runs out of space :-/
Comment 35 Sebastian Sauer 2007-12-05 23:21:54 UTC
eh, and while beeing so much in trouble cause of the out-of-diskspace prob, I forgot to mention, that I'll try to implement the other points named by Aaron + the open points above and then will commit it. Alos thanks for the very fast feedback, Aaron :)
Comment 36 Sebastian Sauer 2007-12-06 01:03:38 UTC
Committed with r745333 to kdebase/workspace/applets/kickoff

That means, that the simple menu will be available as alternate to kickoff now, but not in RC2 since it seems we missed the timeframe by a few days :-/

Anyway, thank you all for the feedback!
Comment 37 kavol 2007-12-06 18:05:23 UTC
just recompiled kdebase from svn and the applet is there - great, thanks!

(now let's figure out how to replace kickoff with it ...)
Comment 38 Michael 2007-12-08 05:33:22 UTC
> (now let's figure out how to replace kickoff with it ...)

It could be added to the right click menu of the applet completely
separate from Kickoff or Simple Menu...


On 6 Dec 2007 17:05:32 -0000, kavol <kavol@seznam.cz> wrote:
[bugs.kde.org quoted mail]
Comment 39 Pino Toscano 2007-12-09 21:45:37 UTC
*** Bug 153747 has been marked as a duplicate of this bug. ***