Bug 175972

Summary:	menu: provide menu search feature "where it is"
Product:	[Unmaintained] kdelibs	Reporter:	Maciej Pilichowski <bluedzins>
Component:	general	Assignee:	kdelibs bugs <kdelibs-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	wishlist	CC:	maninalift
Priority:	NOR
Version:	4.1
Target Milestone:	---
Platform:	openSUSE
OS:	Unspecified
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	whereitis

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.

Comment 5 Christoph Cullmann 2024-09-14 16:18:02 UTC

Hi,

kdelibs (version 4 and earlier) is no longer maintained since a few years.

KDE Frameworks 5 or 6 might already have implemented this wish.

If not, please re-open against the matching framework if feasible or against the application that shows the issue.

We then can still dispatch it to the right Bugzilla product or component.

Greetings
Christoph Cullmann