ReUnion and WinUI3 do not support taskbar control - TaskbarItemInfo

[ivberg]

Describe the bug ReUnion and WinUI3 do not support taskbar control - TaskbarItemInfo. Both these projects promise to be additive and not take away from being able to use existing APIs or Win32 functionality. However, most popular win32 apps use taskbar controls like play/stop or other quick useful controls (introduced in Win7).

For C# - this is exposed via the TaskbarItemInfo class. https://docs.microsoft.com/en-us/dotnet/api/system.windows.shell.taskbariteminfo?view=net-5.0

Steps to reproduce the bug

1. https://aka.ms/winui and per instructions create a C# Desktop WinUI3 0.5 app
2. Attempt to add taskbar functionality via https://docs.microsoft.com/en-us/dotnet/api/system.windows.shell.taskbariteminfo?view=net-5.0
3. You will XAML compiler errors stating that for example this error:

4. Error WMC0001 Unknown type 'CommandBinding' in XML namespace 'http://schemas.microsoft.com/winfx/2006/xaml/presentation'

Expected behavior That ReUnion and WinUI3 support or allow these things just like WPF app would

Screenshots

Version Info WinUI3, ReUnion 0.5.7

NuGet package version: PackageReference Include="Microsoft.ProjectReunion" Version="0.5.7" PackageReference Include="Microsoft.ProjectReunion.Foundation" Version="0.5.7" PackageReference Include="Microsoft.ProjectReunion.WinUI" Version="0.5.7"

Windows app type:	UWP	Win32
	Yes

Windows 10 version	Saw the problem?
Insider Build (22000.40)	Yes

Device form factor	Saw the problem?
Desktop	Yes

Additional context

[asklar]

@ivberg you can add Reunion to an existing WPF app and call reunion APIs, but AFAIK the app must be WPF, not WinUI (WinUI doesn't know about WPF / WinForms apis).

I don't believe there is a WPF project template for Reunion yet so you'd have to do this by hand (create new WPF project, reference Reunion, call non-WinUI APIs).

[iceberg1370]

Yes seems to be the case. This would be a feature request to reimplement in WinUI with a helper class like TaskbarItemInfo similar to WPF. The idea for more WinUI adoption is to remove as many barriers to entry (or switching costs) as possible. Should be possible since these TaskBar items are native APIs underneath anyways.

[nikolayvpavlov]

Lack of integration with the taskbar is really disturbing. This is a selling point compared to web apps, and WinUI is missing it completely.

[castorix]

You can use ITaskbarList3

[nikolayvpavlov]

You can use ITaskbarList3

This is the kind of attitude that alienates developers. Taskbar support is there in WPF, and there is no need to go to interop. Now, in WinUI, that is supposed to be the latest and greatest, we need to go down to bare metal for basic interaction with the Shell. Please. Why would one then want to use WinUI at all?

[castorix]

...Taskbar support is there in WPF... Why would one then want to use WinUI at all?

WinUI is based on UWP, and they have probably higher priorities/bugs to fix (and I don't see a lot of apps which use ITaskbarList* interfaces)

[nikolayvpavlov]

(and I don't see a lot of apps which use ITaskbarList* interfaces)

I don't see a lot of apps which use UWP. Even Microsoft own apps like Teams are based on Electron / WebView2 and are in essence. Not surprising with the death of the mobile platform and the strict sandboxing.

... they have probably higher priorities/bugs to fix

I don't buy this either. Both WinForms and WPF were very solid and quite feature-rich from v1. Even UWP was in a decent shape, too. WinUI starts as a hobbyist project, and the number of issues is ridiculous. Looks like nothing from WPF / UWP is properly reused.

I just finished a small radio media player in WinUI and, I can say, I am far from impressed. Too many quirks, too many weird visual effects, some controls failing to bind bi-directionally (RadioButtons) and limited to simple content (RadioButtons, NavigationView)...

And now you tell me I need to go to bare metal for proper integration with the Shell... Not very encouraging.

[nikolayvpavlov]

Let alone that I am very curious how I can handle the WM_COMMAND message from WinUI. Perhaps I am too dense, but I can't find a nice way to do it without going to interop and replacing the very window proc. Huh.

[castorix]

Let alone that I am very curious how I can handle the WM_COMMAND message from WinUI.

Yes, as you said, the usual way is with P/Invoke and SetWindowSubclass (like in the samples I posted)

A quick test with ITaskbarList3 and a Toolbar (like the MS SDK sample) :

[nikolayvpavlov]

@castorix , I honestly admire your work and effort, but there is no excuse that we need to go to interop for basic stuff like even command handling. I see no reason why WndProc is not exposed for overriding like in WinForms. Windows App Sdk is in its 1.1 version and feature-wise it is more of a 0.5.

[GuildOfCalamity]

I realize that MS is trying to decouple the window from the OS but it's a shame that these features were missed/avoided. It was so easy to add this to your MainWindow

    <Window.TaskbarItemInfo>
        <TaskbarItemInfo ProgressState="Normal" ProgressValue="{Binding BarProgress}" />
    </Window.TaskbarItemInfo>

And now you can't port any of your existing UWP/WPF window specific features to WinUI3.