Overly large bookmark menu

[Luciano Montanaro]

On Friday 25 June 2004 20:11, Shift wrote:
> Le vendredi 25 Juin 2004 12:18, Luciano Montanaro a écrit :
> > I think this is really a Qt problem, but maybe there could be a fix for
> > the specific problem, which is that the bookmark menu can get very large,
> > and cover the menu bar, making the selection of adjacent menus quite
> > difficult.
> >
> > I use "MacOS like menus", so egoistically I could say that limiting the
> > menu height to be less than the application-available screen size would
> > be ok.
> >
> > Maybe, more in general, using more item columns earlier could be a
> > better solution.
> >
> > Another tweak that could be made is to balance the menu columns, that is,
> > once the menu has to be displayed as two columns, it could as well be
> > drawn with two columns that have the same height, or differ in height by
> > one item height).
> >
> > Is this problem fixable outside of Qt? And where should I look at to
> > fix it, if it is possible to fix it?
> >
> > Thanks,
> > Luciano
>
> Here is the bug report http://bugs.kde.org/show_bug.cgi?id=54716
> Vote for it !

This bug covers menus in general, and I expect any dynamic menu which 
can grow large enough would have the same problem as the bookmark menu.

However, I disagree on the proposed solution, since I would prefer a 
multicolumn menu, if the alternative is having to scroll the menu 
up or down. With the multicolumn menu, the selection can be quite fast,
once the item has been found (and after a while, the user probably will 
know where to point without much searching), while with the scrolling 
menu, the user would have to keep the pointer on the scroll area until the 
interesting item appears.

I think the screen is there for the applications to be used, and since it will 
be occluded only temporarily, menus should take advantage of all the area 
that is available. However, multicolumn menus as they are currently 
implemented could be improved, since the occupied area could be reduced, thus
the user would have to move the mouse around a bit less. There is the 
additional advantage to have a smaller area to paint, which could improve 
response time, especially on older hardware.

I'd like to have a closer look at this problem, but I'd like to know if there 
is something that can be done about it in KDE, or if the patch must be done 
on the Qt libraries. 

Luciano