Bug 150883

err, why this has assigned product kchart? - somebody please correct this

Changed product to 'plasma'.  CC myself.

Don't assign it to AJS

I vote for K-Menu since it won't require anything but porting.

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.

Who did disable the voting-feature for this report and could we plase re-enable it? Thanks in advance :)

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. :-(

reassign to product "Kicker" since it seems at all Plasma-products voting is disabled.

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 :)

> 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.

> 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

> 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 ...)

@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.

> 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.

> 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

> 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 ?

>> 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!

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.

Users are entitled to their opinion and we should value their input.

> 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)

> 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.

> 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!

>  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

> 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.

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?!

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).

> 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).  

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.

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?

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

> 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)

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.

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 ;)

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.

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 :-/

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 :)

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!

just recompiled kdebase from svn and the applet is there - great, thanks!

(now let's figure out how to replace kickoff with it ...)

> (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]

*** Bug 153747 has been marked as a duplicate of this bug. ***