add default menu bar in dioxus-desktop to resolve #1691

[pascalbehmenburg]

Feature: add default menu bar to dioxus-desktop

It looks like this on macOS (please ignore firefox underneath it):

This also resolves #1691 since, as mentioned there, macOS requires menu bar items with keybindings assigned to them to enable system default text editing and window shortcut behaviors.

Solution

The feature was implemented by adding a function fn create_default_menu_bar() -> MenuBar in webview.rs which constructs a platform specific menu bar that may be passed into window_builder if disable_default_menu_bar is false which is defined in config.rs to enable the option to opt out of having a menu bar at all. diasable_default_menu_bar is false by default, and therefore the window_builder will use the default menu bar if the user does not opt out, as implemented in webview.

I think this should be exactly what @ealmloff described in his comment.

clippy and all tests including playwright passed on master.

Note: due to tao not supporting a lot of native menu bar items on Linux, there is no edit menu on Linux yet.

Example usage

Cargo.toml:

dioxus = { path = "../dioxus/packages/dioxus/" }
dioxus-desktop = { path = "../dioxus/packages/desktop/" }

main.rs:

use dioxus::prelude::*;

fn main() {
    dioxus_desktop::launch_cfg(
        App,
        dioxus_desktop::Config::new()
            .with_disable_default_menu_bar(false)
    );
}

fn App(cx: Scope) -> Element {
    render! {
        input {
            r#type: "text",
            placeholder: "Enter smth. and use Ctrl + A / Cmd + A...",
        }
    }
}

[ealmloff]

I have one small question about a function name, but overall looks great! This will help make desktop apps work more like I would expect out of box. (I also really appreciate the detailed PR description 🙂)

[jkelleyrtp]

Agreed, looks great, definitely something we want to support. It might be worth to make the function that builds the menubar public and then change the naming scheme to what @ealmloff mentioned. Other than that, LGTM!

[esimkowitz]

Do we want this to be the default behavior on all platforms or only on Mac? I haven't been targeting Windows or Linux recently but if I remember correctly they weren't impacted by the keybindings issue

[pascalbehmenburg]

Do we want this to be the default behavior on all platforms or only on Mac? I haven't been targeting Windows or Linux recently but if I remember correctly they weren't impacted by the keybindings issue

Actually, I don't think it is an issue on Linux or Windows, though I haven't been able to test it either. Otherwise, I do think it won't be bad to have those very basic menus included on these platforms too. It is more consistent that way, otherwise one might wonder where the menus went when cross-compiling or similar.

Agreed, looks great, definitely something we want to support. It might be worth to make the function that builds the menubar public and then change the naming scheme to what @ealmloff mentioned. Other than that, LGTM!

So you basically want to expose the standard menu bar that was built so that one could adjust it further instead of having to re-create a new Menubar when intending to customize the existing one? I think that would be nice, but I am not too sure where to put it. I thought about exposing it and accepting a MenuBar instead of a bool, but MenuBar does not implement copy / clone. Also, I think no one would expect it to be found in webview.rs when using it from the outside. If you have an idea on that I would be really happy about adjusting it, otherwise I'd suggest keeping it the way it is with the incoming naming changes and opening an issue about exposing it where we can discuss this further.

[pascalbehmenburg]

@ealmloff I think this should be ready to be merged now, please check my commit history though since I had a huge fuckup in there where I committed 90 files on accident which were touched by cargo fmt --all. I reverted the commit but since I am not that used to more advanced git commands it would be nice of you to give a look. Also, if possible, squashing the commits into one wouldn't be that bad, I think.

[ealmloff]

Thank you!

[ealmloff]

It might be better to wait to merge this until the last 0.4 version goes out. If you already have the system menu added manually, it wouldn't be great to add a second menu even if the API isn't technically breaking