Bug 97243 - Hierarchical menus are fickle and their usability is low
Summary: Hierarchical menus are fickle and their usability is low
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-18 23:55 UTC by David Tonhofer
Modified: 2020-10-01 11:11 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
LibreOffice mouse path: Follow the green line (56.83 KB, image/png)
2016-01-18 23:55 UTC, David Tonhofer
Details
A "long way to the final menu" (65.69 KB, image/png)
2016-01-18 23:56 UTC, David Tonhofer
Details
Scaling Sartre in Gimp: Both mouse paths work (156.95 KB, image/png)
2016-01-18 23:57 UTC, David Tonhofer
Details
Scaling Sartre in Gimp: The rad mouse path switches the option (156.09 KB, image/png)
2016-01-18 23:58 UTC, David Tonhofer
Details
video (619.06 KB, video/mp4)
2020-09-26 05:16 UTC, BogdanB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Tonhofer 2016-01-18 23:55:10 UTC
After having missed the "perfect horizontal mouse movement" in hierarchical dropdown menus in LibreOffice Writer (Version: 4.4.7.2
Build ID: 4.4.7.2-1.fc22) a few times, and after having noticed that the menu behaviour of Gimp is different and very much more agreeable, I have been wondering about whether the Gimp behaviour could be ported. AFAIK LibreOffice comes with its own menu implementation (from VCL) and Gimp uses GTK+.

Let me illustrate:

Suppose you want to set the "Language" of "All Text" to "None" in LibreOffice. This means navigating *➤ Tools ▼ Language ▶ For All Text ▶ None (Do not check spelling)*. 

It turns out that this is a significant path to trace with the mouse

(See image "Significant Path: Language For All Text None.png")

The menu system of LibreOffice is fickle in that, if you stray from the horizontal line leading into the hierarchically lower menu, the hierarchically lower menu will CLOSE AT ONCE as the next option on the current menu is selected. In the illustration below, you cannot move the mouse along the red path because that means selecting "Word Count". Descending hierarchical menus becomes frustrating as you have to stay very precise (which may be difficult if you are in an uncomfortable position with your hand or are afflicted by neurological disorders).

(See image "Significant Path: Keep the Mouse on the Green Line.png")

On the exact same system, the menu system of Gimp performs very well. Indeed, it seems to have a "target predictor" built in: If you target an element of a hierarchically lower menu, the currently selected option REMAINS SELECTED and the hierarchically lower menu REMAINS OPEN for maximally two seconds as you move the mouse. Both blue and green paths become feasible:

(See image: "Scaling Sartre: Both Paths work.png")

On the other hand, if you target the next item in the current menu, the predictor seems to guess that you want to move to the next option. Thus in the following case, the red path means opening "Colour Tools":

(See image: "Scaling Sartre: Red Path.png")
Comment 1 David Tonhofer 2016-01-18 23:55:54 UTC
Created attachment 122066 [details]
LibreOffice mouse path: Follow the green line
Comment 2 David Tonhofer 2016-01-18 23:56:44 UTC
Created attachment 122067 [details]
A "long way to the final menu"
Comment 3 David Tonhofer 2016-01-18 23:57:53 UTC
Created attachment 122068 [details]
Scaling Sartre in Gimp: Both mouse paths work
Comment 4 David Tonhofer 2016-01-18 23:58:26 UTC
Created attachment 122069 [details]
Scaling Sartre in Gimp: The rad mouse path switches the option
Comment 5 Jean-Baptiste Faure 2016-01-19 21:46:20 UTC
I agree that I often have to try several times before I succeed to reach the submenu I want.
I guess it is a big deal to change this behavior. Nevertheless it is a valid enhancement.

Best regards. JBF
Comment 6 BogdanB 2020-09-26 05:16:43 UTC
Created attachment 165860 [details]
video

I see improvments here: see my video.

If you consider is everything ok, let's close this bug.

Version: 7.0.1.2
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 7 David Tonhofer 2020-10-01 11:00:51 UTC
Thank you! Yes, this looks pretty good.
I'm still on 6.2.8, instead of 7 but it even works there. I didn't even notice.

Bug can be closed!