wxWidgets
Modernize wxMSW with WinUI
Issue migrated from trac ticket # 19352
component: wxMSW | priority: normal
2021-12-21 19:04:19: TrylzEngine created the issue
Hello,
It would be wonderful to add WinUI support or replace the old Win32 by it. From the documentation they says it can be done on a seamless way:
https://microsoft.github.io/microsoft-ui-xaml/about.html See "Path for desktop (Win32) apps"
I am voluntary to implement it if I can get help from a WxWidgets developer.
Thanks a lot!
2021-12-21 20:48:51: @PBfordev commented
(I am not a developer)
Out of curiosity: Do you have an experience with WinUI 3 development. I do not, but from what I read it seems that it is quite buggy, limited, and slow. I understand it is very new but still...
I took a look at the API some time back but I have no idea how to implement wxWidgets' paint event based drawing with WinUI retained graphics mode? But hopefully I am missing something. Does it already make easy to use multiple top level windows? I assume WinUI 3 application does not have to use XAML and all controls can be simply generated by code at runtime?
Considering Microsoft's recent history with new GUI APIs, one would be cautious to jump at yet another soon-to-be-abandoned ship.
By the way, are you aware of any reasonably feature-rich applications using WinUI 3 I could try? For example, MSVS can be seen as a flagship application for WPF.
2021-12-22 01:43:40: TrylzEngine commented
Just to give your our context. We are working on an upgrade of our Windows software. We use WxWidgets for our GUI. Problem is our users feels that the Win32 UI look is too old.
So to improve that we have three solutions:
- Replace WxWidgets by a library that uses the new Windows Controls(like WinUI)
- Try WxQT, but it seems it is still experimental. And the QT license is not very clear...
- My favorite -> Work on the WxWidgets WinUI port
2021-12-22 01:50:49: TrylzEngine commented
I never used WinUI before. From what I read here it seems to be the UI framework used by UWP itself. So I think it can be trusted. My guess is that C++ applications developed with UWP uses WinUI. But yes it wont be nice to start working on a new port and see Microsoft abandon the framework.
2021-12-22 07:48:44: @PBfordev commented
Replying to [comment:3 TrylzEngine]:
I never used WinUI before. From what I read here it seems to be the UI framework used by UWP itself.
I do not think this is correct, it may be the other way around, i.e., WinUI using (also) UWP, see the scheme at https://docs.microsoft.com/en-us/windows/apps/winui/winui3/
TBH, I am also not aware of any UWP application with rich UI (think MS Office or MSVS) but that may be just one of my many shortcomings. OTOH, I see Electron-based apps as crippled (e.g., compare UI features of Visual Studio and Visual Studio Code) but it apparently is good enough for many.
Regarding my concerns I listed in my first post (not even asking about mingw support for WinUI), maybe I am just overly pessimistic.
Good luck anyway.
2021-12-22 13:51:25: TrylzEngine commented
Thanks alot for all these good points! Yes you are right WinUI seems to use UWP. Is there a page explaining the WxWidgets loop?(message processing, drawing, etccc). I would like to start a WxWinUI platform and see where it goes.
If done(probably not before a year) will it be integrated to the main WxWidgets? Is there a developer I can contact when I have questions?
Thank you!
2021-12-22 14:40:27: @PBfordev commented
This (wx-dev discussion group, where the wxTrac traffic is sent) is the place where your posts can be seen and discussed by wxWidgets core developers. AFAIK, the "main" one (Vadim) said he is going to be very busy till the end of the year and even then the focus would be on 3.1.6 and 3.2.0 releases. So you may not get an immediate response.
Disclaimer: I am just a random guy, not a developer or programmer, so my views may be distorted but as always, here are my 2 cents anyway:
Firstly, I believe that creating a wxWidgets port for a new platform can be quite challenging task even if one is familiar with the target platform and wxWidgets internals, if nothing else then time-wise.
I assume you are reasonably familiar with wxWidgets library and understand how it works, i.e., that some controls are wrappers for the native ones where possible (e.g., wxButton), and some are generic on all platforms, implemented by wxWidgets adhering to platform standards (e.g., wxGrid).
I would start with learning WinUI 3, for example playing with the Controls Gallery, reading the API documentation, and writing some simple WinUI 3 code; to check what is and is not available.
Once I was reasonably sure it is possible to create a WinUI 3 port[1], I would start reading http://wxwidgets.org/docs/faq/general/#newport and the documents in WXDIR/docs/contributing.
As you probably know, there are already several ports that run on Windows, the default using WinAPI, the one using GTK, and there is also (somewhat neglected) wxUniversal. I am not sure if wxQt works on Windows or not. Looking at this ports may be useful to see how it all works under the hood. I do not think wxWidgets internals are officially documented somewhere, the documentation is mostly for the application programmers.
[1] The basic controls seem reasonably similar to WinAPI ones and probably can be used with wxSizers but as I wrote before, I am not sure about WinUI 3 supporting such features as multiple top level windows or how to adapt its retained graphics mode to the paint event based system wxWidgets uses. I would also make sure all the controls can be created by code at runtime, just as on all other ports and no (user-written) XAML is required. I suppose there is no support for WinUI 3 by mingw but I guess that cannot be helped.
2021-12-23 02:32:29: TrylzEngine commented
Thank you very much! I wouldn't find better explanations to start. I am familiar with WxWidgets but just as a user. Core code is almost unknow for me.
I will give it a try since it can benefit to both our software and WxWidgets. At least implement the possible features and see where it goes. If I have questions I will write them here then :).
Is it ok that I start by making a GitHub branch from the repo? Will it be tracked that I work on the port in case someone else ask about WinUI?
2021-12-23 04:53:55: @oneeyeman1 commented
Hi,
-
Discussing new ports and hw it should be implemented is done better on wx-dev ML. Please sign-up for it - the direct link is given at http://wxwidgets.org/support/mailing-lists/
-
Is it ok that I start by making a GitHub branch from the repo?
It is better to create your own fork and start there.
- Will it be tracked that I work on the port in case someone else ask about WinUI?
I don't know what you mean by tracked. People usually request by the ML I referenced above r file a ticket like you did.
Now the presumption of "old Win32 UI" makes me curious - do you have a link to a screensht for the UI elements. I am also curious - what wxWidgets version you use right now and what Windows version you are testing it on? I also presume you will be upgrading to latest 3.1.5 release.
What I would do is to try to update the code partially, make sure you include the manifest inside your binary and see if people will complain.
I would also consider looking into wxAUI and see if that is something you software can benefit from...
But that's just me - I don't know anything about WinUI, other than apparently it supports C/C++, but probably mostly .NET/JAVA.
Thank you.
2021-12-23 06:20:55: TrylzEngine commented
Hello,
-
I will post there if it is finally necessary to make the port. I realize that we could manually draw custom widgets for the ones our users "feel" outdated.
-
Sounds great thank you :)
-
Marvelous thanks! Simply wanted to avoid the case that multiple people work on the same port on different forks.
For the "old" look I was talking about, the color dialog is the perfect example.
Here a Win32 Color Dialog:
https://docs.microsoft.com/en-us/windows/win32/dlgbox/color-dialog-box
Here a WinUI 3 Color Dialog: https://docs.microsoft.com/en-us/windows/winui/api/microsoft.ui.xaml.controls.colorpicker?view=winui-3.0
The WinUI 3 ones looks better. Yes it could be linked to the fact that we have been seen the same Color Dialog on windows apps for decades. But still the old feeing is there.
2021-12-23 10:21:40: @PBfordev commented
Replying to [comment:9 TrylzEngine]:
For the "old" look I was talking about, the color dialog is the perfect example.
No offense, but IMO it is actually a very bad example.
WinAPI color dialog in the screenshot you referred to is a non-themed (just check how the buttons look) dialog running on Windows XP, i.e., it has a Windows 95 look. It does not look like that on a modern Windows (controls-wise, not layout-wise).
OTOH, what is in the WinUI3 screenshot is not a dialog: It does not have the caption or buttons. In other words, it is a control (picker), not a dialog. The "dialog" in the screenshot also lacks the features the WinAPI one has so you were comparing apples and oranges.
The "old" feeling is just a feeling, in other words it is subjective. It is all about what is in fashion now, and apparently it is not clean and functional WinAPI design anymore. Now it is a clunky couple-of-shades-of-gray one. I guess it will take a couple of years till the pendulum swings the other way around, just like they perpetually switch between round and sharp browser tab corners.
Nevertheless, it is clear that Microsoft abandoned WinAPI. While they at least added high DPI, I think it is pretty clear by now the controls will not get dark mode support even it if it seems pretty simple to add.
All that said, as I wrote before, among else (e.g, WinUI 3 maturity) I would be worried about the level of Microsoft's commitment to WinUI 3, see their recent history when it comes to that. It is not like we are seeing developers both large and small praising the API and switching their applications to Win UI ASAP.
By the way, creating custom controls may not be as simple as it may seem. It is not only the appearance, one has to worry about proper keyboard and mouse support, RTL, accessibility... Besides that, WPF-looking controls are going to look out of place in WinAPI application.
2021-12-23 20:08:02: TrylzEngine commented
-
I completely disagree. Here the same Dialog under 3.1.3, I dont see that much difference with the Windows 95 look: https://ibb.co/m06Dznj
-
The Winui 3 picker seems to be the direct equivalent to the Win32 one. As the same way the Qt picker would be. I dont see why it is not a valid comparison...
-
Let say we want to have a picker that matches the WinUi 3 one. Couldn't it be done that way:
- Make a frame with child windows.
- Use wxSpinCtrlDouble for the color number inputs.
- Use a child panel for the color selection area. Then intercept mouse down events for the selection. For the drawing, intercept its paint event to draw the color gradient. If the Win Api doesn't expose a way to draw a color gradient, it could be done natively in Directx 11/12 by manually writing the HWND.
- But yes if the WxWidget team is not sure about a WinUI port yet, we wont start working on a port that we could have to maintain ourselves in parallel to the WxWidgets releases.
Thank You!
2021-12-23 22:03:02: @PBfordev commented
Replying to [comment:11 TrylzEngine]:
- I completely disagree. Here the same Dialog under 3.1.3, I dont see that much difference with the Windows 95 look: https://ibb.co/m06Dznj You can disagree with facts, I guess. If you do not believe the dialog is not themed, check the button shape and font used. It is the standard color dialog used in Windows applications such as WordPad even on Windows 10.
Replying to [comment:11 TrylzEngine]:
- The Winui 3 picker seems to be the direct equivalent to the Win32 one. As the same way the Qt picker would be. I dont see why it is not a valid comparison... If you cannot tell a difference between a child control (Microsoft.UI.Xaml.Controls.ColorPicker) and a dialog (wxColourDialog or QColorDialog, these two look pretty much the same) even when it is clear from appearance as well as the class name, I do not know what to tell you...
- Let say we want to have a picker that matches the WinUi 3 one. That would be a trivial task (BTW, wxDC and wxGC do have gradient drawing methods), except for the colored slider which would have to be implemented as a custom control. But that should be simple as well albeit as always, simple still takes time. But the whole dialog should not take more than a day, even if one implements ColorPicker's API quite faithfully.
Replying to [comment:11 TrylzEngine]:
- But yes if the WxWidget team is not sure about a WinUI port yet As I stated before, I am not a developer but I follow the development and I am not aware of any discussion on this topic. As I wrote before, you may need to wait a bit for that.
2021-12-23 22:20:26: TrylzEngine commented
My point was never to discuss the difference between types of windows, but rather to compare the look of color pickers from different platforms. It couldn't be anymore clear than what I wrote.
I will then discuss the port on the dev page.
Thanks for your help!
2021-12-26 00:39:35: @vadz commented
Sorry for the late reply, I'm actually not busy at all, quite on the contrary -- I'm on vacation. I'd be glad to discuss this once I'm back next week, but I can already say that any work on the wxUWP port would be very, very welcome (it's even mentioned as one of the things it would be great to have in our roadmap).
From what little I know about it, it wouldn't be a trivial task, but it should be doable and even if you implement "just" the subset of the wx API that your application needs, it would already be great!
2021-12-26 05:57:55: TrylzEngine commented
Hello Vadz,
Our upcoming release is scheduled in one year. For our UI we mainly want the UWP widgets look and a timeline widget(for animations).
After discussing here it looks like the more secure way to do so would be to implement custom widgets with the look of our choice. We will then go for that solution.
But for the future we will definitely move to UWP, so I will start a branch on the wxUWP platform. It will takes time to implement since i will only work on it on my free time.
From the research i made here is my starting point:
-
See how to generate UWP projects from Cmake. I would use C++/WinRT instead of C++/CX wich looks like another language.
-
UWP application entry point is defined by the application .xaml, .h and .cpp. So a client using wxUWP will have these generated automatically. But he must keep them to the minimal app initialization.
-
UWP events are delegate based, instead of using messages. It should be easy to map these events to the ones of WxWidgets.
Have great holidays!
2021-12-31 11:35:50: @andymrob commented
The OP mentions possibly replacing the Win32 version of wx, so I just thought I'd mention that Win32 is still very much alive, see:
https://docs.microsoft.com/en-us/windows/apps/get-started/?tabs=cpp-win32
"Win32 desktop apps (also sometimes called classic desktop apps) are the original app type for native Windows applications that require direct access to Windows and hardware. This makes this the app type of choice for applications that need the highest level of performance and direct access to system hardware."
and:
https://blogs.windows.com/windowsexperience/2021/06/24/building-a-new-open-microsoft-store-on-windows-11/
"Starting today, Windows developers can publish any kind of app, regardless of app framework and packaging technology – such as Win32, .NET, UWP, Xamarin, Electron, React Native, Java and even Progressive Web Apps."
2021-12-31 12:09:53: @PBfordev commented
Replying to [comment:16 andyr]:
I just thought I'd mention that Win32 is still very much alive, see:
Unfortunately, I cannot agree with this. IMO, the definitive proof is that Microsoft utterly abandoned it is that they did not bother to add support for Dark Mode in Win32.
There is no doubt that Dark Mode is definitely very popular and demanded feature. Yet, Microsoft does not care even enough to make the only Win32 application many users still use daily work right: File Explorer, see the quirks listed on https://trac.wxwidgets.org/ticket/19223#comment:15
Yes, we got high DPI support but when was the last time Microsoft added a new control to Win32 API? I do not think there was any post Windows XP. For example, where are controls such Ribbon or BreadCrumbBar, which have been in common use for a over decade?
But as I wrote before (many times?), I believe that modern Microsoft have bad record when it comes to UI APIs. They have Win32-based MFC and WinForms, which AFAIK are as good as dead, and even their preUWP darling, WPF, seems to be largely ignored. And as I wrote before, I do not see masses migrating to UWP or now the supposedly latest and greatest for C++ programmers, WinUI 3.
Just a thought, instead of creating a new wxWinUI platform with a UWP backend or whatever...can we just use wxPaintEvent or whatever it's called (I don't have experience with it so sorry haha) to create custom styled controls that match WinUI. Similar to how there are libraries for WPF that restyle the controls to match WinUI (https://github.com/Kinnara/ModernWpf & https://github.com/lepoco/wpfui)
Any update on this? I really want apps using cross-platform frameworks like wxWidgets to look modern with Fluent design on Windows.
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.
Either way, you can't use MinGW as your development platform unless MinGW gets WinRT related updates.
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?
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.
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.
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.
I would like to add that mingw support is in their thoughts, see https://github.com/microsoft/WindowsAppSDK/discussions/3532
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!
The project in https://github.com/microsoft/WindowsAppSDK/discussions/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
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 now and 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/
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.