conrod

conrod copied to clipboard

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.

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);

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

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).

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

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).

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

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.

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?

It'll stay inside the window.

@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.