5 ms·

I agree, and I wonder how much further ahead it would be if they'd switched to the current licensing scheme years earlier. Other than writing native for each p

by FigBug 12y ago

I agree, and I wonder how much further ahead it would be if they'd switched to the current licensing scheme years earlier. Other than writing native for each platform, which I don't have time to do, I haven't seen any good alternatives to Qt. And I'm not going back to MFC.

Iftheshoefits 12y ago
I haven't investigated Qt's mobile offerings or "Qt Quick", but I am fairly certain that on X11-based systems the basic core desktop SDK is as native as any other UI toolkit (e.g. GTK), and on Windows it uses the same core libraries that MSVC-written programs use, so it's as close to "native" as it gets there, too. Is that incorrect?
- jmaygarden 12y ago
  That is incorrect unless things have changed in the last few years. Qt does not use native controls. Everything (list boxes, tables, buttons, etc.) is drawn and implemented by the Qt library. wxWidgets takes the opposite approach and uses native controls. I imagine they support a lot fewer platforms as a result. It's much easier to port when all you have to do is abstract the native drawing and input routines.
  - panzi 12y ago
    One might want to add: There are not "native" controls under X11 (and I guess also Wayland). There Qt is as native as any other toolkit.
    - zokier 12y ago
      There barely are any "native" controls on Windows either.
      - wolfgke 12y ago
        Then what is the function CreateWindow in User32.dll for (for all non-Windows developers: this is the WinAPI function to create a control on Windows; it returns a handle to it)? > http://msdn.microsoft.com/en-us/library/windows/desktop/ms632679.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ms63... The lpClassName parameter specifies the type of control to create.
        roel_v 12y ago
        The vast majority of controls on any Windows screen in 2014 is created with CreateWindow calls with that parameter set to some value that was added on by RegisterWindowClass though. I still agree with you that it's silly to say that Windows hardly has 'native' controls.
  - malkia 12y ago
    I was also against not doing native controls for quite long time, mainly because I thought using native controls was the only way to give the system (Windows for example) ability to read the text and other data (screen readers, automation, etc.) It turns out that's not the case. There is an ACCESSIBILITY api which Qt implements that allows the OS (Windows) to "read" text and control the GUI in the non-native widgets. This, and the fact that it's much more simpler to do things by subclassing the C++ way. I also have wxWidgets experience, and here is my summary: Lots of Leaky Abstraction. For example - try to get the current line of a text-edit control - internally what wxWidgets does (or was doing time ago) was to send message to the control, but if the control did not support the message, it had to reparse the whole text, and based on your byte-position count how many CR-LF were there and give that information to you. e.g. it was hard to predict which operation is going to take this and that much of time. Qt is not without pitfalls, and missing features - Visual Studio Docking like windows for example that supports multiple monitors, but other than that it was much easier for our team to use it, rather than MFC or the Win32 API, and even wxWidgets.
  - icefox 12y ago
    > is drawn and implemented by the Qt library. It is not so black and white. For example when there is a button when possible Qt will ask the native system to draw a button with properties x,y,z at location x,y So it might be a QPushButton, but it is the OS X or Win32 library that is doing the painting that the user sees. Of course on Windows the idea of "native controls" is confusing as many Microsoft apps have their own "native controls", which one is the native control? I am guessing WXWidgets simply picks the lowest common denominator one and moves on.
  - dekhn 12y ago
    The deal-breaker for me with wxWidgets was that it "hides" many things in its widgets: for example, I couldn't easily change the color or font of the text in a tabbed widget's tab in python, as those were private variables in the C++ implementation and there were no handles to change them.
