Update to wry 0.13; support IPC, devtool, and feature flags

[asaaki]

First of all: Thank you for this amazing project!
I had already slightly more fun with this than with tauri itself, even though it stands on the shoulders of it (wry, tao).

I know it's a lot at once, but the wry 0.13 upgrade led me down a rabbit hole.

What changes:

• general dependency updates as much as possible (not only wry)
• switch from RPC to IPC handler, fix message (de)serialization
• modularize some code pieces
• adjust module/function/struct/enum visibility where it made sense (not all need to be pub)
• general cleanups

If something is not to your liking or you want something split up differently, I can try to cut separate PRs.

Note: I tested it with some examples and a local project, all on a Win10 machine.

[mrxiaozhuox]

I think upgrade to wry 0.13 has been implemented in another PR: #221

[mrxiaozhuox]

modularize looks great. But I think some feature flag is unnecessary.

[jkelleyrtp]

Looks great!! Thank you for diving into this!

We're probably going to tweak some of the feature flags before releasing our next version - especially with enabling dev tools by default in debug mode.

[asaaki]

Note on the feature flags:

According to wry's documentation, the following flags are MacOS-specific and only enable private APIs, which might only be used during development anyway:

• devtool
• transparent
• fullscreen

That does not mean, those flags actually toggle real behaviour for anyone else; if you want to use devtools on Windows or Linux, you always can, as well as transparency and fullscreen.

To be honest, those flags are named misleading and confusing, they should probably have platform prefixes to communicate, that they are not general purpose feature toggles.

The reason I included them here is that I do not want to block MacOS developers from using the private APIs if they so desire.

---

devtool

That one was interesting (at least on Windows).
wry 0.13 changed quite a bit on the behaviour, probably maybe due to the underlying switch of windows/webview2 related crates.
In my testing there was no entry on the context menu anymore, and also the Ctrl+Shift+i shortcut did not open.
That might be confusing at first, but considering that you do not want to have the devtool in a release, that is already quite nice.

So to actually open the devtool, one has to trigger that.
That's why I had to include the function on DesktopContext, so people can programmatically use it in their apps.

fn AppWithDevTool(cx: Scope) -> Element {
  let window = dioxus::desktop::use_window(&cx);

  // snip

  cx.render(rsx! {
    button {
      onmousedown: |e| e.cancel_bubble(),
      onclick: move |_| { window.devtool() },
      "Open DevTool"
    }
  })
}

I guess this should be documented probably. 😅

---

Bonus: disabling the context menu all together (as it's not very useful when no devtool entry is there):

// add this JS snippet somewhere in your app
window.addEventListener('contextmenu', e => e.preventDefault());

Kudos: tauri-apps/wry#30 (comment)

[jkelleyrtp]

To be honest, those flags are named misleading and confusing, they should probably have platform prefixes to communicate, that they are not general purpose feature toggles.

We'll probably remove them from the top-level dioxus crate, meaning you need to manually bring in the dioxus-desktop crate with features enabled to dig into platform-specific configurations. And perhaps prefix them with macos or something similar.