Context menu

[mankinskin]

(updated 8.9.21)

• ContextMenuSystem: Stored by the Context, stores menu state across frames

• context_menu can be called on Response. It checks if a context menu should be shown and takes a builder closure for the context menu's contents:

ui.horizontal(|ui| {
    ui.label("title:");
    ui.text_edit_singleline(title);
})
.response
.context_menu(|ui| {
    if ui.button("Clear..").clicked() {
        *title = String::new();
        ui.close();
    }
});

• the Ui is extended to support creating and closing of menus via the menu and close methods. When menu is called from within a Ui for a menu, it creates a button with an expandable sub-menu, otherwise it creates an inline drop-down menu. Calling close clears the internal menu state.

.response
.context_menu(|ui| {
    if ui.button("Open...").clicked() {
        ui.close();
    }
    ui.menu("SubMenu", |ui| {
        ui.menu("SubMenu", |ui| {
            if ui.button("Open...").clicked() {
                ui.close();
            }
            let _ = ui.button("Item");
        });
        if ui.button("Item").clicked() {
            ui.close();
        }
    });
});

To-Do:

• respect click context (i.e. clicked element)
• add more extensive examples to demo
• improve submenu navigation with more forgiving mouse movement paths
• unify with egui::menu
• fix hover failing at edge between context menus Only add resize radius for interactable areas #577
• disable hover effect on other menu items when moving towards open submenu
• define useful Response for SubMenu::show: InnerResponse<Option<Response>>
• improve styling
• Better distinction of dragged vs clicked #547 or Don't drag with secondary pointer button by default #578
• optimize menu item and submenu API (MenuUi)
• sometimes context menus applied to panels trigger when clicking on a window covering the panel

Needs new PR:

• is the shadow of the sub-menu on the parent menu fine?
• widgets still show hover visuals when cursor moves over them while submenu is open Disable parent menu UI when submenu is open #684
• items don't adjust to width of larger items when they are added after them Calculating a UI's size without rendering it #606
• Wrap large menus into columns or make them scrollable #683

Let me know if you have any suggestions or find any problems :)

[emilk]

Interesting! Have you considered how this relates to egui::menu? It would be great if all menus could be unified, as there are a lot of similar things to solve (submenus, when to close the main menu, etc).

[mankinskin]

Have you considered how this relates to egui::menu?

Yes, I drew inspiration from it, as this was pretty much my first experience with egui, and now they both render the contents inside a Frame inside an Area, so this part could probably be unified. I would like to keep things separate for now though, until the functionality is complete and we can work on the styling.

I am now trying to make ctx.context_menu(add_contents) and ui.context_menu(add_contents) work and respect the clicked area to show context related context menus.

[mankinskin]

I am pretty happy so far, but it doesn't work perfectly yet. It is now possible to define a context menu for an individual Ui using

ui.context_menu(|ui, menu_state| {
    if ui.button("Add...").clicked() {
        self.add();
        menu_state.close();
    }
});

for example. The ContextMenuSystem is now stored by the egui::Context and uses Ui Id's to manage which context menu to show. Basically a context menu will only be shown when a proper click happens in its max_rect_finite(). I am not sure if this is the best Rect to use, but it was the one that worked best so far. I added some examples to the demo:

• top bar
• backend panel
• widget gallery plot
• drag and drop left column

Unfortunately I was not able to attach context menus to the items in the drag and drop example properly. When right clicking them I only ever get the context menu for the top left item of all columns, and it mostly closes immediately and only stays open a few of the times I click. I suspect it is something with the bounding boxes of the items, where I am probably not using an accurate one to detect clicks on the respective Ui.

@emilk do you maybe have a suggestion which Rect I should use to detect clicks on the content of a Ui? I am currently using ui.rect_contains_pointer(ui.max_rect_finite()).

[mankinskin]

Problem solved, the context menu is now applied to Responses, which hold the accurate rect of the relevant Ui and their Id. Next step is to improve submenu navigation.

[parasyte]

Some nitpicks from a UX point of view:

The menu_state callbacks look unusual and creates flow control that is difficult to reason about. I'm thinking it would make more sense to have the add_content() closure return an enum that will be actionable by the caller:

ui.add(example_plot(plot))
    .context_menu(|ui| {
        if ui.button("Sin").clicked() {
            *plot = Plot::Sin;
            MenuState::Close
        } else if ui.button("Bell").clicked() {
            *plot = Plot::Bell;
            MenuState::Close
        } else if ui.button("Sigmoid").clicked() {
            *plot = Plot::Sigmoid;
            MenuState::Close
        } else {
            MenuState::Continue
        }
    });

It could also be an Option<MenuState>, so the conditions can return Some(MenuState::Close) or None when there is no action to perform. This is a matter of personal preference.

Going over the code, there is also a public callback named get_submenu which returns a value. I'm not entirely sure what this is for. Shouldn't sub-menus share all (most?) of the same code as the main context menu? There is probably a good reason for this separation, I'm just unfamiliar with the evolution and design of this PR.

[mankinskin]

Ah, MenuState::get_submenu shouldn't be public, thanks for pointing out. the root menu and sub menus are basically the same, only that the root also has to store the Id of the element it was attached to. This is to discriminate two different context menus.

return an enum

I thought about this too but I kind of liked the state argument better because it felt more flexible. I am not sure how this feature is going to evolve and if there will be other functions you might want to call from the context menu ui. If you wanted to make multiple calls this would probably be more ergonomic.