- nicholassmith 12y ago
  Little bit of a, little bit of b. They use some native controls on X11, and I think they hook into the Windows C++ APIs in places as well, but with the shift to QML I think it's back to being heavily custom control based again.
  - ori_b 12y ago
    > They use some native controls on X11 They are native controls on X11. Or, more accurately, X11 has no native controls. The closest is probably XAW, which is so awful it was dropped decades ago. There are QT themes that will use GTK for rendering, though. (For reference, a screenshot of XAW: http://www.iue.tuwien.ac.at/phd/halama/_13595_figure4289.gif http://www.iue.tuwien.ac.at/phd/halama/_13595_figure4289.gif The box with 'Athena Simple Widgets' is what is provided by X11.)
    - bryanlarsen 12y ago
      Usually when people talk about native controls on Linux, they're talking about the controls used by whatever window manager they're using. By that measure, QT is not native on any of the gnome window managers, but is native on a KDE based distribution.

by FigBug 12y ago

Iftheshoefits 12y ago

I haven't investigated Qt's mobile offerings or "Qt Quick", but I am fairly certain that on X11-based systems the basic core desktop SDK is as native as any other UI toolkit (e.g. GTK), and on Windows it uses the same core libraries that MSVC-written programs use, so it's as close to "native" as it gets there, too. Is that incorrect?

jmaygarden 12y ago
That is incorrect unless things have changed in the last few years. Qt does not use native controls. Everything (list boxes, tables, buttons, etc.) is drawn and implemented by the Qt library. wxWidgets takes the opposite approach and uses native controls. I imagine they support a lot fewer platforms as a result. It's much easier to port when all you have to do is abstract the native drawing and input routines.
- panzi 12y ago
  One might want to add: There are not "native" controls under X11 (and I guess also Wayland). There Qt is as native as any other toolkit.
  - zokier 12y ago
    There barely are any "native" controls on Windows either.
    - wolfgke 12y ago
      Then what is the function CreateWindow in User32.dll for (for all non-Windows developers: this is the WinAPI function to create a control on Windows; it returns a handle to it)? > http://msdn.microsoft.com/en-us/library/windows/desktop/ms632679.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ms63... The lpClassName parameter specifies the type of control to create.
      - roel_v 12y ago
        The vast majority of controls on any Windows screen in 2014 is created with CreateWindow calls with that parameter set to some value that was added on by RegisterWindowClass though. I still agree with you that it's silly to say that Windows hardly has 'native' controls.
- malkia 12y ago
  I was also against not doing native controls for quite long time, mainly because I thought using native controls was the only way to give the system (Windows for example) ability to read the text and other data (screen readers, automation, etc.) It turns out that's not the case. There is an ACCESSIBILITY api which Qt implements that allows the OS (Windows) to "read" text and control the GUI in the non-native widgets. This, and the fact that it's much more simpler to do things by subclassing the C++ way. I also have wxWidgets experience, and here is my summary: Lots of Leaky Abstraction. For example - try to get the current line of a text-edit control - internally what wxWidgets does (or was doing time ago) was to send message to the control, but if the control did not support the message, it had to reparse the whole text, and based on your byte-position count how many CR-LF were there and give that information to you. e.g. it was hard to predict which operation is going to take this and that much of time. Qt is not without pitfalls, and missing features - Visual Studio Docking like windows for example that supports multiple monitors, but other than that it was much easier for our team to use it, rather than MFC or the Win32 API, and even wxWidgets.
- icefox 12y ago
  > is drawn and implemented by the Qt library. It is not so black and white. For example when there is a button when possible Qt will ask the native system to draw a button with properties x,y,z at location x,y So it might be a QPushButton, but it is the OS X or Win32 library that is doing the painting that the user sees. Of course on Windows the idea of "native controls" is confusing as many Microsoft apps have their own "native controls", which one is the native control? I am guessing WXWidgets simply picks the lowest common denominator one and moves on.
- dekhn 12y ago
  The deal-breaker for me with wxWidgets was that it "hides" many things in its widgets: for example, I couldn't easily change the color or font of the text in a tabbed widget's tab in python, as those were private variables in the C++ implementation and there were no handles to change them.
nicholassmith 12y ago
Little bit of a, little bit of b. They use some native controls on X11, and I think they hook into the Windows C++ APIs in places as well, but with the shift to QML I think it's back to being heavily custom control based again.
- ori_b 12y ago
  > They use some native controls on X11 They are native controls on X11. Or, more accurately, X11 has no native controls. The closest is probably XAW, which is so awful it was dropped decades ago. There are QT themes that will use GTK for rendering, though. (For reference, a screenshot of XAW: http://www.iue.tuwien.ac.at/phd/halama/_13595_figure4289.gif http://www.iue.tuwien.ac.at/phd/halama/_13595_figure4289.gif The box with 'Athena Simple Widgets' is what is provided by X11.)
  - bryanlarsen 12y ago
    Usually when people talk about native controls on Linux, they're talking about the controls used by whatever window manager they're using. By that measure, QT is not native on any of the gnome window managers, but is native on a KDE based distribution.