http://bugs.winehq.org/show_bug.cgi?id=59522 Bug ID: 59522 Summary: explorerframe: ITaskbarList3 SetProgressValue/SetProgressState stubs - could use native desktop backends Product: Wine Version: 11.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: explorerframe Assignee: wine-bugs@list.winehq.org Reporter: Robert-Gerigk@online.de Distribution: --- ITaskbarList3::SetProgressValue() and SetProgressState() in dlls/explorerframe/taskbarlist.c are currently stubs (FIXME + return S_OK). This causes Issues with .NET/WPF applications that use the Windows 7+ taskbar progress API. Some appplications (e.g. WPF apps using TaskbarItemInfo) deadlock or behave incorrectly when the COM call chain around these methods interacts with the UI thread. Wine already implements plattform-specific desktop integration in several places: - macOS: Full Cocoa integration (NSStatusBar, NSDockTile) in winemac.drv - X11: EWMH hints including _NET_WM_STATE_DEMANDS_ATTENTION in winex11.drv - Wayland: xdg-toplevel-icon-v1 protocol in winewayland.drv - DBus: Production clients for BlueZ and UDisks in winebth.sys and mountmgr.sys A natural Extension would be implementing taskbar progress via the com.canonical.Unity.LauncherEntry DBus interface, wich is supported by KDE Plasma, GNOME, and other Linux desktop environments. Firefox and LibreOffice already use this interface for native taskbar progress. Proposed mapping: TBPF_NOPROGRESS -> progress-visible: false TBPF_NORMAL -> progress-visible: true, progress: value TBPF_INDETERMINATE -> progress-visible: true, progress: 0.0 TBPF_ERROR -> urgent: true TBPF_PAUSED -> progress-visible: true (no direct equivalent) The implementation would follow the existing DBus pattern from mountmgr.sys/dbus.c (dlopen/dlsym, graceful degradation when libdbus-1 is unavailable). I'd be willing to work on a Linux/DBus patch if there's interest. Looking for feedback on: 1. Is this the right component (explorerframe) or should this be handled in the platform drivers (winex11.drv, winewayland.drv)? 2. How should the .desktop file association be resolved? (DBus needs an application:// URI) 3. Any concerns about adding a libdbus-1 dependency to explorerframe? I'm currently working on getting KNX ETS 6.4 (a .NET/WPF application) running under Wine and ran into several issues along teh way, this being one of them. The application uses TaskbarItemInfo for progress display wich leads to Problems in the COM/UI thread interaction. ETS 6.4 does run on Linux now, but only trough launch scripts, .dll patches, registry workarounds, and a heavily patched Wine prefix (winetricks dotnet48 + manual fixes) - it would be great to reduce those workarounds over time. I am mostly a solo devloper with an electrical engineering background and fairly new to collaborative development on Gitlab/GitHub, so I'd appreciate any Guidance on the right approach for this - happy to learn. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.