GUIToolkit: hierarchical menus

[Jörg Richter <jri@…>]

In f3c54dce9591a66190e042f083c9de9d03e4d0ef/deepamehta:

Webclient GUIToolkit: Submenus. No success (#758).

The GUIToolkit's menus and the underlying Webclient commands model has been extended in order to support submenus resp. subcommands. But without success.

The problem is in jQuery UI in conjunction with the Webclient's "desktop style" UI, in particular the behavior when menus exceed the browser window bottom. As you know the Webclient's overall objective is to avoid the browser window from scrolling. Instead the Webclient trims the menu and scrolls just the menu. Realizing this behavior for the submenus as well is much too hard. Such a behavior should be offered by jQuery UI out-of-the-box. At the moment I see no reasonable solution based on jQuery UI.

The current state is available in the "submenus" branch (which will probably not be continued/merged). The Workspaces plugin adds a "Assign to" command to the topic context menu with a submenu listing the workspaces.

See #758.

[JuergeN]

So the re-assignment of a workspace will not work through the context menu of a topic, right? Then another suggestion would be to re-assign the workspace in the details panel. In edit mode I could choose the new workspace simply by a dropdown list of available workspaces, just like with association definitions (e.g address, street).

[jri]

Yes, introducing submenus to the Webclient is too difficult at the moment. The Webclient menus rely on jQuery UI. The jQuery UI menus support submenus. However the Webclient must already tweak jQuery UI in order to keep the menus always inside the browser window (by adding scrolling to menus). Extending this tweak to the submenus as well is not feasible with reasonable effort. (This should rather be done by the jQuery UI team.)

Meanwhile I realized the "Assign to Workspace" operation via context menu and a dedicated dialog box. (This is not yet checked in.) But I agree: having the assign operation in the detail panel would be much nicer, as 1) it does not further clutter the context menu (now we have 8 commands there, that is one too much :-), and 2) it lets the user edit the workspace assignment where it is actually displayed which is more intuitive.

[Jörg Richter <jri@…>]

In 207bdf6a2facef66008968bb67ab23c1564423de/deepamehta:

Webclient: support for submenus (#758).

Commands provided by a plugin's topic_commands, association_commands, or canvas_commands listener can have a new sub_commands property. Its value is an array of commands, e.g.:

dm4c.add_listener("topic_commands", function(topic) {
    return [
        {
            label: "Assign to Workspace",
            sub_commands: [
                {
                    label: ...
                    icon: ...
                    handler: ...
                    disabled: ...
                },
                ...
            ],
            context: "context-menu"
        }
    ]
})

Note: submenus are experimental.

At the moment there are crucial layout flaws.

Sub-commands can only be provided for the command context context-menu (not for detail-panel-xxx).

At the moment the Webclient's GUIToolkit supports submenus only for context-menus, not for pulldown-menus.

CHANGES

GUIToolkit API:

1 new method in ContextMenu class:

add_submenu(label, items)

See #758.

[Jörg Richter <jri@…>]

In 354d5cce5a12a1522392cddc04b883c7b6ad8fae/deepamehta:

Adapt Webclient to jQuery UI 1.11.4 (#507, #758).

With jQuery UI 1.11.4 we didn't manage to get scrollable menus with submenus layouted properly.
The submenu appears inside the main menu's container and a vertical scrollbar appears. The submenu is only visible after scrolling to the right.
Fiddling with overflow-x and overflow-y doesn't help. The intended x=visible/y=auto combination is not supported by browsers. See W3C spec below.

With older jQuery UI 1.10.4 we got it working!
The solution is to set the menu's CSS "position" to "static" (and possibly position the menu by the jQuery UI "position" option then). All other position values ("absolute", "relative", "fixed") are not working. CSS "overflow" can just be "auto" then.
With jQuery UI 1.11.4 the "position=static" solution do not work.
So, scrollable menus with submenus are possible with jQuery UI 1.10.4 but not with newer jQuery UI 1.11.4.
All this is true pain!!

W3C spec says:

The computed values of "overflow-x" and "overflow-y" are the same as their specified values, except that some combinations with "visible" are not possible: if one is specified as "visible" and the other is "scroll" or "auto", then "visible" is set to "auto". The computed value of "overflow" is equal to the computed value of "overflow-x" if "overflow-y" is the same; otherwise it is the pair of computed values of "overflow-x" and "overflow-y".

​http://www.w3.org/TR/css3-box/#overflow-x

See #507.
See #758.

[Jörg Richter <jri@…>]

In b6913cda12d3faf8d15e47bca5c14003dffee1da/deepamehta:

GUIToolkit: submenus are regular items (#758).

CHANGES

GUIToolkit API:

1 method dropped from ContextMenu class:

add_submenu(label, items)

To add a submenu use the regular add_item(item) method and pass an item which has a submenu_items property: an array of items.

This way the submenu parent item is a regular item, and thus can have an icon, can be disabled, and can have its own handler.

Submenu layout is still an issue.

See #758.

[Jörg Richter <jri@…>]

In 0cb817ada96d72f4bac4d95d0087045792848399/deepamehta:

GUIToolkit: submenu layout (#758).

Submenu layout is acceptable for the first time!

See #758.