Bug 175972 - menu: provide menu search feature "where it is"
Summary: menu: provide menu search feature "where it is"
Status: REPORTED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.1
Platform: openSUSE Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-24 11:53 UTC by Maciej Pilichowski
Modified: 2009-03-15 12:02 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
whereitis (16.15 KB, image/png)
2008-11-25 17:21 UTC, Maciej Pilichowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2008-11-24 11:53:26 UTC
Version:            (using KDE 4.1.3)
Installed from:    SuSE RPMs

menu: provide menu search feature "where it is"

The thing is with complex (or unknown) app it is not easy to find menu item. "preview" -- where it is?

So in general my idea is to provide "where it is" feature which would work exactly like KMenu opensuse search for KDE3.5. And it works this way, that you start typing something in editbox and all items which does not matched are (temporarily) disabled.
This was the wish.

Now, just a suggestions -- where to put this so it would be accessible, i.e. user won't fall into category "where is the <<where is>>"? So I would opt for menu. I know it is against current HIG, but HIG can change as well to accommodate this approach. So it could look like this

File Edit View Window Help  [ ______ ]

with ability to turn it off. Because for some apps (like kpdf) user could not see any benefit having this, in others like kate, kile, kdevelop, konqueror -> yes.
Comment 1 Maciej Pilichowski 2008-11-24 16:26:27 UTC
Even better!

Having this feature why we should limit the word set to only menu items? It could be menu items + associations list! Not only it would be killer for translations of KDE, but also within one language.

Example:
in kate there is "find" feature, so the list for kate could be
search: find

when the user types in "find" -- find is "highlighted", but when the user types "search" he also gets nice hint.

Translations. In Polish user does not see "find" in the menu,  but when he get some help from English user? Does not matter,she/he can type in the national keyword or base (english) keyword -- still gets the same result. 
Comment 2 Maciej Pilichowski 2008-11-25 17:21:32 UTC
Created attachment 28816 [details]
whereitis
Comment 3 Maciej Pilichowski 2008-11-25 17:24:45 UTC
Or it could be more like Apple spotlight, only icon of whereitis, after click editbox shows up.

Btw. another enhancement could be not only disabling non-matches but showing matches directly below editbox (spotlight like).

(/) [ sea|     ] [v]
    | Edit → Find |
    ---------------

so user could press key down, enter, and voila -- he/she got find.
Comment 4 Casper Clemence 2009-03-15 12:02:16 UTC
Re comment #3. 

I would suggest the user should not have to press the down-arrow. The top item on the list should be highlighted automatically, items in the list should also be clickable.

It would not be _necessary_ even to have an icon as the search could be activated by shortcut, like a a sort of intra-application KRunner.