16 ms·

WxWidgets 3.1.0 Brings Better HiDPI Support, WxQt with Qt5

90 points by Tsiolkovsky 11y ago

andyjohnson0 11y ago
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 11y ago
  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 11y ago
    I have too but I don't like it and feel I would have been better off with qt.
    - dekhn 11y ago
      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 11y ago
        > 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 11y ago
        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 11y ago
        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/notebook.cpp#L389-L413 https://github.com/wxWidgets/wxWidgets/blob/master/src/msw/n... https://msdn.microsoft.com/en-us/library/windows/desktop/bb760554(v=vs.85).aspx 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!
        dekhn 11y ago
        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.
      - mwcampbell 11y ago
        Why would you actually want to change the font of a label on a tab? Wouldn't that make your application inconsistent with the host platform?
        dekhn 11y ago
        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.
      - eco 11y ago
        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).
        tonyedgecombe 11y ago
        Qt is published under LGPL, you don't need to spend £4k for a commercial application.
    - dbcurtis 11y ago
      For someone trying to decide which to use, can explain why?
  - zura 11y ago
    Same here, although with C++ only. And still continuing using it.
- epx 11y ago
  Was a surprise for me as well. wx* makes me remember of Tk, PyTk
- api 11y ago
  Its longevity is due to a couple factors I think: (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.
  - dbcurtis 11y ago
    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.)
    - camperman 11y ago
      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.
hyperbovine 11y ago
When will this trickle down to wxPython?
fithisux 11y ago
WxQt sounds a bit of overkill.
- deleted 11y ago
  [deleted]
- albeva 11y ago
  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 11y ago
    I suspect fithisux's point is that Qt is itself a cross-platform library that abstracts the underlying gui.
    - masklinn 11y ago
      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 11y ago
        > 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.
        witty_username 11y ago
moron4hire 11y ago
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.
- mwcampbell 11y ago
  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.
- jlarocco 11y ago
  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 11y ago
mixmastamyk 11y ago
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 11y ago
-> 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...

90 points by Tsiolkovsky 11y ago

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 11y ago
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 11y ago
  I have too but I don't like it and feel I would have been better off with qt.
  - dekhn 11y ago
    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 11y ago
      > 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 11y ago
        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 11y ago
        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/notebook.cpp#L389-L413 https://github.com/wxWidgets/wxWidgets/blob/master/src/msw/n... https://msdn.microsoft.com/en-us/library/windows/desktop/bb760554(v=vs.85).aspx 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!
        dekhn 11y ago
        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.
    - mwcampbell 11y ago
      Why would you actually want to change the font of a label on a tab? Wouldn't that make your application inconsistent with the host platform?
      - dekhn 11y ago
        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.
    - eco 11y ago
      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).
      - tonyedgecombe 11y ago
        Qt is published under LGPL, you don't need to spend £4k for a commercial application.
  - dbcurtis 11y ago
    For someone trying to decide which to use, can explain why?
- zura 11y ago
  Same here, although with C++ only. And still continuing using it.
epx 11y ago
Was a surprise for me as well. wx* makes me remember of Tk, PyTk
api 11y ago
Its longevity is due to a couple factors I think: (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.
- dbcurtis 11y ago
  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.)
  - camperman 11y ago
    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.

hyperbovine 11y ago

When will this trickle down to wxPython?

fithisux 11y ago

WxQt sounds a bit of overkill.

deleted 11y ago
[deleted]
albeva 11y ago
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 11y ago
  I suspect fithisux's point is that Qt is itself a cross-platform library that abstracts the underlying gui.
  - masklinn 11y ago
    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 11y ago
      > 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.
      - witty_username 11y ago

moron4hire 11y ago

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.

mwcampbell 11y ago
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.
jlarocco 11y ago
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 11y ago

mixmastamyk 11y ago

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 11y ago

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