From kde-core-devel  Mon May 02 09:38:40 2005
From: Fred Schaettgen <kde.sch () ttgen ! net>
Date: Mon, 02 May 2005 09:38:40 +0000
To: kde-core-devel
Subject: Re: [PATCH]: Kicker find as you type
Message-Id: <200505021138.41320.kde.sch () ttgen ! net>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111502678803282

On Monday, 2. May 2005 09:52, Aaron J. Seigo wrote:
> On Sunday 01 May 2005 02:08, Dominik Seichter wrote:
> > To find the application, I simply search the name, comment and executable
> > name of all services.
> >
> > A screenshot can be found here:
> > http://krename.sourceforge.net/screenshots/kicker_01.png
>
> nice ... i believe there is a wishlist request for such an item on b.k.o...
Like http://bugs.kde.org/show_bug.cgi?id=32773 probably

> at first glance, something seems ... hrm.. amis.. i'm not completely sure
> what it is right now, but it seems to be in the wrong place.
> <think outloud mode>
..
> or perhaps in the Applications section, and have it whittle down the
> options so the user can learn where things are as well? (not sure how i
> feel about that, actually)

What do you mean by 'whittle down the options' exactly?
Removing/Disabling non-matching menus from the application section instead of 
showing the results as a separate menu?

Let's think loud too..
The problem here is how to handle search results in submenus. Maybe they can 
be inserted as a temporary, indented menu item below their parent, if there 
is enough room.
The procedure might look like that:
- disable all menu items which don't match or don't contain any matching item.
- For each item in the main menu which is still enabled count the number of 
matches inside (if it is a submenu). If there is enough room for all of them 
in the k-menu, insert them slightly indented below their parent item and 
disable the parent menu. Does this sound reasonable?

I'm not sure if it's better to disable non-matches in the toplevel menu or 
completely hide them. Disabling them leaves the context intact, so it's 
easier to remember the location. But not removing them won't leave much space 
to insert matches from submenus. 
Maybe it would be best to never really insert or remove items in the toplevel 
menu, but only replace them, so we only insert a submenu match into the main 
menu if we can remove a non-match at the same time.
This would make the items wander up and down while searching, but the overall 
size of the menu would stay the same. 

Currently it's possible to search the k-menu already in a non-recursive way. 
Could it be a problem for anyone, if this was replaced by a deep search?

> and it seems to have some overlap with the exec applet as well. as in: this
> functionality would be nice for the exec applet =)

Maybe the search line in the k-menu could also work just like the minicli, but 
with no extra options and no dropdown menu.

Fred


-- 
Fred Schaettgen
kde.sch@ttgen.net