
WxWidgets 3.1.0 Brings Better HiDPI Support, WxQt with Qt5 - Tsiolkovsky
https://www.wxwidgets.org/news/2016/02/wxwidgets-3.1.0-released/
======
andyjohnson0
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.

~~~
kelvin0
I've used it in production code for the last 10 years. Used in both C++ and
Python flavors of the lib ... works great!

~~~
tonyedgecombe
I have too but I don't like it and feel I would have been better off with qt.

~~~
dekhn
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.

~~~
chrisseaton
> 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.

~~~
dekhn
all the native platforms that qt supports support nested label widgets. the wx
class _has_ that member variable, it's just private with no accessor.

~~~
chrisseaton
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.

[https://github.com/wxWidgets/wxWidgets/blob/master/src/msw/n...](https://github.com/wxWidgets/wxWidgets/blob/master/src/msw/notebook.cpp#L389-L413)

[https://msdn.microsoft.com/en-
us/library/windows/desktop/bb7...](https://msdn.microsoft.com/en-
us/library/windows/desktop/bb760554\(v=vs.85\).aspx)

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!

~~~
dekhn
Yes,you are correct: Qt uses themes and styles to configure its internally
rendered widgets so they appear native.

[http://doc.qt.io/qt-4.8/style-reference.html](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.

~~~
chrisseaton
> 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.

~~~
dekhn
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?

~~~
mark-r
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.

------
fithisux
WxQt sounds a bit of overkill.

~~~
albeva
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.

~~~
andyjohnson0
I suspect fithisux's point is that Qt is _itself_ a cross-platform library
that abstracts the underlying gui.

~~~
masklinn
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.

~~~
scrollaway
> 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.

Disclaimer: Lead dev/designer of LXQt.

~~~
coldtea
> _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.

~~~
dools
isn't it possible that you've seen qt apps you couldn't tell apart and
therefore didn't realise they were built with qt?

~~~
coldtea
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).

But let's see, if you have any

------
moron4hire
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/](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.

~~~
jlarocco
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..

~~~
moron4hire
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:

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...](https://www.wxwidgets.org/about/screenshots/cars-hotsurf-msw.png)

Non-standard toolbar buttons, repositioner handles, and rendering and location
for tool-window close boxes:
[https://www.wxwidgets.org/about/screenshots/audacity-
msw.png](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](https://www.wxwidgets.org/about/screenshots/boinc.jpg)

Non-standard coloring on buttons in toolbar:
[https://www.wxwidgets.org/about/screenshots/ginkgo-
windows.j...](https://www.wxwidgets.org/about/screenshots/ginkgo-windows.jpg)

Link-buttons used for commands ("Run Benchmark") and reskinned, giganto
elements mixed with standard, tiny elements:
[https://www.wxwidgets.org/about/screenshots/sysmark2012.jpg](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](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-...](https://www.wxwidgets.org/about/screenshots/audio-evolution-
msw.png)

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...](https://www.wxwidgets.org/about/screenshots/coppercube-msw.jpg)

~~~
jlarocco
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).

~~~
moron4hire
As I said before

    
    
      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.

~~~
jlarocco
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.

------
hyperbovine
When will this trickle down to wxPython?

------
mixmastamyk
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_

------
FraKtus
-> Better support for high DPI displays, especially under Windows

Really happy about this because it's becoming a serious issue if you support
several variations of windows from XP to 10...

