Improve usability of the menu widgets

[jri]

3 flaws with menus should be removed:

• Some menus in the main toolbar reveal their items only when scrolled, despite there is enough space on the screen. This applies at least to the "Workspace", "Topicmap", and "Search mode" menus.

• Most menus longer than the screen height do scroll, which is fine. But the mouse's scroll wheel (or whatever scroll gesture you use) is not usable.

• The context menus appearing in the topicmap panel do *not* scroll. If invoked near the screen bottom some menu items might not reachable.

2 further improvements would be nice to have:

• Control menus via keyboard, e.g. arrow keys.

• Select menu items by typing the beginning letter.

For the technical side see also #532

[Jörg Richter]

Webclient: refactor menus, pt.2 (#532, #534).

Long menus do scroll.
The scroll wheel can be used.

The main toolbar's menus reveal all their items without scrolling.

See #532.
See #534.

• Changeset: 6d78c022c393fa766d192c5a1932c025d9aae443
• URL: ​https://github.com/jri/deepamehta/commit/6d78c022c393fa766d192c5a1932c025d9aae443

[Jörg Richter]

Webclient: refactor menus, pt.4 (#532, #534).

The canvas context menus do scroll when invoked near screen bottom.

DEVELOPER NOTES

DM's GUITookit now supports context menus.

dm4c.ui.context_menu()

All DM menus are now unified and based on GUITookit.
The proprietory canvas context menu code is dropped along with all menu related CSS.
The GUIToolkit menus and context menus rely on the jQuery UI Menu widget.

Menu refactoring is basically done.
Minor issues remain.

BREAKING CHANGE

All menu selection handlers are unified and receive 3 arguments:

menu_item - the selected menu item
x, y - coordinates of the selecting mouse click

This applies to toolbar menus as well as context menus.
If your plugin provides topic/association/canvas commands resp. places commands in the toolbar menus it must be possibly adapted. Check your command handler arguments.

See #532.
See #534.

• Changeset: b926b2a689ff709e9a71575d7d5ad0d59b5b709d
• URL: ​https://github.com/jri/deepamehta/commit/b926b2a689ff709e9a71575d7d5ad0d59b5b709d

[Jörg Richter]

Webclient: fix long menus (#532, #534).

In long menus, when a (vertical) scrollbar appears:

• the menu items are not line wrapped (the menu is wide enough).
• no horizontal scrollbar appears.

=> If one or both is not true for your OS or windowing system please send me an unscaled screenshot of the menu.

Note: you can use the mouse wheel or whatever scrolling gesture to scroll through long menus.
The former upper/lower "scrolling areas" are gone.

See #532.
See #534.

• Changeset: 19492501480a475350b1b4da4fb8f8063b4aaf83
• URL: ​https://github.com/jri/deepamehta/commit/19492501480a475350b1b4da4fb8f8063b4aaf83

[Jörg Richter]

Webclient: refactor menus, pt.2 (#532, #534).

Long menus do scroll.
The scroll wheel can be used.

The main toolbar's menus reveal all their items without scrolling.

See #532.
See #534.

• Changeset: 6d78c022c393fa766d192c5a1932c025d9aae443
• URL: ​https://github.com/jri/deepamehta/commit/6d78c022c393fa766d192c5a1932c025d9aae443

[Jörg Richter]

Webclient: refactor menus, pt.4 (#532, #534).

The canvas context menus do scroll when invoked near screen bottom.

DEVELOPER NOTES

DM's GUITookit now supports context menus.

dm4c.ui.context_menu()

All DM menus are now unified and based on GUITookit.
The proprietory canvas context menu code is dropped along with all menu related CSS.
The GUIToolkit menus and context menus rely on the jQuery UI Menu widget.

Menu refactoring is basically done.
Minor issues remain.

BREAKING CHANGE

All menu selection handlers are unified and receive 3 arguments:

menu_item - the selected menu item
x, y - coordinates of the selecting mouse click

This applies to toolbar menus as well as context menus.
If your plugin provides topic/association/canvas commands resp. places commands in the toolbar menus it must be possibly adapted. Check your command handler arguments.

See #532.
See #534.

• Changeset: b926b2a689ff709e9a71575d7d5ad0d59b5b709d
• URL: ​https://github.com/jri/deepamehta/commit/b926b2a689ff709e9a71575d7d5ad0d59b5b709d

[Jörg Richter]

Webclient: fix long menus (#532, #534).

In long menus, when a (vertical) scrollbar appears:

• the menu items are not line wrapped (the menu is wide enough).
• no horizontal scrollbar appears.

=> If one or both is not true for your OS or windowing system please send me an unscaled screenshot of the menu.

Note: you can use the mouse wheel or whatever scrolling gesture to scroll through long menus.
The former upper/lower "scrolling areas" are gone.

See #532.
See #534.

• Changeset: 19492501480a475350b1b4da4fb8f8063b4aaf83
• URL: ​https://github.com/jri/deepamehta/commit/19492501480a475350b1b4da4fb8f8063b4aaf83

[Jörg Richter]

Webclient: refactor menus, pt.2 (#532, #534).

Long menus do scroll.
The scroll wheel can be used.

The main toolbar's menus reveal all their items without scrolling.

See #532.
See #534.

• Changeset: 6d78c022c393fa766d192c5a1932c025d9aae443
• URL: ​https://github.com/jri/deepamehta/commit/6d78c022c393fa766d192c5a1932c025d9aae443

[Jörg Richter]

Webclient: refactor menus, pt.4 (#532, #534).

The canvas context menus do scroll when invoked near screen bottom.

DEVELOPER NOTES

DM's GUITookit now supports context menus.

dm4c.ui.context_menu()

All DM menus are now unified and based on GUITookit.
The proprietory canvas context menu code is dropped along with all menu related CSS.
The GUIToolkit menus and context menus rely on the jQuery UI Menu widget.

Menu refactoring is basically done.
Minor issues remain.

BREAKING CHANGE

All menu selection handlers are unified and receive 3 arguments:

menu_item - the selected menu item
x, y - coordinates of the selecting mouse click

This applies to toolbar menus as well as context menus.
If your plugin provides topic/association/canvas commands resp. places commands in the toolbar menus it must be possibly adapted. Check your command handler arguments.

See #532.
See #534.

• Changeset: b926b2a689ff709e9a71575d7d5ad0d59b5b709d
• URL: ​https://github.com/jri/deepamehta/commit/b926b2a689ff709e9a71575d7d5ad0d59b5b709d

[Jörg Richter]

Webclient: fix long menus (#532, #534).

In long menus, when a (vertical) scrollbar appears:

• the menu items are not line wrapped (the menu is wide enough).
• no horizontal scrollbar appears.

=> If one or both is not true for your OS or windowing system please send me an unscaled screenshot of the menu.

Note: you can use the mouse wheel or whatever scrolling gesture to scroll through long menus.
The former upper/lower "scrolling areas" are gone.

See #532.
See #534.

• Changeset: 19492501480a475350b1b4da4fb8f8063b4aaf83
• URL: ​https://github.com/jri/deepamehta/commit/19492501480a475350b1b4da4fb8f8063b4aaf83

[Jörg Richter]

Webclient: fix menu closing (#532, #534).

It does not happen that 2 menus are open at the same time.

See #532.
See #534.

• Changeset: 198284c3a823c0cc8c46bde2a6d3c8ba407247e8
• URL: ​https://github.com/jri/deepamehta/commit/198284c3a823c0cc8c46bde2a6d3c8ba407247e8

[Jörg Richter]

Webclient: 1-click menus (#534).

The menu gesture has fundamentally changed: now we have 1-click menus.

Before:

Click ---------> Choose ---------> Click

That is 2 mousedowns and 2 mouseups = 2 clicks

Now:

Mousedown ---------> Choose ---------> Mouseup

That is 1 mousedown and 1 mouseup = 1 click

So the effort of the most frequent usage gesture, a menu selection, has reduced by half.

(That's the very gesture I'm familar with by using a Mac.
BTW: how it works on Gnome, KDE, Unity, ...?)

-> What do you think? Do we want keep it this way?

I'm quite happy until it comes to scrolling long menus.

DEVELOPER NOTES

GUIToolkit:
dm4c.ui.button(config) accepts another config option:

on_mousedown -- the handler fired on button mousedown (a function).

See #534.

• Changeset: be870c13fde35c964da7ecc0baef25e5c303848a
• URL: ​https://github.com/jri/deepamehta/commit/be870c13fde35c964da7ecc0baef25e5c303848a

[Malte]

-> What do you think? Do we want keep it this way?

Aha. Well, one surely would need some time to get used to, keeping the mouse button pressed feels somehow frantic for me now, just when using touchpads (on laptops) this behaviour feels OK to use. And no, from pointer based interfaces I haven't experienced such menu behaviour ever before (Gnome, KDE, Windows).

What do others say?

[Jörg Richter]

Webclient: combine 1- and 2-click gesture (#534).

Both, the "traditional" 2-click gesture and the new 1-click gesture can be used together.

Each time you use a menu you can do both:

• work just like before, that is click to open a menu, and do another click to select an item.
• or save 1 click by holding the mouse button down, move to the item, and release the button.

This works for both, context menus and stationary menus.

The 2-click gesture is still useful in case of long menus, which are scrollable.

I think, we have the best of "2 worlds" now.

DEVELOPER NOTES

GUIToolkit:
dm4c.ui.button(config) accepts another config option:

on_mouseup -- the handler fired on button mouseup (a function).

See #534.

• Changeset: 6b837cd5fb2757d6ffe97f6a9a8f0dc0fd500f5e
• URL: ​https://github.com/jri/deepamehta/commit/6b837cd5fb2757d6ffe97f6a9a8f0dc0fd500f5e

[JuergeN]

Very cool! :)

[Jörg Richter]

Webclient: keyboard control for menus (#534).

All menus can be controlled via keyboard.
Taken from jQuery UI website:

• ENTER/SPACE: Invoke the focused menu item's action.
• UP: Move focus to the previous menu item.
• DOWN: Move focus to the next menu item.

Typing a letter moves focus to the first item whose title starts with that character. Repeating the same character cycles through matching items. Typing more characters within the one second timer matches those characters.

Disabled items can receive keyboard focus, but do not allow any other interaction.

See #534.

• Changeset: 0b1f6ae8540b38ac37329256b12e66732715b238
• URL: ​https://github.com/jri/deepamehta/commit/0b1f6ae8540b38ac37329256b12e66732715b238

[Jörg Richter]

Webclient: fix menu closing (#532, #534).

It does not happen that 2 menus are open at the same time.

See #532.
See #534.

• Changeset: 198284c3a823c0cc8c46bde2a6d3c8ba407247e8
• URL: ​https://github.com/jri/deepamehta/commit/198284c3a823c0cc8c46bde2a6d3c8ba407247e8

[Jörg Richter]

Webclient: 1-click menus (#534).

The menu gesture has fundamentally changed: now we have 1-click menus.

Before:

Click ---------> Choose ---------> Click

That is 2 mousedowns and 2 mouseups = 2 clicks

Now:

Mousedown ---------> Choose ---------> Mouseup

That is 1 mousedown and 1 mouseup = 1 click

So the effort of the most frequent usage gesture, a menu selection, has reduced by half.

(That's the very gesture I'm familar with by using a Mac.
BTW: how it works on Gnome, KDE, Unity, ...?)

-> What do you think? Do we want keep it this way?

I'm quite happy until it comes to scrolling long menus.

DEVELOPER NOTES

GUIToolkit:
dm4c.ui.button(config) accepts another config option:

on_mousedown -- the handler fired on button mousedown (a function).

See #534.

• Changeset: be870c13fde35c964da7ecc0baef25e5c303848a
• URL: ​https://github.com/jri/deepamehta/commit/be870c13fde35c964da7ecc0baef25e5c303848a

[Jörg Richter]

Webclient: combine 1- and 2-click gesture (#534).

Both, the "traditional" 2-click gesture and the new 1-click gesture can be used together.

Each time you use a menu you can do both:

• work just like before, that is click to open a menu, and do another click to select an item.
• or save 1 click by holding the mouse button down, move to the item, and release the button.

This works for both, context menus and stationary menus.

The 2-click gesture is still useful in case of long menus, which are scrollable.

I think, we have the best of "2 worlds" now.

DEVELOPER NOTES

GUIToolkit:
dm4c.ui.button(config) accepts another config option:

on_mouseup -- the handler fired on button mouseup (a function).

See #534.

• Changeset: 6b837cd5fb2757d6ffe97f6a9a8f0dc0fd500f5e
• URL: ​https://github.com/jri/deepamehta/commit/6b837cd5fb2757d6ffe97f6a9a8f0dc0fd500f5e

[Jörg Richter]

Webclient: keyboard control for menus (#534).

All menus can be controlled via keyboard.
Taken from jQuery UI website:

• ENTER/SPACE: Invoke the focused menu item's action.
• UP: Move focus to the previous menu item.
• DOWN: Move focus to the next menu item.

Typing a letter moves focus to the first item whose title starts with that character. Repeating the same character cycles through matching items. Typing more characters within the one second timer matches those characters.

Disabled items can receive keyboard focus, but do not allow any other interaction.

See #534.

• Changeset: 0b1f6ae8540b38ac37329256b12e66732715b238
• URL: ​https://github.com/jri/deepamehta/commit/0b1f6ae8540b38ac37329256b12e66732715b238

[Malte]

Replying to Jörg Richter:

Webclient: combine 1- and 2-click gesture (#534).

Both, the "traditional" 2-click gesture and the new 1-click gesture can be used together.

Each time you use a menu you can do both:

• work just like before, that is click to open a menu, and do another click to select an item.
• or save 1 click by holding the mouse button down, move to the item, and release the button.

This works for both, context menus and stationary menus.

The 2-click gesture is still useful in case of long menus, which are scrollable.

When I click directly onto one of the elements making up a scrollbar (to "manually" scroll down the menu and not using a scrolling gesture) the menu disappears (in both FFOX and Chromium). Tested with the "By Type" Menu.

[Malte]

Replying to Jörg Richter:

Webclient: keyboard control for menus (#534).

All menus can be controlled via keyboard.
--
Typing a letter moves focus to the first item whose title starts with that character. Repeating the same character cycles through matching items. Typing more characters within the one second timer matches those characters.

Yeah, super-nice! Great work.

[Malte]

Replying to Malte:

Replying to Jörg Richter:

Webclient: keyboard control for menus (#534).

All menus can be controlled via keyboard.
--
Typing a letter moves focus to the first item whose title starts with that character. Repeating the same character cycles through matching items. Typing more characters within the one second timer matches those characters.

Yeah, super-nice! Great work.

Oh, there seems to be an issue with default keyboard handling. When hitting ENTER or SPACE (while a menu has focus in the browser) the menu does not pop up. (FFOX and Chromium).

This can be reported for the "Toolbar" as well as menus part of the "Page Panel".

[jri]

Replying to Malte:

When I click directly onto one of the elements making up a scrollbar (to "manually" scroll down the menu and not using a scrolling gesture) the menu disappears (in both FFOX and Chromium). Tested with the "By Type" Menu.

Confirmed!
That's a bug.
Thank you very much for reporting!

[jri]

Replying to Malte:

Oh, there seems to be an issue with default keyboard handling. When hitting ENTER or SPACE (while a menu has focus in the browser) the menu does not pop up. (FFOX and Chromium).

This can be reported for the "Toolbar" as well as menus part of the "Page Panel".

What do you mean with "pop up".
I can see no problem with DM menu's enter key (Safari, FFOX, Chrome).

[Malte]

What do you mean with "pop up".

In my browsers no (closed) menu opens through pressing ENTER or SPACE (when being focused) on the keyboard.
The menu items don't show up, though the button (visually) gets fired when a key is pressed. No errors thrown/nothing visible in a browsers console.

[jri]

Thank you for clarification!
You mean no menu pops up when the menu button has focus and Enter/Space? is pressed (the menu is NOT open at that time, so I would not say it has focus. The menu button has).

OPENING menu via Enter/Space? is not supported yet. Enter/Space? is operational only in menus which are OPEN already.

Anyway, opening menus via Enter/Space? is a good idea!
I even thought about that for context menus already. That is, a topic on the canvas is selected, I hit Enter and its context menu appears.
I would try to realize both.

Thank you for valuable feedback!

[Jörg Richter]

Webclient: open menus with ENTER or SPACE (#534).

When a menu button has focus its menu can be opened by pressing ENTER or SPACE.
Thanks, Malte, for reporting.

One issue remain: because in a just opened menu no item is focused pressing ENTER/SPACE (which normally selects the focused item) in this situation throws a client-side error.

Extend docu for GUIToolkit Button.

See #534.

• Changeset: cac34371c32a90d9280102b232ca972f0e900288
• URL: ​https://github.com/jri/deepamehta/commit/cac34371c32a90d9280102b232ca972f0e900288

[Jörg Richter]

Webclient: open menus with ENTER or SPACE (#534).

When a menu button has focus its menu can be opened by pressing ENTER or SPACE.
Thanks, Malte, for reporting.

One issue remain: because in a just opened menu no item is focused pressing ENTER/SPACE (which normally selects the focused item) in this situation throws a client-side error.

Extend docu for GUIToolkit Button.

See #534.

• Changeset: cac34371c32a90d9280102b232ca972f0e900288
• URL: ​https://github.com/jri/deepamehta/commit/cac34371c32a90d9280102b232ca972f0e900288

[Jörg Richter]

Webclient: fix 2-click menu gesture (#534).

When selecting a menu item via 2-click gesture no "#" appears in the browser's address bar.

See #534.

• Changeset: f94a6fc35a3c7664b8ba7fb97da5a12c6fb293f6
• URL: ​https://github.com/jri/deepamehta/commit/f94a6fc35a3c7664b8ba7fb97da5a12c6fb293f6

[jri]

Replying to Malte:

When I click directly onto one of the elements making up a scrollbar (to "manually" scroll down the menu and not using a scrolling gesture) the menu disappears (in both FFOX and Chromium).

This needs still to be solved.

[Jörg Richter]

Webclient: fix menu scrollbar (#534).

The vertical scrollbar appearing for long menus is usable.
The menu does not disappear accidently when a scrollbar element is clicked.

Thanks, Malte, for reporting.

See #534.

• Changeset: 080c26541dc1da23be08c6597bc2c0b1d80f20c9
• URL: ​https://github.com/jri/deepamehta/commit/080c26541dc1da23be08c6597bc2c0b1d80f20c9