[another PATCH]: Kicker find as you type
kde.sch at ttgen.net
Mon May 2 23:52:22 BST 2005
On Monday, 2. May 2005 14:46, Dominik Seichter wrote:
> Am Monday, 2. May 2005 11:38 schrieb Fred Schaettgen:
> > 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.
> I think hiding is far better than simply disabling, because we don't really
> have that much space left in the menu. Keeping the overall size of the main
> kde menu is important and should be done if we display the results in the
> main menu.
As an experiment I have added the search function to the main K-Menu, which
only disables menu items that don't match. From what you described this is
hopefully a slightly different approach - it's not really the most efficient
way to start programs yet, but it's still fast and easy to find something in
Have a look at the following pictures to get an idea of what it looks like:
The patch against CVS HEAD (R.I.P.) can be found here:
Picture one was taken after opening the k-menu (I borrowed the ClickLineEdit
from amarok/libkdepim - it's not in kdelibs yet, or is it?).
Picture two was taken after typing "/pdf". There are two problems at this
point: First, it's lagging for a few seconds the first time you do a search,
because the menus are loaded on demand. Second, you can't see which program's
name actually matched - you have to open the menus first. But often it might
be enough to remember where to look for the program.
Picture three was taken after pressing <down>, <right>. The menu doesn't pop
up automatically, but it's still easy to navigate there, because the disabled
items are skipped.
I decided not to set the focus on the search line when the menu is displayed,
because the regular keyboard shortcuts wouldn't work instantly then. The
'/'-key to start the search resembles the search shortcut of khtml.
For those who want to use primarily the deep search, we could still add an
option to the context menu of the search line to set the focus on the
lineedit when the menu is opened.
Now what is the best way to show the nested results immediately, but still in
the correct hierarchical structure? Could it be worth the effort to try what
I described earlier in this thread (s.o.)? Might it be even better to leave
it as is? Or are flat result lists better?
If we show just a flat result list, we wouldn't help the user to remember the
place of the program in the k-menu. It might make people use the keyboard
more often, by making the way back to using the mouse a little harder - so
maybe that's even a good thing. But somehow I still don't think it is. Can
someone tell me why?
kde.sch at ttgen.net
More information about the kde-core-devel