Taskbar progress

[valaphee]

• [x] Tested on all platforms changed
• [x] Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• [x] Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• [x] Created or updated an example program if it would help users understand this functionality
• [x] Updated feature matrix, if new features were added or implemented

This adds a simple way to set the progress indicator in the taskbar on Windows, there is still no way to set the state to error or paused, and don't know if it should be added.

[daxpedda]

Dropping some stuff I found while searching for cross-platform compatibility:

• taskbar_interface - Rust crate that can do this externally (with window handles). Supports Windows and Linux.
• X11 can be supported through libxapps with _NET_WM_XAPP_PROGRESS. Actual DE support is spotty.
• There is a Unity Launcher API for this, which e.g. KDE supports. I assume this isn't something we can support in Winit.
• MacOS has the ability to draw whatever in the taskbar, so there are some implementations that simply draw a progressbar. See e.g. DockProgressBar.

[valaphee]

Ah didn't know that this is not only a Windows thing, will look into it

[daxpedda]

Ah didn't know that this is not only a Windows thing, will look into it

Let's do it in follow-ups though, because this here is uncontroversial while the others are not. You should get the other backends approved by the corresponding backend maintainers first before putting in any significant work.

[kchibisov]

Such stuff generally has nothing to do with windowing which is all winit about. That's the reason external APIs exist.

On Linux there's no standard interface for that, the same goes to tray. It's usually all dbus, because again, nothing to do with windowing and tied to specific DE, so not winit job.

[notgull]

Agreed with @kchibisov. If it has nothing to do with windowing, it doesn't belong in winit.

[valaphee]

I mean there is already a function to hide the window in the taskbar, and I agree that the taskbar and tray area are not really window related. But the necessary groundwork is already there and setting the progress requires the hwnd, and having the functionality in winit makes it also more visible to the user. It's also relatively light-weight, easy to maintain, and common.

But I would never add other taskbar functionalities though like adding buttons, etc.

[valaphee]

Just out of curiosity, the taskbar buttons have to be handled in WndProc https://github.com/microsoft/Windows-classic-samples/blob/main/Samples/Win7Samples/winui/shell/appshellintegration/TaskbarThumbnailToolbar/ThumbnailToolbar.cpp

[daxpedda]

Such stuff generally has nothing to do with windowing which is all winit about. That's the reason external APIs exist.

On Linux there's no standard interface for that, the same goes to tray. It's usually all dbus, because again, nothing to do with windowing and tied to specific DE, so not winit job.

I assume this was meant for Linux only? Windows still seems in scope to me considering we are handling plenty of similar taskbar related things there already.

I would consider MacOS not in scope as well because it doesn't actually offer an API to do that.