[PATCH]: Kicker find as you type
kde.sch at ttgen.net
Mon May 2 10:38:40 BST 2005
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.
kde.sch at ttgen.net
More information about the kde-core-devel