Re: Modernize wxMSW with WinUI (Issue #19352)
Jaiganésh Kumaran
Any update on this? I really want apps using cross-platform frameworks like wxWidgets to look modern with Fluent design on Windows.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Grant Kim
I would like to share about this implementation.
There are two way to implement this.
The first one is use Windows APP SDK. but this method is not really streamlined at this point because it is not possible to release a traditional binary form (e.g. statically linked single exe file or such) and I wasn't able to find statically link the "Microsoft.WindowsAppRuntime.Bootstrap.dll". Moreover, the separate WinApp runtime is required.
The last one that I tried was: use the XAML island and this one no needs to have additional dependencies.
Both way, you will can't use MinGW as your development platform unless MinGW gets WinRT related updates.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
Sorry, when you say "share this implementation", what do you mean exactly? I.e. what are you sharing, where is the code producing the screenshot above?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Grant Kim
I meant to share some information about what I have done.
Of course, it is not even close to be finished but I'm trying to implement UWP/WinUI in various ways. I'm not sure I'm going to dig this further, but I'll update once it gets some progress.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
If you have something that builds and is at least somewhat useful, please don't hesitate to already submit a PR with your changes, it's not a problem if it's incomplete. In fact, it would be much simpler to integrate any such changes piecewise than as one enormous change later when/if you do complete them.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Jaiganésh Kumaran
The last one that I tried was: use the XAML island and this one no needs to have additional dependencies.
While it doesn't need additional dependencies, you only get the Windows 10 styling out of the box. For the new Windows 11 style, you need to install the WinUI 2 NuGet package for XAML islands or a UWP app separately. So not a good option for self-contained and single file executables. But most apps using WinUI tend to be Store apps and it's not a problem for them.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
phantomhugo
I would like to add that mingw support is in their thoughts, see microsoft/WindowsAppSDK#3532
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
I would like to add that mingw support is in their thoughts, see microsoft/WindowsAppSDK#3532
This is nice to know, thanks for the link!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Sota Nakamura
The project in microsoft/WindowsAppSDK#3532 uses xaml, but we can use WinUI 3 controls in C++ codes without xaml and xaml island. see https://github.com/sotanakamura/winui3-without-xaml
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
PB
It seems little did change since my last post in this thread, i.e., WinUI 3 is still immature (may be read as "basically unusable with no light at the end of the tunnel") and no one is really using it in applications with complex UI (e.g., multiple top level windows, docking system, non-trivial dialogs). Too bad...
See also https://old.reddit.com/r/cpp/comments/15lk6fn/cwinrt_is_now_in_maintenance_mode/
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Sota Nakamura
Xaml islands for WinUI 3 is supported in Windows App SDK 1.4. It makes easier to access the WinUI 3 controls from a existing C++ project.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Nikita Bragin
Any news for winui support in wxWidgets?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
PB
IMO, WinUI 3 seems more and more like a stillborn child, unfortunately. There is little surprise that no one feels like investing a huge amount of time and effort in this, assuming it would be even feasible.
Fore example, the data presented in this discussion are not indicator of its bright future.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Brickmasterhunt
Brickmaster1 left a comment (wxWidgets/wxWidgets#19352)WinUI 3 definitely has the modern looks and I like the style, but from my experience in apps the UI just looks decent without doing anything. The performance is horrible, and if feels very sluggish and unproductive to do anything. Windows' own settings app is a great example of this. I have a very good computer by most means of measurement (Intel i7 9700k and RTX 3080, 32GB RAM) and the app just doesn't have a good framerate/ the animations limit the speed at which I can perform simple actions. If wxWidgets were to implement this in any way at all, I would only want it to make an exact copy of the style, but rewrite the implementation in the wxWidgets style, with the performance that can be cherished in wxWidgets apps. That's my two cents.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Fefe_du_973
Fefedu973 left a comment (wxWidgets/wxWidgets#19352)Given Microsoft’s recent renewed focus on Windows quality, including their stated goal of moving more core Windows experiences to WinUI 3 to improve responsiveness, I wonder whether it might be worth re-evaluating the feasibility of a WinUI-based wxMSW backend or integration layer.
Of course, this would likely be a major effort and WinUI 3 still has known trade-offs, but the recent Windows App SDK 2.x releases and Microsoft’s renewed investment in WinUI seem to make the idea more relevant than it was when this issue was originally opened.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.
jsha...@gmail.com
Fefe_du_973
Fefedu973 left a comment (wxWidgets/wxWidgets#19352)This is my first extremely early prototype.
I'll release the code and the branch as soon as possible.
I will need a lot of help to make that a reality and stable but i belive in it !
https://github.com/user-attachments/assets/e2665511-4279-49b0-8fa4-7bb8fc5b80e7
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.
Fefe_du_973
Fefedu973 left a comment (wxWidgets/wxWidgets#19352)Experimental wxWinUI port prototype
I have a first experimental wxWinUI branch that adds a WinUI 3 based Windows port prototype for wxWidgets.
Branch:
https://github.com/Fefedu973/wxWidgets/tree/feature/winui-port-prototype
The current approach keeps the normal wxWidgets API surface, but implements a subset of controls using WinUI 3/XAML Islands. Each wx control owns a native HWND, and that HWND hosts a DesktopWindowXamlSource whose content is the corresponding WinUI control.
Currently implemented / partially working:
wxFramewxPanelwxButtonwxStaticTextwxTextCtrlwxChoicewxCheckBoxwxRadioButtonwxSliderwxStaticLine- sample at
samples/winui
The runtime is bootstrapped through Windows App SDK for unpackaged apps. The port initializes WinRT/WinUI, creates a dispatcher queue, sets up WinUI resources, and routes keyboard messages through WinUI’s ContentPreTranslateMessage.
The current sample proves that native WinUI controls can render inside a classic wxWidgets app, and that wx events can be forwarded back from WinUI controls into normal wx event handlers.
Known issues still being investigated:
- text input still has keyboard routing problems, including the Windows error sound and duplicate characters for some keys
- Mica/backdrop rendering behaves incorrectly on non-HDR displays
- focus/tab navigation across multiple XAML islands still needs more work
- I still need to implement many more widgets. The end goal is to be able to compile
widgets.exeusing this WinUI port and that everything works as expected in this demo app. - this is still a prototype branch, not a complete port
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.
Nick Logozzo
nlogozzo left a comment (wxWidgets/wxWidgets#19352)WinUI has experimental CMake support: microsoft/WindowsAppSDK#6446
And there is this library that may help as well: https://github.com/roxk/idlgen
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#19352)I have a first experimental
wxWinUIbranch that adds a WinUI 3 based Windows port prototype for wxWidgets.
Wow, this looks very impressive, great news!
Do you have build instructions somewhere? I'd like to try building this myself.
From a quick look at the code, it seems like this follows the typical wx strategy of including wx/winui/foo.h from wx/foo.h when using wxWinUI, which is perfectly reasonable, but one of the first question I have is whether we could write this port in a way to allow mix-and-matching WinUI and Win32 controls because I suspect a lot of existing applications have some MSW-specific code in them which wouldn't work if you just replace wxMSW with wxWinUI, so it would be great if we could allow progressive migration by making it possible to create either classic Win32 or WinUI controls. Have you thought about this by chance?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.
Ferréol DUBOIS COLI
Fefedu973 left a comment (wxWidgets/wxWidgets#19352)I have a first experimental
wxWinUIbranch that adds a WinUI 3 based Windows port prototype for wxWidgets.Wow, this looks very impressive, great news!
Do you have build instructions somewhere? I'd like to try building this myself.
From a quick look at the code, it seems like this follows the typical wx strategy of including
wx/winui/foo.hfromwx/foo.hwhen using wxWinUI, which is perfectly reasonable, but one of the first question I have is whether we could write this port in a way to allow mix-and-matching WinUI and Win32 controls because I suspect a lot of existing applications have some MSW-specific code in them which wouldn't work if you just replace wxMSW with wxWinUI, so it would be great if we could allow progressive migration by making it possible to create either classic Win32 or WinUI controls. Have you thought about this by chance?
Thanks, glad you like it!
Build instructions
It's a normal CMake build with one extra toolkit option. On Windows 11 with VS 2022 / MSVC:
cmake -S . -B build-winui -G "Visual Studio 17 2022" -A x64 -DwxBUILD_TOOLKIT=winui cmake --build build-winui --config Release --target winui # the wxWinUI sample (what you saw in the demo video) cmake --build build-winui --config Release --target widgets # the widgets sample
-DwxBUILD_TOOLKIT=winui sets WXWINUI, adds the __WXWINUI__ __WXMSW__ defines and enables wxUSE_WINUI3. The Windows App SDK dependencies are pinned and restored automatically (see the versions in build/cmake/winui.cmake); requirements today are Windows 11, MSVC, and an unpackaged Windows App SDK bootstrap at runtime. I can add a short docs/winui/ README to the branch if that's useful.
Mixing WinUI and Win32 controls / progressive migration
Yes — and I think the architecture is actually well-suited to it, which is encouraging. The port is an overlay on wxMSW, not a rewrite of the HWND model: every wxWinUI control is still a real Win32 child HWND, and a per-control DesktopWindowXamlSource XAML island is hosted on that HWND's client area. So a WinUI control and a classic Win32 control are both just HWND children and already coexist fine in the same window/sizer — there's nothing in the rendering/hosting model that prevents it. GetHandle() still returns a real HWND, so a fair amount of HWND-level MSW code keeps working; what breaks is code that assumes the HWND is a specific native control class (subclassing it, sending EM_*/BM_* messages, etc.), since the visible control is now a XAML island rather than a native BUTTON/EDIT. That's exactly the case where being able to keep a control as classic Win32 is the right escape hatch.
The only thing that's currently all-or-nothing is compile-time class selection: under __WXWINUI__, wx/button.h pulls in wx/winui/button.h instead of wx/msw/button.h, and the build compiles src/winui/button.cpp in place of src/msw/button.cpp. So in a given build wxButton is either the Win32 one or the WinUI one — not both. I did this deliberately to keep the prototype simple (goal: get widgets.exe running unmodified), but it's not a fundamental constraint.
I've thought about a few ways to allow both, roughly least → most invasive:
- Parallel classes — keep the wxMSW classes as-is and expose the WinUI ones under distinct names (e.g.
wxWinUIButton). ExistingwxButtoncode stays classic Win32; you migrate a control at a time by switching the type. Least invasive, fully explicit, zero runtime cost, but not source-transparent. - Per-window / per-app opt-in with a peer/backend split —
wxControl::Create()dispatches to either a Win32 or a WinUI peer based on a flag (conceptually like the wxOSX peer, or the native-vs-generic split). Most transparent for existing code, but a much bigger refactor since it needs a proper backend abstraction. - Hybrid —
wxButtondefaults to wxMSW, with a scoped opt-in (a window flag, or "use WinUI for the children created under this window") that makesCreate()produce WinUI peers.
My instinct is that (1) or (3) gets us progressive migration with the least risk, while (2) is the "right" long-term shape if we want it to be transparent. Before I restructure the prototype I'd love your steer on which direction fits wxWidgets best — in particular whether you'd prefer a peer/impl abstraction inside the existing classes vs. parallel opt-in classes — since it affects how the whole port is organized.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#19352)I can add a short
docs/winui/README to the branch if that's useful.
Yes, I think it would be (either there or docs/msw/winui.txt).
I've thought about a few ways to allow both, roughly least → most invasive:
I think for now the simplest thing to do would be to implement a variant of your (1) by providing both wxWinUI::Button and wxMSW::Button (I think this is better than wxWinUIButton and wxMSWButton because this could give you a way to easily select between the implementations in the given scope by just adding a using directive) and making wxButton a typedef for one of them (although in practice it will have to be a class deriving from them because there are plenty of forward declarations of it in the existing code).
The other approaches are, in principle, more flexible and I'd like to have a pimpl-based implementation for all wx classes but, as you say, this would require many more changes, so maybe it would be better to start with (1).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.