Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: disable default menu to allow custom menus #5320

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

vgarleanu
Copy link

Slint at the moment does not support native menu bar integration. This PR aims to alleviate this issue somewhat by making slint compatible with the muda crate from tauri.

Muda does not work when the default menu for the menu-bar is enabled, thus this PR disables it by default on MacOS.

@CLAassistant
Copy link

CLAassistant commented May 30, 2024

CLA assistant check
All committers have signed the CLA.

@tronical
Copy link
Member

Thanks for the patch. I'm a little torn about this :-)

On the one hand, I think it's in everyone's interest to be able to use Slint with muda. Yes, to that.

On the other hand, when not using muda, this makes a suboptimal situation even worse: By default, winit adds a minimal entry to the system menubar on macOS with an about item and the ability to quick the application. With this change and when not using muda, there's no more system menubar - instead the menubar of the previous application is active. I think that's very confusing.

I think that perhaps the use-case of muda is best addressed by using the window_builder_hook. What do you think?

@vgarleanu
Copy link
Author

Thanks for taking a look @tronical. I agree with you here, if you don't supply a custom menu-bar then the experience becomes suboptimal. I think ideally we'd need a event_loop_builder_hook, as the menu-bar isnt controlled via the WindowBuilder but rather the EventLoopBuilder.

Let me know what you think! Also on another note, adding a event_loop_builder_hook would also allow us to create a proxy for the EventLoop that would be exposed publicly, I and many others have use-cases where we need access to the raw event-loop event stream. We could potentially kill two birds with a single stone here!

@tronical
Copy link
Member

Oops, good catch about EventLoopBuilder vs. WindowBuilder. Since there can only ever be one EventLoop and that's created in new_with_renderer_by_name, I think a hook wouldn't work but it would have to be a parameter to the new function. Maybe like new_with_event_loop_builder?

@vgarleanu
Copy link
Author

So we'd pass a event-loop builder? Why not just pass a built event-loop?

@tronical
Copy link
Member

that sounds okay to me :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants