[another PATCH]: Kicker find as you type

[Fred Schaettgen]

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 
the k-menu.

Have a look at the following pictures to get an idea of what it looks like:
  http://fred.hexbox.de/kde_patches/kmenu-search-1.png
  http://fred.hexbox.de/kde_patches/kmenu-search-2.png
  http://fred.hexbox.de/kde_patches/kmenu-search-3.png

The patch against CVS HEAD (R.I.P.) can be found here:
  http://fred.hexbox.de/kde_patches/kmenu-search-fs20050503.diff

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?

Fred

-- 
Fred Schaettgen
kde.sch at ttgen.net