"Blessed" way to do things out of winits scope? (winit-extras)

[madsmtm]

There are a lot of things out of winit's scope that are useful (and maybe expected by most people that we provide), here's a few examples I've stumbled across, though there are many more:

• Clipboards (Provide system clipboard handling API on Window #2156)
• macOS gestures (Add touchpad magnify and rotate gestures support for macOS #2157)
• Maybe popups? (Pop-up menus #403)
• Menubars (Noob Question on Menus etc #427 / feat: WIP Custom menu builder #1921)
• macOS file open events (Allow listening to file open events on macos #1759)

The readme already notes this, and directs users to various graphics libraries, but these are not always what the user wants (or their graphics library may not support it).

It has been suggested we make a winit-extras crate or similar under the @rust-windowing umbrella (name up for bikeshedding), to house these components; this would help us with:

• Providing examples of usage
• Ensuring our APIs actually allow external crates to hook in to the functionality they need (we're working towards this, see Platform-specific event callbacks #2120)
• Helps keeping these extra features up to date with the latest winit version
• In the cases where we depend on an external library for this, this "blesses" that library, providing a more consistent user experience (currently there are many clipboard libraries out there; it would be nice if the ecosystem could converge on a single one)

The alternative is just to make crates for each of these things, and document them in the wiki (though for some of the smaller features like file open events it seems kinda dumb).

[madsmtm]

Third alternative is to simply increase the scope, though that brings other problems (such as not having enough maintainer time to support it and general feature creep) - though creating a new crate under the @rust-windowing umbrella also kinda exhibits these problems...

[tinaun]

note that the tauri maintainers have already forked winit to add menus / clipboards etc in tao

[notgull]

I would, personally, support this. I was actually about to make my own extension crate to do this, but I feel having an official endorsement from @rust-windowing would boost its legitimacy.

[parasyte]

There are multiple crates trying to offer various desktop environment features that winit lacks. I often find myself questioning why these need to be separate from the window management library, and what value it has. IMHO, any of these are obvious candidates for inclusion in a winit-extras crate:

• Common dialogs
  • rfd
  • nfd
  • nfd2
  • nfde
  • native-dialog
  • tinyfiledialogs
  • msgbox
  • dialog
• System tray icons
  • tray-icon
  • tray-item
  • systray
  • quoll
  • stray
• Desktop notifications
  • notify-rust
  • notifica

[kchibisov]

Desktop notifications in any form are out of scope, they don't require the windowing system in the first place for what I know.

Tray is the same thing I guess, though might not be entirely. Don't want to deal with it inside the winit though.

I'm not sure about what type of dialogs are you talking about, but such usually is a part of the GUI toolkit, the dialog is a regular window, so it's all out of scope for winit, I'd say.

Winit should collect essential features which is hard to get right in such 3d party crates, we're not the GUI toolkit, but the windowing library, you built your toolkit on top of it.

[parasyte]

Well then it's a good thing this ticket is for tracking "things out of winits scope".