4 ms·

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

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.

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.