WxWidgets 3.1.0 Brings Better HiDPI Support, WxQt with Qt5
wxwidgets.org
wxwidgets.org
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.
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.
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.
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.
https://github.com/wxWidgets/wxWidgets/blob/master/src/msw/n...
https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
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!
http://doc.qt.io/qt-4.8/style-reference.html
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.
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.
Note also that Wx runs on top of Qt. Why not drop Wx and just use Qt directly?
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.
The illusion is pretty much pixel-perfect.
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).
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 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.
Disclaimer: Lead dev/designer of LXQt.
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.
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).
But let's see, if you have any
They have different OS X (Cocoa/Obj-C), QT and even GTK implementation of the UI.
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.
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).
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.
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.
Are we done splitting hairs?
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.
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).
Gimp created its own toolkit because at the time, Qt didn't have a GPL-compatible license.
While it is a great apps, UI-wise it is exactly as masklinn wrote. It has weirdness-es on all - Windows, OSX and Linux.
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.
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..
All of the buttons are non-standard, but the gridview headers and tab controls are standard: https://www.wxwidgets.org/about/screenshots/cars-hotsurf-msw...
Non-standard toolbar buttons, repositioner handles, and rendering and location for tool-window close boxes: https://www.wxwidgets.org/about/screenshots/audacity-msw.png
Skinned background and non-standard grouping panels, but standard buttons, menus, textboxes, etc: https://www.wxwidgets.org/about/screenshots/boinc.jpg
Non-standard coloring on buttons in toolbar: https://www.wxwidgets.org/about/screenshots/ginkgo-windows.j...
Link-buttons used for commands ("Run Benchmark") and reskinned, giganto elements mixed with standard, tiny elements: https://www.wxwidgets.org/about/screenshots/sysmark2012.jpg
An MDI hacked together out of grouping panels: https://www.wxwidgets.org/about/screenshots/trident-msw.jpg
There was absolutely no reason to reskin these buttons and textboxes. Skeuomorphism is bad design: https://www.wxwidgets.org/about/screenshots/audio-evolution-...
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...
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.
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.
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.
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.
Qt comes to mind - which allows simple css styling of the whole UI, applied everywhere, in a simple manner – but still can look native.
I haven't used it much but Qt seems to the best option at the moment.
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.
Really happy about this because it's becoming a serious issue if you support several variations of windows from XP to 10...