I used this 15+ years ago with C++, it was so much easier to do cross platform things that way and it had good performance. Now I think I have not worked on a native desktop app on at least 10 years. And everything I see others make is more hybrid, javascript, electron kind of things. The performance of that even though we have much faster hardware feels worse than what WxWidgets / C++ did 15 years ago...
I wrote a (simple) accounting/billing application for my inlaws' shop some 20 years ago wih wxWidgets. I developed it on a mac, but it ran on a PC. The PC was very modest even back then (some 486, at best), but the application ran like lightning.
The same for a MS-DOS Clipper [1] application written 30 years ago. Sorry, with all due respect to the wxWidgets contributors, aesthetically wxWidgets (like many other UI libs) is not for 2022.
Users care a lot less about looks than designers and PMs (seem to) wish they did.
They like consistent, reliable, fast operation. Especially those first two things.
The things that make them most unhappy are: 1) programs that behave unpredictably—a predictable, consistent bug that happens every single time is preferable to an operation that fails 5% of the time, randomly, or a button that fails to register about half of all clicks, or anything like that and 2) changes to an interface they've already learned—because your new thing probably isn't 1/10 as "intuitive" as you think it is, so it's just another annoying arbitrary thing they have to deal with for no good reason, when they already had the last annoying, arbitrary thing figured out.
Now, where it might make a difference (maybe—but I'm skeptical) is screenshots on sales pages. Which I suppose is why design continues to be so anti-user.
> aesthetically wxWidgets (like many other UI libs) is not for 2022
wxWidgets applications are supposed to look native on every platform... what's the issue? Personally, I find apps with weird GUIs that don't look at all like the rest of the system very irritating. I would prefer developers to spend more time implementing features, and less making bling-bling UI things.
> I would prefer developers to spend more time implementing features, and less making bling-bling UI things.
So many apps twenty years ago had features that apps today do not. It was really frustrating to see instant messaging services regress in features as people migrated from one to another to a third to ... today's dumpster fires.
A serious question: what are native controls on Windows? Is the Windows XP era where each control is its own HWND (and usually drawn with GDI+)? Is it Windows 7 era where the drawing is Direct2D? Windows 8 where the elements of the app come together with DirectComposition? Or maybe Windows 10 style which is an evolution of UWP (now rebranded WinUI), with drawing in Win2D?
For lightweight utilities, I think the user32 controls (HWND per control, drawn with GDI) are still a reasonable choice. That's the one GUI toolkit that's guaranteed to already be in the working set on all versions of Windows, thus minimizing the impact on startup time and memory footprint. Do those controls just look hideous to modern users? I obviously can't judge that for myself. Or is there a problem with the way they render text on high-DPI displays?
It used to be they didn't render high-dpi text correctly, but fixes went in for that. Even so, it's a hack and often not pixel perfect. If you're trying to do visually sophisticated things (soft shadows, fading animations), GDI+ is inadequate. So basically it looks antiquated. It might be fine for simple form-like programs.
My main point is that "native" covers a lot of ground, and "native legacy compatibility" and "native modern" are radically different technology stacks on Windows.
The HWND-based ones that come with Windows would be the native controls as this is how the underlying window system works. The WPF/UWP/etc UI stacks are built on top of HWND stuff pretty much the same way as Java Swing or JavaFX were made that largely (especially the latter) ignore the underlying window system.
Of course since they come with the OS you might as well use those instead of bundling a separate UI toolkit, but IMO if you consider them as native as the HWND stuff then might as well consider everything native - AFAIK Windows even comes with a shared Electron/Chromium instance applications can use so in that case you could say anything that uses Electron is native on Windows :-P.
UWP is most definitely not HWND per control, and doing so would be incredibly limiting. I don't know the UWP (WinUI) internals, but on mac it's generally a CALayer per widget, and Core Animation is doing the compositing. On Windows, the Windows 8 equivalent is DirectComposition, but I think the WinRT Windows.UI.Composition interface has some capabilities not exposed through winapi.
It isn't HWND per control indeed, it does its own composition, hence why i mentioned Swing and JavaFX with an "especially the latter" in parentheses (but Swing also does bypass the underlying window system aside from the toplevel stuff for per-control functionality whenever that'd make sense).
I was an active user until 2 years ago, when I quit my last enterprise software job. They had a cross platform (including embedded systems) enterprise video security system, a suite of applications all written in wxWidgets. They screamed, they were so fast. They had to be, for our enterprise clients. But those same clients had typical "give me candy" managers, and they complained about the ancient native interface. That company chose to ditch wxWidgets, put everything behind a server I wrote, and then hire some over priced web agency to make them a web interface they charged 4 times the expense of the development entire enterprise software suite.
Lunacy. Change looks like progress to some people. And doubly so if it looks like all web UIs these days - loads of padding, giant buttons, and really slow to load and render.
A truly excellent toolkit. The code is very readable and the developers are quick to communicate/respond on the forum or stackoverflow.
I wish more people used it instead of writing "apps" that are just a giant web browser with javascript and a hack to get menus working correctly, with fake UI widgets that don't respond like native window controls (no proper tab navigation, no moveable or resizeable dialogs, keyboard accelerators don't work).
So true... some people seem to appreciate the their "aesthetics", but many 2022 UIs are just much worse than what we used to have with... Windows 3.1, or System 7 on Mac. They had uniform keyboard shortcuts (at least Windows, no idea for Mac which I used only very rarely), uniform window controls, applications that didn't need a 150 MB runtime... the worse, is that this is still possible today, just many people don't even bother to try doing it.
I' redoing all the UI on my eCommerce app to be "server driven" across iOS, Android, Web.
I get near parity on design on all platforms yet keep full native speed on mobile.
The main issue with old widget system is how hard is to theme them, and theming is, I think, a major driver of the use of HTML/CSS (certainly on my business customers, where they demand the UI be colorized with their corporate stuff!).
Fix that (like with SwiftUI) and suddenly using native is more doable (bussines-wise).
Combining with server-driven architecture, so far my eCommerce app with 3 dozens of screens is made with 2 files of SwiftUI (app specific, plus a one-time cost in build the boilerplate), very doable to a solo guy to code all in 3 platforms.
I wish theming would go back to being something we as end users do to our whole system, not something forced upon us by app developers (or their corporate overlords).
>> wxWidgets licence is a modified version of LGPL explicitly allowing not distributing the sources of an application using the library even in the case of static linking.
I’m truly curious, is this because it rules out distributing a statically linked binary? I may be misremembering, but I thought LGPL is completely fine for commercial apps if you’re just looking against the LGPL’d code.
LGPL stipulates that you should be able to link against your own version of the LGPL library you're integrating, that's to say a user should be able to run an app with their own version of the LGPL library if they want to.
For some app distribution channels, like with iOS apps, that can be difficult to impossible to actually implement given the control Apple has over app packaging and distribution.
Otherwise, you should be able to distribute a commercial non-LGPL app that uses an LGPL library just fine as long as you meet that stipulation.
As others have pointed out, WxWidgets ships with a modified LGPL license that makes this point moot, anyway, and makes it easier for commercial apps to comply with the modified license compared to the bare LGPL as they are free to statically link WxWidgets and distribute apps in compliance with the modified license.
Would it be good enough on platforms like iOS to dynamically link, include the DLLs in the bundle, and tell people they are on their own if they want to switch them out?
>> Would it be good enough on platforms like iOS to dynamically link, include the DLLs in the bundle, and tell people they are on their own if they want to switch them out?
You also have to offer them source code, or just ship it along with.
I meant source code of the library part. Correct, your app can stay closed. You still have to comply with the redistribution requirements of the LGPL code.
I have vivid memories of WxWidgets. I used it ~20 years ago to develop a program to browse a collection of artistic works (mainly sculptures and paintings) that was distributed on a CD (no internet at the time, this is the way knowledge was spread!). It was a bit clunky to use but extremely solid, and the end result was nice: it stored information in XML and displayed it in a window, letting the user to do simple searches and export images as JPG. I was able to seamlessly put in the same CD executables for Windows and for Linux, which was quite a big deal at the time.
A few years later (~2009), I used Qt to develop a big codebase that needed to be used on Windows, Linux, and Mac. It was admittedly nicer than WxWidgets, but my impression was that it was harder to understand what Qt did under the hood… It was as if Qt was trying to be more clever than the C++ compiler, while with WxWidgets it had always be more or less evident what the library was doing.
Bit of a tangent, but it's nice to see a project with a googlable name. If this were started today it would be called Avocado or Potato or something like that.
I used WxWidgets almost 20 years ago with Python to quickly make a project that included printing support. I went from reading the docs to a working prototype in one night!
Hopefully this release will help the planned improvements to Audacity too.
wxWidgets are a perfect choice if you want cross-platform native controls. Just a reminder, Qt doesn't use native controls, it just emulates the native look and feel. Besides wxWidgets I know only IUP that uses system native controls (though Cocoa is a work in progress), and IUP deals with just UI, wx is like a Qt, a lot more.
Eclipse's SWT for Java also uses native controls, and IIRC it does so more consistently across platforms than wx. In 2015 I wanted to develop a desktop app in Python, but use SWT, so I did a hacky mongrel setup where I used the pyjnius Python package to load the Avian lightweight JVM into my CPython process so I could use SWT. Avian is dead now, so if I ever have to port that app to ARM64 for Apple Silicon Macs (right now it runs fine under emulation), I'll be in trouble. But at least for now, the app has a reasonably lightweight cross-platform UI.
Once I started building a GUI wrapper that could either use SWT or AWT as backend (or perhaps Swing rather than AWT, i do not remember).
I do not remember why. Perhaps I thought it will be more portable or performant.
But I quickly abandoned that (would not want to get stuck on a legacy tech like java and awt) and ported all my projects to Pascal for maximal performance.
I'm working on a native wrapper for SWT with GraalVM. The resulting library with base SWT is about 18M, which is fairly large, but definitely workable.
I have successfully used the wrapper from C and Zig as a proof of concept. The main goal was to originally expose SWT for Nim, but I got pretty side tracked. I'll probably make a show HN later this year when I have it in a usable state. I haven't gotten callbacks working quite yet, which makes it pretty useless.
I'm a bit worried about performance, but I'll throw a cassowary constraint manager on top of a ton of widgets and see how it does. Memory usage with an empty window is ~35mb at 1920x1080. It successfully works on Windows, Linux, and MacOS x86 and aarch64.
Also Yue, with bindings for C++, JavaScript, and Lua: https://libyue.com/
I haven't used it for Gtk or Windows, yet, but macOS support seems atleast as good as the other targets.
wxWidgets has a sublime idea: an api that is just a wrapper over native controls. For cross platform frameworks it is fast and light. The very opposite of bloatware.
But it also has a terrible flaw: its heavy-templated C++ api, hard to port to other languages.
I don't want to get stuck on C++. I want to use Go and Rust. And all the wxWidgets ports to those languages suck, big time.
Show me a solid wxWidgets for Rust and I'll fall in love again. Yes, I'd also colaborate on that project, too.
As a user GTK typically feels a little funky on Windows, although I don't know how much of that is a fault with the toolkit and how much of it is a function of Windows definitely not being those developers' primary target.
I'm delighted to hear Rust programmers have got something worth using.
wxPython is the only maintained alternative there. I think there’s an opportunity to create bindings to other languages with libClang nowadays. However, it’s gotta be done selectively, since there’s so much surface area in the API to fill in the gaps for C++’s standard library.
I also maintain wxlua (Lua wrapper around wxwidgets: https://github.com/pkulchenko/wxlua) and it is expected to work with the current wxwidgets release (I tested with a recent pre-release version).
For those thinking that this is just another version, note that 3.2 is a stable version, with 3.0 having been first released almost nine years ago. In the interim, I'm sure many people have used 3.1, but now you get all of the fun enhancements without an asterisk.
Many people don’t know about XRC, which allows you to describe a window in an XML document much like HTML. It can be edited and live reloaded. Wonderful feature.
Seems cool for tweaking layout and styles on the fly, thanks for pointing this out.
I think many devs underestimate how important the JS world's Hot Module Replacement has become for frontend dev velocity. Live reload just makes visual work so much better.
Of course we all know the scourge that is Electron apps. Maybe now that native web view is becoming more available across desktop OS's we will see apps move to leaner frameworks. Tauri (which hit 1.0 yesterday) allows native system access, notifications, app tray, auto updates, polyglot backend via sidecars, and HTML/CSS/JS/TS frontend. Not native controls that many of us love, but much better than where we're at now.
I use Yue (libyue.com) with its Lua bindings. I compile Lua source files into a static binary, but I can flip a switch (in the environment) to load sources from a specific directory. This isn't hot reload--currently I still need to restart the application--but it wouldn't be too difficult to hot reload the sources.
How and when views reflect the new code would be more complex, but AFAICT (from https://www.geeksforgeeks.org/hot-reload-in-electronjs/) it's not exactly magic in Electron, either--browser views are reloaded in their entirety, and the main application is restarted entirely if its sources are changed, so you can lose state. You could probably do something more sophisticated in Lua, by dynamically updating the metatables of live objects (similar to prototypes in JS). That'd be a very leaky abstraction (presumably by Electron hot reload doesn't try it). You'd need to architect your code to be robust to missing or changed object state across versions of the code, or at least to annotate which objects are capable of being hot reloaded. But Smalltalk and, to a lesser extent, Objective-C developers have experience hot patching code this way, so it can be done.
That said, I find myself wishing that they'd have a page of screenshots and code snippets for each components, like web development frameworks typically have, for example: https://www.primefaces.org/primevue/calendar
Of course, you cannot run those components live, but might at least have screenshots of each component on each supported platform.
SWT has its set of issues. Last time I had to do desktop UI, I went with Swing. Other option is going a JavaFX way, which even has a nice Clojure bindings.
In the "Platform details" page [1] they say that GTK 3 is the default since WxWidgets 3.1.4, but if you want you can link against GTK 2 by calling `configure` with the flag `--with-gtk=2`.
