I am not sure if the glacial release schedule these days is a strength (it's stable, there's not much left to do), or a weakness (the project is dying). The various V3.1.x releases all say please use this release for production, even though in theory it's the even number releases that are supposed to be production worthy. Waiting for V3.2.0 (by some measure the right thing to do) would have meant waiting for many years at this point, not sure how many.
I made the decision around 2010, when the landscape was a little different. A key but rather random factor was I'd happened to buy a book on wx, just for interests sake. I liked that wx was straightforwardly open source, whereas qt had various licensing issues and complications (still does). Gtk is really in a different category. Wx sits on gtk on Linux for example.
wxWidgets is a wrapper over the native GUI toolkit. It allows you to write a OS independent GUI code and because it is a wrapper you get most of the benefits of native toolkit like dark mode.
> most of the benefits of native toolkit like dark mode.
On which OS does dark mode work with wx? Certainly not with Windows... (which, as VZ points out, isn't wx's fault, it's just that no APIs officially exist for this - explorer.exe has dark mode, but that uses completely private, undocumented APIs).
Not the person you're asking but here's my take anyway:
I use wx for my own stuff and also use a lot of wx-based applications. Wx is quirky and has some bugs but it's not going to go away or have a massive breaking change without warning. Its biggest weakness is the slow release schedule which leaves users waiting for a long time to access things that are critical on changing platforms (macos is a massive pain to support as the underlying system changes all the damn time). My opinion of it can be summarized as "the worst, except for all the others" so I keep using it.
I keep considering Qt whenever I start a new project and I'm still scared to use it. It's controlled by a company that is in really bad shape financially and has a history of attempting stupid things for short-term profit and screwing over customers. It's reasonable if you can manage with either just the LGPL components or if your entire project is GPL, but if not their license terms are really terrible and get worse and worse over time. They keep making changes that fuck over their paying customers. I don't feel good about using this at the moment. The KDE people have thankfully got that company by the balls with a watertight contract, and I totally trust the KDE people, but there's still plenty of damage the company can do, and every sign they will. It's really unfortunate because Qt is otherwise an excellent platform.
Multiplatform gtk is a pain. There are a few projects that successfully pull it off (Horizon EDA is a notable example) but I don't think I could manage it myself.
If you're doing a new thing you might want to consider one of the many imgui implementations (as you seem to be thinking in that direction already).
Ah indeed, I am one of those painful macOS users.. the carelessness with which the mother company changes and/or breaks API's overnight still boggles my mind.
It's funny, I have some experience with Swing, from work, and I kind of like it, API-wise, so I toyed with the idea of JNI'ing my way around it... but it seems such a ridiculous thing to do for a super-simple GUI. Plus missing the chance of actually learning a 'native' (native as in code) GUI toolkit.
I remember playing with Qt (many) years ago and making a mental note to get back to it but a 2020 revisit turned into an exercise in frustration, couldn't get it to build anything (very likely to blame on my ageing XCode installation rather than the Qt SDK). But as you point out, licensing issues & overall maker's attitude need to be considered too.
The imgui's are quite neat. I like the fact that building one of the demo's (with an impressive array of widgets) sort of 'just worked.' That's impressive, these days!
> Ah indeed, I am one of those painful macOS users.. the carelessness with which the mother company changes and/or breaks API's overnight still boggles my mind
I suppose that's one of the reasons why Electron is so popular these days. If MacOS is constantly changing its APIs, that Microsoft can't seem to decide between classic Win32 and Modern UI, Linux that is split between Qt and GTK, plus all the mess on the mobile side.
Because OSes can't provide a consistent API, app ship with their their own OS! (a browser today is essentially an OS on top of an OS).
> Because OSes can't provide a consistent API, app ship with their their own OS! (a browser today is essentially an OS on top of an OS).
This.
Even when targeting a single platform the developer may very well choose to use one of these frameworks just to avoid having to deal with the most horrible parts of the platform in question (and GUI's tend to be those parts.)
I've been a wxWidgets dev for about 8 years now, and about a year ago I tried moving to ImGUI. The problem with ImGUI is it's necessity to constantly re-render, like a game engine. If one's application is already high-compute, using ImGUI is death to performance.
One key difference between wxWidgets and Qt or GTK is that wxWidgets, as far as I know, uses native controls to create the UI, unlike Qt or GTK which draw everything themselves. Qt is really good at imitating a native feeling but wxWidgets provides a real native UX.
Having said that, for my Python projects, I am currently using Qt via PySide2 since that one worked without any problems with a simple pip installation while the other 2 gave some errors (I tried them about 2 years ago, maybe they work better now).
Another reason I currently use Qt is because I needed to do a lot of drawing and interact with these drawings on a canvas and Qt has QGraphicsView widget which is a really capable canvas widget where you can easily do transformations, interactivity with good performance and it also has a good documentation. GTK didn't have such a widget out of the box, I didn't look at wxWidgets, though, maybe that one has.
But only the old school Windows style right? I still don't get the argument because Windows itself now has like 3 different styles for their system apps themselves. There is not the "one" native style.
This whole area has got so muddied with Microsoft going beserk after Windows 8, the shift to the web, mass use of Electron and Apple bringing iPhone/iPad apps to macos.
It's quite sad really because none of it was changed in the name of users interest.
That is indeed true. wxWidgets currently has the old school Win32 style. I think WPF uses different set of controls (but I am not 100% sure). And UWP has a totally different look and feel.
Those are the true native style for Windows, yes. Microsoft's subsequent efforts aren't as good and they've not even fully committed to them themselves. WPF is on life support.
From Microsoft offerings for C++ devs, just keep using MFC, or in your case wxWidgets.
They will mention WinUI, but the team pushing for C++/WinRT killed all VS tooling support that C++/CX, so for doing WinUI with C++ you are stuck editing IDL files without any kind of VS tooling support, and also have to copy/merge the generated C++ files of the IDL ones.
I basically agree with pjmlp: Win32/MFC has always worked and will continue to work.
> in C# land WinForms was discouraged
Portability, it seems. Not unreasonably, they're focusing on C# as a backend language in UNIX-like environments. While you can run WinForms from dotnet core, doing so adds a large chunk of libraries to your deployment and of course only works on Windows targets. I'm not sure I entirely approve of this direction, but it follows from targeting Java, and I do prefer C# to Java.
Of course, if you just want a little bit of the API, there's nothing stopping you from just p/invoking it out of user32.dll, which I did last month ...
That is what WinUI team would wish, but given that currently with version 3.0:
- Only C# and C++/WinRT apps are supported
- Desktop apps support .NET 5 and C# 9, and must be packaged in an MSIX app
- No XAML Designer support
- New C++/CX apps are not supported, however, your existing apps will continue to function (please move to C++/WinRT as soon as possible)
- Unpackaged desktop deployment is not supported
- When running a desktop app using F5, make sure that you are running the packaging project. Hitting F5 on the app project will run an unpackaged app, which WinUI 3 does not yet support.
> One key difference between wxWidgets and Qt or GTK is that wxWidgets, as far as I know, uses native controls to create the UI, unlike Qt or GTK which draw everything themselves. Qt is really good at imitating a native feeling but wxWidgets provides a real native UX.
This is kind of a strawman, especially with wxPython. The basic widgets are native (like e.g. a button, text input, checkbox, combobox), yes, but most of the "advanced" widgets aren't (e.g. AUI, list and tree controls, which are not native on Gtk, dataview, propgrid, ...), and everything in wx.lib isn't (avoid wx.lib.agw btw.). Most of the latter category has no or limited support for Hi-DPI. Most of the latter neither feels nor looks native, to varying degrees.
Personally I find my opinion of wx has sort of evolved like an inverted parabola. It started off kinda low, because a lot of stuff has confusing names, things are done in mildly weird ways and stuff like the layout system works in mysterious ways. It reached a high point at "this is pretty ok". Kinda went downhill from there: the layout system is just a massive pita, basic things seem to be missing because they're basically not doable with that layout system (e.g. notice how there really isn't anything in wx which provides an automatically line-wrapping text/label widget), support for rich-text/HTML/markup is abysmal, the event system is a PITA, most of the advanced widgets have are barely usable from both a programmer's and a a user's point of view (wxPropertyGrid...), there is a distinct lack of APIs for system integration (try putting or getting HTML from/to the clipboard, which is a one-liner with Qt), somehow not-flicker-free drawing is still a thing in wx, and it is not taken to be granted, the menu system is the thinnest of wrappers around the lowest of common denominators; QAction/QMenu is a far superior system of interactions. There is a pattern to this; wx generally chooses to make something a "thin wrapper over lcd". Qt generally chooses to rather make a stable abstraction (works on OS 1, probably works on OS 2), and, well, abstract. Qt has Model/View, which can be a little intimidating if you use it for the first time, but it actually works really well. wx has
wxListCtrl::OnGetItemText (it also has dataview since a few versions, which is in the odd place of "way more complicated than a callback, not nearly as good as Qt MV"). Qt has QAction, wx has... wxMenu::Append. wx's way of doing things definitely has advantages (for one thing, wx is far, far less code than Qt Widgets, and if the controls you are using are native, everything truly is native, though this arguably doesn't matter any more).
FWIW I probably struggled more with layouts in a single wx project in a few months than I've done in all Qt and web experience prior to that. There are just so many weird happenings which just... don't exist outside wx.
I can't say much for wxPython lib, but fixing high DPI support in native controls is the main focus of 3.2.0 and things look pretty good in 3.1.5 already IMHO.
I could understand if you wrote that the layout system is not powerful enough because it's too _simple_ -- it's really just a combination of 1D box layout and 2D grid layout that can be composed -- but I really don't know what could possibly be so weird about it.
Markup support is indeed simple because we don't want to write and maintain our own CSS parser or anything like this, but you can use wxWebView to have all the browser power at your fingertips.
Putting HTML into clipboard is a one liner with wx too (just use wxHTMLDataObject as any other data object).
More could be said about the other subjects, but these ones just seem like very obvious misconceptions, so I'd like to at least leave a record here to prevent the parent post from leaving a wrong impression.
Let me just say, you're doing a superb job with wxWidgets. Having learned and used an uncounted number of UI toolkits, wxWidgets is the least irritating I've used in a 40 year coding career. Standing ovation to you, sir.
> I can't say much for wxPython lib, but fixing high DPI support in native controls is the main focus of 3.2.0 and things look pretty good in 3.1.5 already IMHO.
Yes, the wx core handles this really well. If the correct APIs are used, no or few changes to application code are necessary to handle HiDPI properly - definitely a very good aspect of wx.
> I could understand if you wrote that the layout system is not powerful enough because it's too _simple_ -- it's really just a combination of 1D box layout and 2D grid layout that can be composed -- but I really don't know what could possibly be so weird about it.
For me it remains unclear how the various sizes (MinSize, Size, BestSize and the size passed to the constructor/Create) interact with the sizer's decisions. From what I've seen a BestSize seems to more or less be treated like a MinSize, where the sizer will not continue to shrink a control if Size == BestSize.
How to correctly implement a re-flowing (where e.g. the width depends on the height, or vice versa) control is also unclear to me. wxTextCtrl does it, somehow, in a somewhat buggy way. I managed to do it but I doubt it's correct.
What I personally find weird is how sizers don't really compose - you can put sizers in sizers, but that's not what I mean: If the layout changes in a sub-sub-sub-panel, then just calling Layout() there won't usually be sufficient, you have to walk up the tree. In Qt for example I've never spend a single thought about what would change the layout and how or what needs to receive Layout calls, it's just 100 % automatic.
A combination of both of these is that I found wxScrolledWindow to be very tricky to get to work properly, even after spending a lot of time on it, I still end up with a dialog that takes a few frames to stop redrawing/changing its layout.
Another weird corner is wxCollapsiblePane.
I concede that a lot of this could be because I don't know enough about wx or because I'm too dense to understand it properly.
> Putting HTML into clipboard is a one liner with wx too (just use wxHTMLDataObject as any other data object).
Thanks, that set me on the right track to work it out. Previously I only found extremely weird/convoluted solutions and older posts suggesting that wx doesn't do it for you (google: "wx clipboard html"). But wxDataObjectComposite with a wxHTMLDataObject and wxTextDataObject indeed "just works". Perhaps something for the docs as an example?
> Markup support is indeed simple because we don't want to write and maintain our own CSS parser or anything like this, but you can use wxWebView to have all the browser power at your fingertips.
Well yeah, but a WebView is a pretty heavy-handed approach if you just want to make a few words bold or insert a link or something like that. Also, Qt's approach works more universally (e.g. it also applies to the labels of check/radio boxes, buttons etc., and it also lets you do things like highlight a field in red when it contains an invalid input, like people are used to nowadays).
Best size is determined by each window. Min size is best size by default, but can be set to something different to override it. And the initial size is also min size by default, because this is what you'd expect: if you create a text entry wide enough for 50 characters, you don't want it to shrink to its best size which would be smaller. Generally speaking, it's best to avoid hardcoding any sizers (and definitely never use sizes in pixels).
For the relayout, the general principle is that it _always_ flows from top to bottom, i.e. changing anything for a child will _never_ affect the size of a (grand) parent. So you just need to call Layout() on the top-most window whose size you want to allow changing. Again, this might be too simple, perhaps, but at least it is simple and 100% consistent (well, wxCollapsiblePane just might be one of the very few exceptions...). I'm not sure how does Qt manage to avoid confusion if it propagates layout changes in both directions.
For markup, we do support it in wxGenericStaticText and several other controls, including buttons, checkboxes and wxDataViewCtrl which is quite enough for simple things like this. wxHtmlWindow is pretty nice for slightly more complicated stuff, even though it's just HTML 3.
Converse to this, I find the layout manager really useful and easy. wxSizer is easy to understand. Want something to expand? Use wxEXPAND. Use proportion 1 to make it take up all the space.
Use wxFormBuilder if you find laying stuff out difficult.
I find the layout manager easier than Borland or MFC codebases I have had to use, that's for sure!
> Isn’t GTK basically _the_ native controls of Linux?
Depends on the desktop environment. If you use GNOME or Xfce then yes, your native toolkit is GTK. As someone pointed out over here [0], if you use KDE then your native toolkit is Qt.
(Posted from Kubuntu, incidentally. KDE is impressively polished these days.)
My pet peeve: I live on KDE, yet nobody considers Qt native!
More important to me is accessibility. Does the toolkit integrate with the OS such that users can use their accessibility tools? I don't know about wx, but not all crossplatform toolkits do this consistently (or at all).
Something is alien somewhere, and as others noted, for Windows specifically I couldn't tell you what native is. On Linux there's just GTK and Qt, but the count is far higher on Windows these days. I have a Qt app that blends in imperceptibly well in my eyes, while some of MS own software stands out.
QGraphicsView in particular is fantastic, it's the main reason I picked PySide for my app, but overall I've been very impressed with the polish of Qt and the quality of the documentation.
I did a couple of commercial programs with it back when Qt was charging for a licence. In the end I wish I had stumped up the money for Qt as I had a lot of problems with wx.
> The various V3.1.x releases all say please use this release for production, even though in theory it's the even number releases that are supposed to be production worthy.
V3.1.x is 5 years old now and it looks like they’re using semver for at least v3 releases. So I wouldn’t worry about this being an odd numbered release.
It's neither a strength (there are definitely tons of things to do) but nor is it much of a weakness because the development is quite active pretty much all the time (just look at the commit history, PR merge rate or whatever).
The main problem with 3.2.0 is that, due to our commitment to ABI compatibility for even-numbered releases, we really want to cram as many new APIs into it as possible and this keeps pushing it further and further away. If nothing catastrophic happens, it should finally be released this autumn, whether we manage to finish all the planned features (see https://trac.wxwidgets.org/wiki/Roadmap) or not, but in the meanwhile you really shouldn't hesitate to use 3.1.x, the only unstable part of it is the ABI (_not_ API).
Nice chess GUI, BTW! (although I admit that I spend what little time I have for chess exclusively on Lichess nowadays).
Thank you for the incredible effort you have put into wxWidgets over many years. If you go to Help > Credits you will see you get a credit within the Tarrasch program. Yes, you are right, Lichess is fabulous. There are still some things I much prefer to do in Tarrasch though :-)
I recently-ish upgraded an app's (Slippi) wxWidgets base to 3.1.4, which led me into a somewhat deep dive of wxWidgets since the Dolphin build it was forked from had an "Externals" version that was somewhat of a custom setup. Needless to say I have a renewed appreciation for the amount of work that went into (and still goes into) wxWidgets. It's just absurd how well it covers the "big 3" desktop environments.
I think it probably gets a bad rep when compared to "modern" UI development frameworks, however this thing is still trucking along all these years later. I'm not sure I'll need to touch 3.1.5, but it's just really cool to see it still being worked on.
I think the biggest thing the project needs though though is... documentation. Or maybe it has it, but needs some serious SEO work to make it better accessible? So much of my time was spent trying to figure out what specific feature flags meant, whether they were still valid, and so on. I've done Cocoa development for years, so I'm used to outdated/old documentation, but with wxWidgets it just felt... harder to find the right stuff. Maybe because the userbase is smaller in comparison?
FWIW updating from 3.1.4 to 3.1.5 (and then to 3.2.0) should be pretty seamless.
The documentation does need work, but it's hard to find people volunteering to do it (although a few people do contribute to the docs too and this is something that is always very much appreciated). Any concrete suggestions for improvements are welcome as reports on https://trac.wxwidgets.org/newticket and, as you might have already realized by now, PRs to the docs on https://github.com/wxWidgets/wxWidgets/pulls are even more so.
Finally, asking questions (on the forum, users mailing list or SO) seems to work pretty well for most people.
Cool to know re: 3.1.5, but I don't think I'll need to dig into it as Dolphin upstream moved to Qt, and eventually, hopefully, Slippi just mirrors that.
And yeah, I hear you on the people issue... open source is sometimes a thankless job. Overall though, great job on wxWidgets so far - I really do think it's an underappreciated project.
I find the documentation fairly easy to follow and well written. I leave the class index open in a web browser, pinned.
The great thing is you can just look at the source if there's any confusion. One issue is the mildly broken nature of the macOS version (odd bugs now and then) but that's because Apple keeps changing things. It is significantly better than it was 5 years ago!
Try reading other documentation like MFC and you'll appreciate the wxWidgets documentation...
Eeeehhh I'm gonna disagree - most open source macOS projects have those bugs because it lacks the resources/dev-power to keep up. Windows and Linux in comparison tend to have much more in the way of developers willing to contribute.
Cocoa/AppKit rarely change, and it's often one of the bigger complaints with it. Big Sur is probably the most radical version change set in years, but to say Apple "keeps changing things" for Cocoa/AppKit is not really correct.
Also, if it's not clear, I _do_ read other documentation. I still think wxWidgets needs work, and one of the devs even admitted as much in their response to me.
If only they had usable C bindings so it could be used from more languages. Such a shame. Making it possible to use from Rust, Nim, Go would really give it a second wind of users.
Be the change you want to be! wxC did exist but grew unmaintained, split into several variants (I think at least wxHaskell and wxErlang had their own versions) and withered. It shouldn't be that difficult to revive it but, well, somebody does need to do it.
It's a bit funny that people don't realize that "they" are "you". wxWidgets is an old school open source project, people are supposed to contribute to it because they have their own itch to scratch.
FWIW wx has always been very friendly to new contributors, so I'd really encourage people who are annoyed by something in it to just propose changing them on wx-dev.
Last time I used wxWidgets, more than 10 years ago, the API felt very dated and clumsy compared to Qt for example. Do people still use wxWidgets for new deployment?
Idem. I developed quite a number of desktop apps in a professional environment using wxPython. I found easy to quickly prototype new ideas. Also, you have access to the rich python ecosystem that other solutions for producing desktop apps won't have.
I found the API to be usable although the event system is bit limited in my opinion.
I even chosen it to develop a commercial app in c++(https://seamuove.com) mainly because I knew the API. Bonus is that you can produce small single exe using static linking.
I currently maintain an app that uses wxPython and it still feels dated and clumsy. Everything is named poorly, the documentation has large gaps, and there are numerous pitfalls and gotchas. I am in the process of moving to PySide and will not be considering wxWidgets for any future projects.
I think wxWidgets is fantastic. I use it in my CMake project. I have a git submodule with the wxWidgets source. I just set the options I want and add_subdirectory(). I statically link it it into my binary for easy distribution, because the license is more permissive than LGPL in that regard. Thanks to the wxWidgets collaborators for all their hard work!
61 comments
[ 2.1 ms ] story [ 110 ms ] threadI am not sure if the glacial release schedule these days is a strength (it's stable, there's not much left to do), or a weakness (the project is dying). The various V3.1.x releases all say please use this release for production, even though in theory it's the even number releases that are supposed to be production worthy. Waiting for V3.2.0 (by some measure the right thing to do) would have meant waiting for many years at this point, not sure how many.
((Looking into GUI toolkits for a side project, I was thinking about one of the SDL-based ones but really unsure now))
On which OS does dark mode work with wx? Certainly not with Windows... (which, as VZ points out, isn't wx's fault, it's just that no APIs officially exist for this - explorer.exe has dark mode, but that uses completely private, undocumented APIs).
I use wx for my own stuff and also use a lot of wx-based applications. Wx is quirky and has some bugs but it's not going to go away or have a massive breaking change without warning. Its biggest weakness is the slow release schedule which leaves users waiting for a long time to access things that are critical on changing platforms (macos is a massive pain to support as the underlying system changes all the damn time). My opinion of it can be summarized as "the worst, except for all the others" so I keep using it.
I keep considering Qt whenever I start a new project and I'm still scared to use it. It's controlled by a company that is in really bad shape financially and has a history of attempting stupid things for short-term profit and screwing over customers. It's reasonable if you can manage with either just the LGPL components or if your entire project is GPL, but if not their license terms are really terrible and get worse and worse over time. They keep making changes that fuck over their paying customers. I don't feel good about using this at the moment. The KDE people have thankfully got that company by the balls with a watertight contract, and I totally trust the KDE people, but there's still plenty of damage the company can do, and every sign they will. It's really unfortunate because Qt is otherwise an excellent platform.
Multiplatform gtk is a pain. There are a few projects that successfully pull it off (Horizon EDA is a notable example) but I don't think I could manage it myself.
If you're doing a new thing you might want to consider one of the many imgui implementations (as you seem to be thinking in that direction already).
The imgui's are quite neat. I like the fact that building one of the demo's (with an impressive array of widgets) sort of 'just worked.' That's impressive, these days!
I suppose that's one of the reasons why Electron is so popular these days. If MacOS is constantly changing its APIs, that Microsoft can't seem to decide between classic Win32 and Modern UI, Linux that is split between Qt and GTK, plus all the mess on the mobile side.
Because OSes can't provide a consistent API, app ship with their their own OS! (a browser today is essentially an OS on top of an OS).
This. Even when targeting a single platform the developer may very well choose to use one of these frameworks just to avoid having to deal with the most horrible parts of the platform in question (and GUI's tend to be those parts.)
I mean, we can bitch as much as we want on what TQTC is doing with the open-source license mess, but their stock went from 8$ in 2018 to 100$ ...
http://www.nasdaqomxnordic.com/aktier/microsite?Instrument=H...
They acquired froglogic a couple days ago:
https://sdtimes.com/softwaredev/sd-times-news-digest-qt-acqu...
Having said that, for my Python projects, I am currently using Qt via PySide2 since that one worked without any problems with a simple pip installation while the other 2 gave some errors (I tried them about 2 years ago, maybe they work better now).
Another reason I currently use Qt is because I needed to do a lot of drawing and interact with these drawings on a canvas and Qt has QGraphicsView widget which is a really capable canvas widget where you can easily do transformations, interactivity with good performance and it also has a good documentation. GTK didn't have such a widget out of the box, I didn't look at wxWidgets, though, maybe that one has.
But only the old school Windows style right? I still don't get the argument because Windows itself now has like 3 different styles for their system apps themselves. There is not the "one" native style.
It's quite sad really because none of it was changed in the name of users interest.
I know in C# land WinForms was discouraged (no idea why) but what do they recommend now??
What is the "native" toolkit for modern C++ apps on Windows? I end up using wxWidgets because it is easy.
They will mention WinUI, but the team pushing for C++/WinRT killed all VS tooling support that C++/CX, so for doing WinUI with C++ you are stuck editing IDL files without any kind of VS tooling support, and also have to copy/merge the generated C++ files of the IDL ones.
> in C# land WinForms was discouraged
Portability, it seems. Not unreasonably, they're focusing on C# as a backend language in UNIX-like environments. While you can run WinForms from dotnet core, doing so adds a large chunk of libraries to your deployment and of course only works on Windows targets. I'm not sure I entirely approve of this direction, but it follows from targeting Java, and I do prefer C# to Java.
Of course, if you just want a little bit of the API, there's nothing stopping you from just p/invoking it out of user32.dll, which I did last month ...
Sounds like the direction Java took, moving JavaFX (a rather underrated GUI toolkit from what I can tell) out of the core Java standard library.
- Only C# and C++/WinRT apps are supported
- Desktop apps support .NET 5 and C# 9, and must be packaged in an MSIX app
- No XAML Designer support
- New C++/CX apps are not supported, however, your existing apps will continue to function (please move to C++/WinRT as soon as possible)
- Unpackaged desktop deployment is not supported
- When running a desktop app using F5, make sure that you are running the packaging project. Hitting F5 on the app project will run an unpackaged app, which WinUI 3 does not yet support.
-- https://docs.microsoft.com/en-us/windows/apps/winui/winui3/
Most of long time UWP belivers just packed our stuff and are back in WPF/Win32 land.
This is kind of a strawman, especially with wxPython. The basic widgets are native (like e.g. a button, text input, checkbox, combobox), yes, but most of the "advanced" widgets aren't (e.g. AUI, list and tree controls, which are not native on Gtk, dataview, propgrid, ...), and everything in wx.lib isn't (avoid wx.lib.agw btw.). Most of the latter category has no or limited support for Hi-DPI. Most of the latter neither feels nor looks native, to varying degrees.
Personally I find my opinion of wx has sort of evolved like an inverted parabola. It started off kinda low, because a lot of stuff has confusing names, things are done in mildly weird ways and stuff like the layout system works in mysterious ways. It reached a high point at "this is pretty ok". Kinda went downhill from there: the layout system is just a massive pita, basic things seem to be missing because they're basically not doable with that layout system (e.g. notice how there really isn't anything in wx which provides an automatically line-wrapping text/label widget), support for rich-text/HTML/markup is abysmal, the event system is a PITA, most of the advanced widgets have are barely usable from both a programmer's and a a user's point of view (wxPropertyGrid...), there is a distinct lack of APIs for system integration (try putting or getting HTML from/to the clipboard, which is a one-liner with Qt), somehow not-flicker-free drawing is still a thing in wx, and it is not taken to be granted, the menu system is the thinnest of wrappers around the lowest of common denominators; QAction/QMenu is a far superior system of interactions. There is a pattern to this; wx generally chooses to make something a "thin wrapper over lcd". Qt generally chooses to rather make a stable abstraction (works on OS 1, probably works on OS 2), and, well, abstract. Qt has Model/View, which can be a little intimidating if you use it for the first time, but it actually works really well. wx has wxListCtrl::OnGetItemText (it also has dataview since a few versions, which is in the odd place of "way more complicated than a callback, not nearly as good as Qt MV"). Qt has QAction, wx has... wxMenu::Append. wx's way of doing things definitely has advantages (for one thing, wx is far, far less code than Qt Widgets, and if the controls you are using are native, everything truly is native, though this arguably doesn't matter any more).
FWIW I probably struggled more with layouts in a single wx project in a few months than I've done in all Qt and web experience prior to that. There are just so many weird happenings which just... don't exist outside wx.
I could understand if you wrote that the layout system is not powerful enough because it's too _simple_ -- it's really just a combination of 1D box layout and 2D grid layout that can be composed -- but I really don't know what could possibly be so weird about it.
Markup support is indeed simple because we don't want to write and maintain our own CSS parser or anything like this, but you can use wxWebView to have all the browser power at your fingertips.
Putting HTML into clipboard is a one liner with wx too (just use wxHTMLDataObject as any other data object).
More could be said about the other subjects, but these ones just seem like very obvious misconceptions, so I'd like to at least leave a record here to prevent the parent post from leaving a wrong impression.
Yes, the wx core handles this really well. If the correct APIs are used, no or few changes to application code are necessary to handle HiDPI properly - definitely a very good aspect of wx.
> I could understand if you wrote that the layout system is not powerful enough because it's too _simple_ -- it's really just a combination of 1D box layout and 2D grid layout that can be composed -- but I really don't know what could possibly be so weird about it.
For me it remains unclear how the various sizes (MinSize, Size, BestSize and the size passed to the constructor/Create) interact with the sizer's decisions. From what I've seen a BestSize seems to more or less be treated like a MinSize, where the sizer will not continue to shrink a control if Size == BestSize.
How to correctly implement a re-flowing (where e.g. the width depends on the height, or vice versa) control is also unclear to me. wxTextCtrl does it, somehow, in a somewhat buggy way. I managed to do it but I doubt it's correct.
What I personally find weird is how sizers don't really compose - you can put sizers in sizers, but that's not what I mean: If the layout changes in a sub-sub-sub-panel, then just calling Layout() there won't usually be sufficient, you have to walk up the tree. In Qt for example I've never spend a single thought about what would change the layout and how or what needs to receive Layout calls, it's just 100 % automatic.
A combination of both of these is that I found wxScrolledWindow to be very tricky to get to work properly, even after spending a lot of time on it, I still end up with a dialog that takes a few frames to stop redrawing/changing its layout.
Another weird corner is wxCollapsiblePane.
I concede that a lot of this could be because I don't know enough about wx or because I'm too dense to understand it properly.
> Putting HTML into clipboard is a one liner with wx too (just use wxHTMLDataObject as any other data object).
Thanks, that set me on the right track to work it out. Previously I only found extremely weird/convoluted solutions and older posts suggesting that wx doesn't do it for you (google: "wx clipboard html"). But wxDataObjectComposite with a wxHTMLDataObject and wxTextDataObject indeed "just works". Perhaps something for the docs as an example?
> Markup support is indeed simple because we don't want to write and maintain our own CSS parser or anything like this, but you can use wxWebView to have all the browser power at your fingertips.
Well yeah, but a WebView is a pretty heavy-handed approach if you just want to make a few words bold or insert a link or something like that. Also, Qt's approach works more universally (e.g. it also applies to the labels of check/radio boxes, buttons etc., and it also lets you do things like highlight a field in red when it contains an invalid input, like people are used to nowadays).
For the relayout, the general principle is that it _always_ flows from top to bottom, i.e. changing anything for a child will _never_ affect the size of a (grand) parent. So you just need to call Layout() on the top-most window whose size you want to allow changing. Again, this might be too simple, perhaps, but at least it is simple and 100% consistent (well, wxCollapsiblePane just might be one of the very few exceptions...). I'm not sure how does Qt manage to avoid confusion if it propagates layout changes in both directions.
For markup, we do support it in wxGenericStaticText and several other controls, including buttons, checkboxes and wxDataViewCtrl which is quite enough for simple things like this. wxHtmlWindow is pretty nice for slightly more complicated stuff, even though it's just HTML 3.
Use wxFormBuilder if you find laying stuff out difficult.
I find the layout manager easier than Borland or MFC codebases I have had to use, that's for sure!
Depends on the desktop environment. If you use GNOME or Xfce then yes, your native toolkit is GTK. As someone pointed out over here [0], if you use KDE then your native toolkit is Qt.
(Posted from Kubuntu, incidentally. KDE is impressively polished these days.)
[0] https://news.ycombinator.com/item?id=26818328
More important to me is accessibility. Does the toolkit integrate with the OS such that users can use their accessibility tools? I don't know about wx, but not all crossplatform toolkits do this consistently (or at all).
Point is: there is no such thing as native.
Xamarin could be a viable choice as well.
https://www.softpedia.com/get/Others/Miscellaneous/Chess-Tim...
It was many, many years ago, wayy before 2015. Not sure when. Don't have the source code.
Now there appears to be a "cracked" version on some Russian site..which is strange because I don't remember putting any kind of copy protection.
So either I totally forgot about the copy protection or someone is using my program for malware or something.
V3.1.x is 5 years old now and it looks like they’re using semver for at least v3 releases. So I wouldn’t worry about this being an odd numbered release.
https://semver.org/
The main problem with 3.2.0 is that, due to our commitment to ABI compatibility for even-numbered releases, we really want to cram as many new APIs into it as possible and this keeps pushing it further and further away. If nothing catastrophic happens, it should finally be released this autumn, whether we manage to finish all the planned features (see https://trac.wxwidgets.org/wiki/Roadmap) or not, but in the meanwhile you really shouldn't hesitate to use 3.1.x, the only unstable part of it is the ABI (_not_ API).
Nice chess GUI, BTW! (although I admit that I spend what little time I have for chess exclusively on Lichess nowadays).
I think it probably gets a bad rep when compared to "modern" UI development frameworks, however this thing is still trucking along all these years later. I'm not sure I'll need to touch 3.1.5, but it's just really cool to see it still being worked on.
I think the biggest thing the project needs though though is... documentation. Or maybe it has it, but needs some serious SEO work to make it better accessible? So much of my time was spent trying to figure out what specific feature flags meant, whether they were still valid, and so on. I've done Cocoa development for years, so I'm used to outdated/old documentation, but with wxWidgets it just felt... harder to find the right stuff. Maybe because the userbase is smaller in comparison?
The documentation does need work, but it's hard to find people volunteering to do it (although a few people do contribute to the docs too and this is something that is always very much appreciated). Any concrete suggestions for improvements are welcome as reports on https://trac.wxwidgets.org/newticket and, as you might have already realized by now, PRs to the docs on https://github.com/wxWidgets/wxWidgets/pulls are even more so.
Finally, asking questions (on the forum, users mailing list or SO) seems to work pretty well for most people.
And yeah, I hear you on the people issue... open source is sometimes a thankless job. Overall though, great job on wxWidgets so far - I really do think it's an underappreciated project.
The great thing is you can just look at the source if there's any confusion. One issue is the mildly broken nature of the macOS version (odd bugs now and then) but that's because Apple keeps changing things. It is significantly better than it was 5 years ago!
Try reading other documentation like MFC and you'll appreciate the wxWidgets documentation...
Cocoa/AppKit rarely change, and it's often one of the bigger complaints with it. Big Sur is probably the most radical version change set in years, but to say Apple "keeps changing things" for Cocoa/AppKit is not really correct.
Also, if it's not clear, I _do_ read other documentation. I still think wxWidgets needs work, and one of the devs even admitted as much in their response to me.
It's a bit funny that people don't realize that "they" are "you". wxWidgets is an old school open source project, people are supposed to contribute to it because they have their own itch to scratch.
FWIW wx has always been very friendly to new contributors, so I'd really encourage people who are annoyed by something in it to just propose changing them on wx-dev.
Quick prototyping with Python and wx would be my typical use-case.
I found the API to be usable although the event system is bit limited in my opinion.
I even chosen it to develop a commercial app in c++(https://seamuove.com) mainly because I knew the API. Bonus is that you can produce small single exe using static linking.
Overall thanks for the effort dear wx team!