refactor: remove wry/cef feature flags, enforce runtime crates usage

[lucasfernog]

Runtime & feature flag changes

Runtime

• tauri::Wry removed. Use an explicit runtime type, e.g. tauri_runtime_wry::Wry<tauri::EventLoopMessage> (or CEF), and build with tauri::Builder::<YourRuntime>::new().

Feature flag

• Wry/CEF features removed. The tauri crate no longer has wry or cef features. You choose the runtime by adding the runtime crate to your dependencies (e.g. tauri-runtime-wry or tauri-runtime-cef), not by enabling a feature on tauri

Breaking changes

• tauri::Wry removed. Replace tauri::Builder::<tauri::Wry>::new() with tauri::Builder::<tauri_runtime_wry::Wry<tauri::EventLoopMessage>>::new() (or your chosen runtime). A type alias is recommended.
• No more wry/cef features on tauri. If you relied on tauri with features = ["wry"] (or similar), you now depend on tauri-runtime-wry (or tauri-runtime-cef) and pass that runtime type to the builder.

[github-actions]

Package Changes Through 4fce1df

There are 5 changes which include tauri-macos-sign with patch, tauri with minor, @tauri-apps/cli with patch, tauri-cli with patch, tauri-bundler with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
tauri-macos-sign	2.3.3	2.3.4
tauri-bundler	2.8.1	2.9.0
tauri	2.10.3	2.11.0
@tauri-apps/cli	2.10.1	2.10.2
tauri-cli	2.10.1	2.10.2

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[FabianLars]

i didn't look through the whole PR yet but what do you think about including it (minus the cef part) in tauri v3 as well? I think with that in place we could potentially gradually port over cef support, keeping the runtime itself separate for the time being.

With v3 still being some time off i think we have enough time to test this approach before bringing it into v3.

[amrbashir]

Removing tauri::Wry would mean removing the default Runtime implementation for tauri::AppHandle, tauri::Window...etc which is a big breaking change given that a lot of users use these types without specifying the generic R and defaulting to Wry runtime.

I am not opposed to removing though, I just think we can go a little further by removing the R generic from all public types and instead use dynamic dispatched runtime.

tauri::Builder::default()
  .runtime(tauri_runtime_wry::default())
  .run()
  .expect("failed to run")

where the runtime method would use Arc or Box

impl Builder {
  fn runtime<R: Runtime>(mut self, runtime: R) -> Self {
    self.runtime = Some(Arc::new(runtime));
  }
}

[lucasfernog]

Removing tauri::Wry would mean removing the default Runtime implementation for tauri::AppHandle, tauri::Window...etc which is a big breaking change given that a lot of users use these types without specifying the generic R and defaulting to Wry runtime.

I am not opposed to removing though, I just think we can go a little further by removing the R generic from all public types and instead use dynamic dispatched runtime.

tauri::Builder::default()
  .runtime(tauri_runtime_wry::default())
  .run()
  .expect("failed to run")

where the runtime method would use Arc or Box

impl Builder {
  fn runtime<R: Runtime>(mut self, runtime: R) -> Self {
    self.runtime = Some(Arc::new(runtime));
  }
}

hmm that's a breaking change to every plugin out there - but there are more apps than plugins, I can see why that makes sense.

i didn't look through the whole PR yet but what do you think about including it (minus the cef part) in tauri v3 as well? I think with that in place we could potentially gradually port over cef support, keeping the runtime itself separate for the time being.

With v3 still being some time off i think we have enough time to test this approach before bringing it into v3.

well currently this feat/cef branch is what i envision the "v3" branch being.. if we start a dev -> v3 -> feat/cef branch cascade that works too, but it'll be fun to manage 😂

[FabianLars]

well currently this feat/cef branch is what i envision the "v3" branch being.. if we start a dev -> v3 -> feat/cef branch cascade that works too, but it'll be fun to manage 😂

hmm the last few conversations sounded more like cef will come later than v3 (or in a follow up 3.x) as we have e.g. the gtk4 upgrade waiting or the MSRV policy issue that's getting more annoying by the day.

[lucasfernog]

dynamic dispatch is really complicated btw.. i hit all sorts of object safety issues with the traits :/

[lucasfernog]

well currently this feat/cef branch is what i envision the "v3" branch being.. if we start a dev -> v3 -> feat/cef branch cascade that works too, but it'll be fun to manage 😂

hmm the last few conversations sounded more like cef will come later than v3 (or in a follow up 3.x) as we have e.g. the gtk4 upgrade waiting or the MSRV policy issue that's getting more annoying by the day.

yeah I know v3 shouldn't be tied to CEF at all.. I'm just lazy to port some of the breaking changes to a separate branch - but I will :(