Separate the concept of "platform" and "GUI toolkit"?

[madsmtm]

raw-window-handle recently changed their API to use the names of the toolkit instead of the platform. E.g. Windows -> Win32 and MacOS -> AppKit.

This is done because the mapping is not 1:1, an example in winit is Wayland vs. X11 (X11 can technically be used on MacOS as well), another prominent example is that UIKit applications can be used on MacOS using Mac Catalyst. Additionally, AppKit applications can technically also run under non-macos systems using GNUStep (though winit likely won't work out-of-the-box for this), and I suspect similar compatibility libraries exist for the other toolkits.

winit is only built to handle the most common platform/toolkit combinations, but maybe we should start to change this? It would allow using winit in more situations, and would also open up for adding support for choosing Qt or GTK (the fairly popular druid-shell and the fork tao both use GTK, if that's any indication) as one's backing toolkit.

Concretely, we could begin by renaming things:

• Documentation ("Platform-specific" section -> "Toolkit-specific" section)
• Extension traits (WindowExtIOS -> WindowExtUiKit)
• Directory/file structure externally (e.g. platform::macos -> toolkit::appkit)
• Directory/file structure internally (e.g. platform_impl/windows -> toolkit_impl/win32)

In the future we could then expose features to enable each toolkit, with sensible defaults set per platform (see https://github.com/rust-lang/cargo/issues/1197#issuecomment-268203727).

Downsides include teachability (most users probably don't care about the distinction), git conflicts (there are a lot of open PRs that would potentially be affected by a rename) and churn (any usage of the platform module would have to change).

Opening this for discussion, there are other ways to solve the Mac Catalyst and GTK problems!

[maroider]

Making platform support be less tied to the compilation target is certainly an intriguing idea, but that would seemingly require rust-lang/cargo#1197 to be implemented instead of being a feature request.

As for renaming things in the docs, well, I'm not sure "GUI toolkit" is the best name here. Wayland certainly doesn't fit the bill. "Platform" seems neutral enough to me, and doesn't necessarily imply that it's strictly tied to an OS (although a "platform" is usually tied to one OS).

Furthermore, I have some concerns about having a "GTK backend". IIRC, druid-shell adopted GTK since it was easier than going straight for X11 and/or Wayland, and tao seemingly does it to accommodate for tauri's need to use WebKitGTK, which seemingly (and thus frustratingly) can't be used in non-GTK applications. I believe a better approach for GTK and QT integration would be to have a separate crate that builds on top of winit, rather than having such a feature live in winit proper, as I am of the mind that adopting such backends would fundamentally limit our ability to deliver on a consistent cross-platform experience.

[wusyong]

I created winit-gtk, a winit fork with GTK backend, in hope of pushing this discussion further. Right now you can add it by configuring Cargo like:

winit = { package = "winit-gtk", version = "0.28" }

Is the plan still pushing #2430? And what's the expectation for other "backend" crate that will build on top of winit?

[notgull]

I'd like to point out that both glazier (the successor to druid-shell) and tao are actively moving away from GTK as a backend.

Personally I would not support GTK/Qt as a first class backend, since it makes packaging exponentially more complicated.

[wusyong]

tao is moving to the way that can switch back to winit again, and it'll still require GTK. I don't mean to support GTK/QT as first-class backend. I would like to see winit can work with these toolkits instead. Just like AppKit is de facto toolkit on Mac and anyone who uses winit can integrate with them easily.

[madsmtm]

Is the plan still pushing #2430?

I'll try to make a push forwards on it at some point, but I think I'd like some feedback from the other maintainers on the core idea before proceeding (otherwise, if we decide it's not the way forwards, I'll just waste a great deal of time).

And what's the expectation for other "backend" crate that will build on top of winit?

I remember talking with @amrbashir on Matrix that we'd just put it behind a feature flag unstable-gtk that's disabled by default, and be done with it. Nobody here actually want to have first-class GTK support, but that's the most pragmatic solution that gets rid of the fork.

[amrbashir]

Nobody here actually want to have first-class GTK support, but that's the most pragmatic solution that gets rid of the fork.

I agree, it is not desired but the quickest solution available but #2430 is probably the best solution long-term.