Back in the early nineties I worked on a couple of projects that used wxWidgets (it was still called wxWindows then) to target MS Windows and Motif on Unix. I'm amazed to learn that it is still around and being used.
I remember it as being quite a nice library with a decent API for its time. There are probably some useful lessons to be learned from its longevity.
(1) It's stable. No "let's rewrite everything every two years!" It's a bit ugly but once you learn it you know it.
(2) It targets a reasonably stable set of platforms.
(3) It's not over-ambitious. It doesn't try to be its own rendering engine or implement pseudo-style-sheets (I'm looking at you Qt) or do other crazy things. It just wraps a minimum common denominator of desktop UI functionality sufficient to ship a good working application that's not too ugly and is usable.
As such it's great for long lived C++ code bases that need UI functionality across platforms.
Well, yes, but hasn't the same led to bit rot? Admitedly, I haven't looked at wx in a looong time. But when I was, I was looking at WxPython, and IIRC at the time there was an issue with wx being 32-bit only with no visible progress towards 64 bit. That scratched wxPython off my list for that project. (I admit my data is stale here, so, if you can refresh my cache, please do.)
32 and 64-bit versions are available for the big three platforms and work well. I have custom desktop apps that I need to deploy to 32-bit Windows, 32 and 64-bit Linux and 64-bit OSX and wx has been a sane way of getting a GUI for all of them.
Yup. WxWidgets was probably the least useful graphical development environment I have used. In particular, many of the GUI elements don't expose their inner widgets. For example, when I used it, I wanted to change the font of a label in a tabbed window. The tabbed window widget provided no access to the font object at the C++ level- I suppose you could subclass, but that wouldn't propagate tot he Python generated classes.
You're better off just using qt: they put a lot more work into making it a useful environment, it runs a lot more places.
> In particular, many of the GUI elements don't expose their inner widgets
But you know why, right? It's because it's supposed to be both cross-platform and native, so a particular platform may not use a nested label widget in a tabbed window, so it can't give you such an object.
Maybe my information is out of date, but I didn't think Qt supports any platforms natively at all. So Qt can give you a label widget, because it's creating the controls itself. They aren't really native controls.
If you look at the Windows implementation for the wxNotebook (which I guess is the class you mean), you can see it doesn't use a nested widget for the tab label. The field may exist, but this implementation doesn't use it and instead it uses standard Windows API calls like TabCtrl_SetItem, which doesn't allow you to set a font. It only allows you to pass in a char* string.
So on Windows what do you expect it to give you if you ask for the label widget if there isn't one? Pretend there is one and give you some kind of facade object? What should happen if you try to set the font? Since the API they're using just doesn't support it.
I think the Windows API may allow you to subclass a tab to draw it yourself and use fonts, but that's asking a lot. And there still isn't really any label widget for them to return even if they did that!
In the case of windows, you can either use the char * methods, or you have an owner-controlled widget which is a rendering area. That's what Qt does. Combined with Qt's windows style, you get somethign that looks native by default, but is customizable.
This seems to me to be a far more productive approach that trying to come up with an API that supports only the common subset of features shared between Apple's UI toolkit, Windows UI toolkit, and Linux. Note that qt also supports embedded devices with raw frame buffers; you can make a UI that looks nearly pixel identical to Windows on that platform.
> This seems to me to be a far more productive approach that trying to come up with an API that supports only the common subset of features shared between Apple's UI toolkit, Windows UI toolkit, and Linux.
But an API with the common subset of features is the whole philosophical point of wx! If you're going to criticise them for that you might as well criticise screwdrivers for turning screws. That's what they were built for.
Well, then I disagree with wx's approach. Not only is it more inflexible, the qt solution of creating a styled UI that can be adapted to look native, while being portable and not preventing people from customization, seems to be more flexible.
Note also that Wx runs on top of Qt. Why not drop Wx and just use Qt directly?
Wx doesn't run on top of Qt, it simply has an option to use Qt as its back end engine in place of e.g. the Windows native API. You can do a Windows build that doesn't have Qt anywhere in sight.
> Yes,you are correct: Qt uses themes and styles to configure its internally rendered widgets so they appear native.
Oh wow, I have developed QT applications and never even noticed that. Sure, on Linux I know that it draws the controls, are there are no standard controls. But I figured they just had a pretty good integration and didn't bother looking under the hood.
You will notice it most when Microsoft updates the look and feel of the standard widgets in a new version of Windows. The Wx app will pick up the new look automatically, the Qt app will need to be updated.
Your example kind of reflects that you aren't using wx for what it's made for. You can usually call GetHandle() and switch to platform specific stuff if you need to do something weird like that. I wouldn't really recommend that though. The point of wxWidgets isn't to be the most flexible GUI framework. It's to be as consistent and native as it can be across many platforms.
If you need to do weird things in a non-native way then wx probably isn't for you. If you want to write software that looks and feels like a native application (because it is) then wx is your best bet.
Qt is great but I've never used Qt application that felt like a native application. Also, Qt is rather expensive for commercial projects (about $4k per year per developer).
In my case, I wanted to bold the font when an activity occurred there, so a user would know to navigate to that tab.
I don't particularly care about the host platform; I write software that runs on all 3 major platforms, and having it behave mostly-consistently across the platforms is more important than being consistent with the host platform.
That's the main idea of wxWidgets - it doesn't have its own GUI backend (wxUniversal really doesn't count) but uses other native frameworks such as win32, cocoa gtk and now QT too. So it will probably look nice and native in say KDE environment.
And I suspect albeva's point is that Qt is technically cross-platform but practically will look odd on every platform but native. GTK is exactly the same, technically cross-platform but practically a GTK application on Windows or OSX stands out like a sore thumb and behaves weirdly.
> but practically will look odd on every platform but native
That's absolute nonsense. First of all there's no "native" platform to Qt because it's cross-platform, and that's taken extremely seriously. Second of all, Qt apps are extremely well integrated on Windows, OSX and Linux alike.
There's tons of examples of commercial Qt apps exactly for that reason. What you say is true only for GTK, not Qt.
>Second of all, Qt apps are extremely well integrated on Windows, OSX and Linux alike.
I've never seen a QT app that I couldn't immediately tell apart from a native OS X/Cocoa app -- with the exception of Skype, which still doesn't look 100% native, but at least looks like it has a decent skin.
Nope, I follow UI toolkits pretty closely and always try to find a native app for a given task first and foremost. After that QT is the second best option, GTK somewhat worse, and Swing and other monstrocities to be avoided at all costs.
It's not subtle either, these things always stick like sore thumbs -- only exception are some that only use very basic widgets and delegate 90% of the work to native ones (like native file open dialogs etc).
Qt is great but it's a stretch to say it looks and feels completely native. Open Qt Creator on Windows and tell me it looks or feels anything like a native Windows application.
Qt looks pretty close if you stick to just the essential controls/widgets (text, buttons, text fields). Once you start using other stuff you can definitely tell it isn't a native application. That's not to say Qt isn't good. It's a great toolkit and far, far more complete and featureful than wxWidgets but that's comes as a trade off. The native-backed nature of wxWidgets means you are kind of working with the lowest common denominator a lot of the time which means you don't often get more sophisticated control/widget options. You also have to deal with more bugs between the platforms whereas you rarely have to with Qt.
You have to decide if you want a big, powerful toolkit with commercial backing (and a pretty hefty licensing fee for commercial users) that doesn't quite feel native or a natively-backed toolkit that is less featureful, more buggy, and free.
> looks or feels anything like a native Windows application
But compared to what? A ribbon app like MSWord? Photoshop? VS2015? VS200X? They're all radically different and they're all creation-centered apps, so if you tell me Qt Creator doesn't feel native... it feels more native than any of those I cited, all massive commercial successes?
It's like you said... it looks native when you stick to forms and buttons. And honestly, yeah that's fine, because any app that doesn't stick to forms and buttons will want to customize itself far more.
>On some platforms (such as MeeGo and KDE) Qt is the native API. Some other portable graphical toolkits have made different design decisions; for example, wxWidgets uses the toolkits of the target platform for its implementations.
As far as I know, it's also true that Qt doesn't try to use native widgets, it instead tries to draw them on its own (resulting in more possibilities of course).
Besides maintaining the eponymous desktop environment, KDE is very much a platform, leveraging Qt, but also offering its own core libs and infrastructure for tons of stuff.
So much so, in fact, that the title of their webpage is: "KDE - The KDE development platform".
I should know, I've been following (and occasionally participating) in the project since 1998.
It is not a platform in the sense that's meant in the post above, which is why I said the article is misleading, not wrong.
Like you said, KDE leverages Qt. Qt doesn't leverage KDE in the sense that "Qt's native platform is KDE".
When you say "native" when talking about a cross-platform toolkit, you're implying the toolkit was first designed to run on that platform and then ported to others. Qt predates KDE, as you well know.
>When you say "native" when talking about a cross-platform toolkit, you're implying the toolkit was first designed to run on that platform and then ported to others.
No, you're just implying (as the parent did) that the platform (KDE) had picked and stuck to the toolkit (Qt) as its basis, unlike Wx which has multiple.
Exactly. Running Gimp or Inkscape on OSX is really painful experience at some times. I wish they choose wx instead of GTK.
You usually cannot tell wxWidgets application from any other system one (unless the developer is clueless about platform guidelines like Quit menu item on Mac or such).
They might look right, but they don't behave right with screen readers and other assistive technology tools, or with software designed to programmatically access, automate or test GUI controls. So it's a shame more software projects don't use wx, which for the most part doesn't have those problems.
With my consulting work, I still end up doing a lot of desktop application development. I've been on the lookout for a GUI toolkit that I could use to replace WinForms in my workflow. Ideally, it'd be cross-platform, support native widgets, and provide the de facto standard OO API that every other GUI toolkit has converged on. I know WinForms doesn't check all those boxes, but I see no point in moving to WPF which checks even fewer.
So I get excited when GUI toolkit projects get posted on HN. And then I'm usually deflated when I look at the screenshots. I know they haven't built these programs themselves, so it's not necessarily their fault that these developers have gone with the everything-and-the-kitchen-sink style of UI design. But they also chose to feature these particular projects, so someone there thinks these are good examples, which does not speak well towards their commitment to enabling good design.
https://www.wxwidgets.org/about/screenshots/
Most of these examples feature something you should never do: selectively replacing the standard widgets from your operating system's toolkit. Either create/use a different toolkit entirely or use the defaults, don't mix and match.
It's disheartening to think that, in 2016, the least-bad way to design a UI is to wrap up a browser as a widget and sling HTML/CSS.
I'm really not sure what you mean. wxWidgets is a wrapper around the underlying GUI framework.
AFAICT, all of those screenshots are using the standard wxWidgets UI elements, with the obvious exceptions of the audio waveform, the on-screen keyboard, and the 3D graphics widget, which will not be standard components in any GUI toolkit.
The variation is due to the users taking the screenshots using different themes or styles in Gtk, KDE, Windows, etc..
I was not talking about those very purpose-specific widgets. I know they aren't standard components. I'm also not talking about theme- or OS-specific differences. I'm talking about the fact that few of the examples maintained a 100% consistent look and feel within their own theme. These are not nitpicky things. Maintaining visual consistency between applications is key to achieving usability. Here are some examples:
A hacked together Ribbon view out of a tab-view placed in the toolbar location, but they also include a separate toolbar section. Finally, that "calculate" button should follow its config elements, not precede them: https://www.wxwidgets.org/about/screenshots/coppercube-msw.j...
I'm simply baffled that you're nitpicking little things like those, and then jumping to the conclusion that wrapping a browser widget is the best way to display a GUI in an end user application. HTML/CSS UIs you're suggesting are notorious for using ugly, non-standard, completely hacked up widgets with ridiculous styling that don't fit in with the rest of the system.
Furthermore none of your nitpicks are due to wxWidgets itself and are mostly due to the application developer making usability choices (i.e. using customized buttons, grouping toolbar buttons using color, etc.) or simple mistakes (like forgetting to turn off the grid view header).
I know they haven't built these programs themselves, so it's not necessarily their fault
that these developers have gone with the everything-and-the-kitchen-sink style of UI
design. But they also chose to feature these particular projects, so someone there
thinks these are good examples, which does not speak well towards their commitment to
enabling good design.
And they aren't little things. Replacing standard buttons in some cases but not others confuses the user as to what elements are actually interactive. Not using the layouts that the operating system vendor recommends for different types of applications confuses users as to where to expect to find things. Using your own, janky set of icons without text labels confuses users as to which buttons do what.
I mean, have you even used KiCAD? It's an absolute abomination of UX.
You know how programmers have a reputation for being bad at design? You know how programmers have a reputation for "not having any common sense"? This is why.
The point is, using a silly web UI in a browser widget, as you suggested, makes the problem worse.
TBH your argument sounds like a designer trying to justify being a designer. No real users are "confused" by any of the things you've nitpicked about. You're conjuring up some uber-stupid theoretical user as a strawman. But feel free prove me wrong by finding real people on the web complaining that they're confused by those issues.
I think it's the influence of the web that has allowed these deviations from standard to flourish in a way that they couldn't have 20 years ago. When every widget on a web page is new and unknown, you just learn to deal with it. Certainly you can find bad design both on native apps and on the web.
Yeah, these look pretty bad. If you are going to reskin, reskin everything. However, on Windows, you really cannot. Even more so if you are using the "classic" interface. On my last count, the scrollbars would redraw themselves in response to 11 different types of messages (not only WM_PAINT and WM_NCPAINT, as one would expect). And the API wouldn't give you a handle for you to draw them yourself, windows forms or not.
Also, it doesn't help that most of the screenshots are quite old. Where are the apps running on Windows 10? The OSX screenshots, when present, are from the first OSX versions.
Just getting done with a pretty significant realtime plotting app using CMake, Qt 5.5 and QWT. I have to say, it's been a mostly painless, pretty pleasurable experience. The Stylesheets CAN be a huge pain though. If you get a good and organized architecture down, it is by far the best method to style a desktop app I've ever used. Especially if you utilize QObject properties!
I'm not sure I see wxWidgets as being the real problem here. The real problem is bad UI design, and you'd end up with that regardless of the toolkit used.
I am often in the same position. There are only more or less bad options, no good ones. Even on Windows only it's hard to pick a good toolkit for apps that can run from Windows 7 to App Store.
I haven't used it much but Qt seems to the best option at the moment.
I will have to look closer at Qt, then. The last time I looked at it, it seemed like it required a hefty licensing fee for commercial use and building forms required use of their janky editor. But that was a while ago, so it could have changed. The only proprietary editor I have room for in my life is Visual Studio, and even that is begrudging.
FWIW, I think Eclipse's SWT is the least bad option among cross-platform desktop GUI toolkits. Have you used it?
wxWidgets is a close second, but there are some caveats. For example, for a native multi-column list view, you have to use wxListView on Windows, but wxDataView on OS X and GTK.
I'll agree that the featured apps are badly designed (overly reskinned), but I think they have been chosen because they are well known open source applications and also because of the rich set of controls used.
In the early 2000's I wrote a few apps with this toolkit and was quite happy with them. The native widgets looked/worked correctly and were "snappy." Around that time everyone decided that we would use QT from now on, even though it looked slightly off. I never had any complaints about wxWidgets/Python except for the passing of ID numbers. shrug
I remember it as being quite a nice library with a decent API for its time. There are probably some useful lessons to be learned from its longevity.