Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

lucasmerlin
Copy link
Collaborator

@lucasmerlin lucasmerlin commented Feb 13, 2025

Continuation of #5713

Silently breaking changes:

  • Menus now close on click by default, this is configurable via PopupCloseBehavior

Additional additions:

  • Button::right_text
  • StyleModifier

This is a rewrite of the egui menus, with the following goals:

  • submenu buttons should work everywhere, in a popup, context menu, area, in some random Ui
  • remove the menu state from Ui
  • should work just like the previous menu
  • proper support for keyboard navigation
    • It's better now but requires further work to be perfect
  • support PopupCloseBehavior

@github-actions
Copy link

Preview available at https://egui-pr-preview.github.io/pr/5716-lucaspopup-based-menu
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

@lucasmerlin lucasmerlin marked this pull request as draft February 13, 2025 20:46
@lucasmerlin lucasmerlin force-pushed the lucas/popup-based-menu branch from e6cf98d to 0109e35 Compare February 18, 2025 15:09
@lucasmerlin lucasmerlin force-pushed the lucas/popup-based-menu branch from 0109e35 to b9c1a1f Compare February 19, 2025 17:21
@lucasmerlin lucasmerlin added feature New feature or request egui labels Feb 20, 2025
@lucasmerlin lucasmerlin changed the title Improved menu based on egui::Popup ⚠️ Improved menu based on egui::Popup Feb 20, 2025
# Conflicts:
#	crates/egui/src/containers/popup.rs
#	crates/egui/src/containers/window.rs
#	crates/egui/src/response.rs
#	crates/egui/src/ui.rs
#	crates/egui/src/ui_builder.rs
#	crates/egui_demo_lib/src/demo/context_menu.rs
#	crates/egui_demo_lib/src/demo/demo_app_windows.rs
#	crates/egui_demo_lib/src/demo/popups.rs

let inner = Popup::menu(&button_response)
.id(popup_id)
.style(None)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we set the menu styles for the ComboBox? I'm overwriting this here since this is how it was before, but I think the menu styles would look nice here

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question 🤔 If so I think we save it for another PR

Comment on lines +243 to +246
ui.hyperlink_to(
egui::RichText::new("🦋").size(font_size),
"https://bsky.app/profile/ernerfeldt.bsky.social",
);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like there is no butterfly in egui :(

Screenshot 2025-02-20 at 19 04 02

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You just have to wait for🐛...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought this would be a fun way to display the options, but it seems like the readability suffers a bit. Should I change it?

@lucasmerlin lucasmerlin force-pushed the lucas/popup-based-menu branch from 8c9b953 to a312478 Compare February 28, 2025 10:07
@crumblingstatue
Copy link
Contributor

⚠️ Breaking: This technically breaks popup dialogs nested inside menus, for example a color edit button
image

Since they use the same popup mechanism, and there can only be one popup, they will close the menu (and likely themselves in the process).

I don't know if this should be counted as a regression, or never supported in the first place, but a decision should be made regarding this, before merging this PR.

@lucasmerlin
Copy link
Collaborator Author

@crumblingstatue good catch. I want to support opening multiple/nested popups which should fix this. But I'll implement that in a separate PR, since this one is already so big.

@lucasmerlin lucasmerlin merged commit cd22517 into master Mar 3, 2025
46 checks passed
@lucasmerlin lucasmerlin deleted the lucas/popup-based-menu branch March 3, 2025 13:56
lucasmerlin pushed a commit that referenced this pull request Mar 20, 2025
Breaking changes:
- When using the Memory::popup state, it's now required to call
keep_popup_open each frame or the popup will close.
- Usually handled by the `Popup` struct, but required for custom popups
using the state in `Memory` directly

-----

If a popup is abandoned `Memory::popup` would remain `Some`. This is
problematic if, for example, you have logic that checks
`is_any_popup_open`.

This PR adds a new requirement for popups keeping their open state in
`Memory::popup`. They must call `Memory::keep_popup_open` as long as
they are being rendered. The recent changes in #5716 make this easy to
implement.

Supersedes #4697 which had an awkward implementation

These two videos show a case where a context menu was open when the
underlying widget got removed.

Before (`any_popup_open` remains `true`)
![Screenshot 2025-03-16 at 18 22
50](https://github.com/user-attachments/assets/22db64dd-e6f2-4501-9bda-39f470b9210c)

After
![Screenshot 2025-03-16 at 18 21
14](https://github.com/user-attachments/assets/bd4631b1-a0ad-4047-a14d-cd4999710e07)



* Closes #3657
* [x] I have followed the instructions in the PR template
lucasmerlin added a commit to rerun-io/rerun that referenced this pull request May 8, 2025
### Related

### What

I was curious how my work on egui
[menus](emilk/egui#5716) and
[popups](emilk/egui#5713) would work in rerun,
so I gave it a try.

### Findings so far

- ~The new tooltip positioning works well unless we scroll in the scroll
area. Maybe we should intersect the widget rect with the clip rect.~
Fixed!


https://github.com/user-attachments/assets/54e7ffb1-f0a9-4f2d-8776-e0bea8777903
darkwater pushed a commit to darkwater/egui that referenced this pull request Aug 24, 2025
Continuation of emilk#5713

**Silently breaking changes:**
- Menus now close on click by default, this is configurable via
`PopupCloseBehavior`

**Additional additions:**
- `Button::right_text`
- `StyleModifier`

This is a rewrite of the egui menus, with the following goals:
- submenu buttons should work everywhere, in a popup, context menu,
area, in some random Ui
- remove the menu state from Ui
- should work just like the previous menu
- ~proper support for keyboard navigation~
  - It's better now but requires further work to be perfect
- support `PopupCloseBehavior`

* Closes emilk#4607 
* [x] I have followed the instructions in the PR template
darkwater pushed a commit to darkwater/egui that referenced this pull request Aug 24, 2025
Breaking changes:
- When using the Memory::popup state, it's now required to call
keep_popup_open each frame or the popup will close.
- Usually handled by the `Popup` struct, but required for custom popups
using the state in `Memory` directly

-----

If a popup is abandoned `Memory::popup` would remain `Some`. This is
problematic if, for example, you have logic that checks
`is_any_popup_open`.

This PR adds a new requirement for popups keeping their open state in
`Memory::popup`. They must call `Memory::keep_popup_open` as long as
they are being rendered. The recent changes in emilk#5716 make this easy to
implement.

Supersedes emilk#4697 which had an awkward implementation

These two videos show a case where a context menu was open when the
underlying widget got removed.

Before (`any_popup_open` remains `true`)
![Screenshot 2025-03-16 at 18 22
50](https://github.com/user-attachments/assets/22db64dd-e6f2-4501-9bda-39f470b9210c)

After
![Screenshot 2025-03-16 at 18 21
14](https://github.com/user-attachments/assets/bd4631b1-a0ad-4047-a14d-cd4999710e07)



* Closes emilk#3657
* [x] I have followed the instructions in the PR template
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

egui feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unify menus with tooltips/popups

4 participants