Context Menu (aka ClickDownMenu) Draft

[libfud]

There should be something like a Contextual trait, where right clicking on a widget which implements it reveals a context menu. I think this shares some overlap with a drop down menu.

[mitchmindtree]

I think this might even be best as its own Widget. A user could provide either a specific clickable area, or the ID of a widget that can be clicked to activate it. Usage could be something like:

RightClickMenu::new(some_menu)
    .click_area(position, dimensions) // A user could either use this
    .click_widget(SOME_WIDGET_ID) // or this.
    .react(...)
    .set(MY_CLICK_MENU, ui);

[mitchmindtree]

It would be cool if a user could specify which mouse button activates the menu. Perhaps ClickDownMenu is a better name.

[mitchmindtree]

There should be a single Menu type/trait which can be shared between this and the Menu/ToolBar #417 and perhaps even the DropDownList (could be changed to DropDownMenu).

[flying-sheep]

in existing UI frameworks, both are rendered by creating a floating titlebarless window which is able to extend outside of the main window.

[agraven]

GTK3 applications using client side decoration actually draw the vast majority of popup menus in the actual application window instead of in a floating one. Electron applications do this as well (but that's because they simply can't make floating windows, I think).

[flying-sheep]

Interesting! Do they detect if the menu would fit into the window boundaries and only create a floating window if it doesn’t?

[agraven]

Most applications like this change which side of the cursor the menu appears on, usually the menu is position so the cursor is at its top-left, but this is changed to bottom or right corner if necessary.

[flying-sheep]

Sure, but what if you have a very small parent window or a very long menu? Will it still render in the window (with scrollbars or so) or will it pop out as its own window?

[agraven]

It'll stay inside the window.

[mitchmindtree]

@flying-sheep yes unfortunately conrod will have the same restriction as GTK in this sense (at least for widgets that are generic across platforms). In our case, conrod_core does not have ownership over the windowing context or know anything about it - it just receives input events and outputs widget primitives for rendering and widget events for updating state.

That said, you might be able to implement a popup style menu for a specific windowing backend (e.g. winit) - it would require a custom widget implementation and might be better off as a downstream crate. It may even be possible to make a generic one that worked with windowing from different platforms, but this would likely involve much greater design considerations.