But I don't see any reason not to return enums by default and have something like context_menu_with_state in addition to that if you ever need to manipulate menu state more extensively.

[mankinskin]

The submenu navigation works a lot better now, the code checks if the pointer is travelling towards an open submenu and allows it to cross over other items if it is. It also requests a repaint if it is travelling towards a submenu, so that when the pointer stops moving, this can be detected even in reactive mode.

There is one problem with draggable elements though, like in the drag-and-drop example. Because drag is also enabled by right clicking, the draggable elements sense a drag instead of a click when right clicking them. I think it is rather untypical to drag using the right mouse button, and I think it would be reasonable to disable dragging with secondary pointer button by default, in favor of detecting secondary button clicks.

#547 would also solve this

[mankinskin]

@parasyte I also just noticed that the menu_state is needed to create SubMenus, as they use the parent state to know if they are open or not.

[parasyte]

Isn't that a concern that is internal to the implementation? I'm not sure the caller should be aware of or have access to that information.

[mankinskin]

The MenuState only allows creating submenus and closing the menu hierarchy. Everything else is private. I don't see another way letting users create submenus in a closure than passing them a handle to the state they need to interact with. Anything else would require probably a much tighter API that would have to mimic Ui to manipulate MenuState behind the scenes..
The MenuState is completely opaque and only exposes close() and submenu(). I don't see a problem with this.

[mankinskin]

Making some progress on the styling, but there seems to be an issue with overlap and hovering of the submenu button. My guess is that the submenu's frame margin or shadow covers a part of the button in the parent menu, and that causes the submenu to close and reopen repeatedly.

I would be very glad if someone could take a look at the styling code and share some thoughts about it. I feel like I am making this harder than it should be.

[mankinskin]

I think I will also look into implementing submenus in the existing menus this way. It will pretty much work the same way.

[emilk]

This is very impressive work, but I have a concern about having to write menu_state.item("Click me").show(ui).clicked(). I would prefer if one could simply write ui.button("Click me").clicked(), and add any widget at all with just ui.add(…) as anywhere else in egui. I understand we need something special for submenus, but I think we should be able to get other widgets to work.

The context menus should support all the widgets egui does, and should do so using the same interface.

[mankinskin]

@emilk Thanks for reviewing this! I agree about the API, that should all be hidden in Ui. We do need some way to create a submenu and close the menu though, and they need access to some state for the context menu. If this state was managed internally, we would have this interface return Options or Results when the Ui is not of a submenu, i.e. there is no internal menu state. I think this would be kind of unsound and a potential risk, because people would have to call .unwrap() on something like ui.submenu(..) when there is really no reason there wouldn't be a menu state when they are inside a context_menu builder. So I am thinking about an API like this

.response
.context_menu(ui, |ui, menu_state| {
    if ui.menu_item("Text", &menu_state).clicked() {
        menu_state.close() 
    }
    ui.sub_menu("Text", &mut menu_state, |ui, menu_state| {
        if ui.menu_item("Nested item", &menu_state).clicked() {
            menu_state.close()
        }
    })
})

The benefit here is that there is always a menu_state when there should be and no unwrap calls are needed. also the menu_item and sub_menu builders would fit with the other widget builders in Ui. The menu_item builder would be needed to have specialized visuals for menu items, instead of using the regular button widget, which for example doesn't respect if a submenu is open and the cursor is moving towards it, i.e. there shouldn't be any visuals on other items even when they are hovered shortly. Maybe the API would even benefit from some getters for these conditions so people can integrate their own widgets more easily.

I will try to integrate your suggestions soon, so we can move on with this :)

Edit: Another option would be to have separate type for a MenuUi which would be a superset of the Ui API and always has a menu state to use. That would hide the menu_state management and avoid unwrap.

[coderedart]

don't know if this is the right place for it to mention. i am waiting on egui menus/submenus for my app. as my app is a rewrite/port of another app that had custom ui framework, i read upon a couple issues they had with menus. thought i should mention them here for consideration.

1. What happens if menu is too big, like bigger than the height of window/monitor, are the menus beyond the border inaccessible? or will the menu have scrolling? or will there be a new column to show the rest of the items.
2. is it possible to have checkboxes in menu items, and will the menu disappear when clicked on the checkbox to toggle it, so if the user wants to toggle multiple checkboxes, does he/she need to open menu, toggle item, and repeat ? the use case for it is when there's options that are toggleable and when enabled those options themselves have suboptions.
   the following screenshot should explain what i'm trying to say.
   
   

[mankinskin]

@coderedart Thanks for your input. There is no special handling for large menus yet, so the items would just go off-screen. I will try to get scrollable and multi-column menus working.

About your second question: checkboxes will be easily possible, just like all other kinds of widgets. The menu will just be another Ui. Also the menu will be closed explicitly, so you can interact with widgets without closing the menu.

[emilk]

cargo clippy and cargo fmt are still unhappy!

[mankinskin]

I will add the changelog note tomorrow 👍

[mankinskin]

So happy to contribute to this awesome project! Thanks for all the support :) was great fun

[mankinskin]

but what about the changelog now @emilk ? I didn't add that yet. But it is probably just one line anyways..

[emilk]

I just pushed a line to the changelog in 41f77ba!

[emilk]

I have just created an egui discord server: https://discord.gg/qzvmcrUe - come join if you like!