Closed
Bug 66254
Opened 24 years ago
Closed 12 years ago
submenus should act like real Mac submenus (selection is too difficult)
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
INCOMPLETE
Future
People
(Reporter: mpt, Assigned: mikepinkerton)
References
()
Details
(Whiteboard: [2012 Fall Equinox])
This is son-of-bug 5927, which was fixed by adding a delay to the closing and
opening of XP Toolkit submenus to make it easier to go from a main menu item to
a submenu item.
That's how native Windows submenus work, but native Windows submenus suck bad.
They make you wait ages before submenus open, even if you don't want to, they
can highlight items for submenus without ever opening them, and they close a
submenu too quickly when you're trying to select an item near the bottom of the
submenu.
Here's how it should work.
When the user mouses over an item which has a submenu, highlight the menu item
immediately, but wait 250 milliseconds before opening the submenu. This still
seems instantaneous, but it saves a lot of flickering and lag as you make your
way down the parent menu, and also guards against the edge case that the submenu
is so massively wide that it covers the main menu and leaves you unable to get
to items below it. (For bonus points, if you need to load stuff in order to show
the submenu, start doing that *during* the 250 ms pause, rather than when it
ends.)
Now, when a submenu is opened, draw yourself a trapezoid with these four points
(these are for a submenu which is opened to the right of the main menu --
reverse `left' and `right' below if the submenu is opened on the left):
(1) the top left corner of the parent menu item
(2) the top left corner of the submenu (this is just in case the submenu is too
tall to be completely southeast of the main menu item, in which case it
should be partly northeast as well)
(3) the bottom left corner of the submenu
(4) the bottom left corner of the main menu item.
If the cursor goes from the parent menu item (not just from anywhere) into a
part of that trapezoid which is outside the parent menu item, start a timer
which lasts for 1000 milliseconds. At the end of that 1000 ms, *or* if the user
goes outside the trapezoid, close the submenu and do whatever is appropriate
for wherever the user is now -- e.g. if the cursor is now over a new submenu
parent item, highlight that item, and then open the submenu after 250 ms if the
cursor is still there.
If the cursor goes anywhere outside the trapezoid, close the submenu
immediately, and do whatever is appropriate for where the cursor is now.
Reporter | ||
Comment 1•24 years ago
|
||
Alternatively, do a wrapper which turns XP Toolkit menu structures into native
menus ...
Comment 2•24 years ago
|
||
While opening submenus may be too fast (or too slow) for some, there IS a system
setting for this on Windows. You can only alter it using TweakUI or a similar
utility, but it can be changed. It would probably be better to use this setting
for the submenu opening delay on Windows, than to set an arbitrary delay which
might work for some, but not for others.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Assignee | ||
Comment 3•24 years ago
|
||
i seem to recall that we do use that setting. maybe not.
Comment 4•24 years ago
|
||
Mike, I just checked, and yes, that setting is already used. So if I understand
the original bug description, at least part of it (taking too long to open
submenus) should be considered resolved.
Reporter | ||
Comment 5•24 years ago
|
||
No, because there is no such setting on Mac OS, for which this bug was filed.
Such a setting does not help, anyway; it only allows you to choose between
submenus opening too slowly and submenus closing too quickly.
Comment 6•24 years ago
|
||
The menu delay has been configurable forever, using the LookAndFeel system. It
works great. (I set my delay long, to get Motif/Be style menus.)
user_pref("ui.submenuDelay", [msec]);
I think the Windows look&feel is supposed to default to the system setting.
Are people talking about a different sort of menu delay here? Or is the bug
that the Mac default is wrong?
Reporter | ||
Comment 7•24 years ago
|
||
No, because there is no such setting on Mac OS, for which this bug was filed.
Such a setting does not help, anyway; it only allows you to choose between
submenus opening too slowly and submenus closing too quickly.
If you find the original bug description too difficult to understand, please tell
me, and I'll draw a diagram.
Steps to reproduce #1:
* Arrange your bookmarks so that two folders are immediately adjacent to each
other, and so that the first of these folders contains lots of items.
* Open the Bookmarks menu on the Personal Toolbar, and hover over the left end of
the first folder item to open its submenu.
* Drag diagonally down towards the bottom item of the submenu.
What happens:
* The second folder (and other items in the menu) highlight when moused over,
even though the second folder submenu does not open when highlighted, and even
though the other moused-over items are not at all related to the open submenu.
What should happen:
* Nothing, until (a) 1000 ms passes, or (c) you go outside the trapezoid (e.g.
you get to the submenu) -- whichever happens first.
Steps to reproduce #2:
* With the same set of bookmarks, hover over the left end of the first folder
item to open its submenu.
* Move the mouse vertically down to the second folder item.
What happens:
* You have to wait some delay period for the second submenu to open. This makes
it unnecessarily difficult to browse through a large set of submenus (e.g. the
Start menu hierarchy in Windows).
What should happen:
* The second submenu should open immediately.
Comment 8•24 years ago
|
||
Seem's you're missing Mathew's point. A time delay is not the optimal solution.
See Tog's answer to question 6:
http://www.asktog.com/columns/022DesignedToGiveFitts.html
Comment 9•24 years ago
|
||
Matthew, sorry. I misunderstood the problem from your original description.
Your second explanation clarified it for me. However, (since I don't have a Mac
to try this with) when I try it with the Windows Mozilla, I find that there is
another way to do this. That is, set the auto submenu open delay to something
quite long, and click on each folder item to make it open. On Mozilla, a folder
item seems to open immediately when you click (something that NS 4.x seems to do
wrong). It seems to me like this would get around the problem to some extent,
but then again, the current scheme has never bothered me. I suspect that this
is really a personal preference thing, where different folks will prefer
different approaches.
Comment 10•22 years ago
|
||
2 years later...
Actual sytem menu bar items behave properly, but Moz-specific submenus, such as
folders in a Personal Toolbar folder, act more like Windows submenus.
Blocks: 32494
OS: Mac System 9.x → MacOS X
Summary: Nested menu selection is too difficult → submenus should act like real Mac submenus (selection is too difficult)
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Comment 11•12 years ago
|
||
Is this still actual?
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA/WONT?]
Comment 12•12 years ago
|
||
Resolved per whiteboard
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA/WONT?] → [2012 Fall Equinox]
You need to log in
before you can comment on or make changes to this bug.
Description
•