Which, if any, achieves Windows native look: GTK+, wxWidgets, Qt, FLTK?

Question

I need to write an application that will be visually indistinguishable from something written natively for Windows XP/Vista/7 using whatever comes by default with the most modern Visual Studio. But I'm developing using MinGW and Vim (in C++).

In particular, I want the following controls to be native on the above three versions of Windows: form chrome, buttons, check boxes, menus, combo boxes, progress bars, scrollbars, rich text boxes. This will be enough for me.

I know that if you load GdiPlus and other things like riched32.dll as needed, and use Windows API to instantiate controls, then the OS will substitute its version of GdiPlus or other library, so it will look like XP style controls on XP, Vista on Vista, etc.

But I don't want to use plain Windows API, because even retrieving the default font takes half a page of code, and similar stories whatever I want to do. So I'd like to use a toolkit.

wxWidgets, Qt, GTK+, FLTK seem like the most widely used. But they are all cross-platform. I've used cross-platform applications, and many of them have foreign GUI controls (I call them widgets). So my question is: which of these toolkits can be made to produce true native-looking UI controls listed above, appearing correctly on the three versions of MSWin listed above?

I've typed each of them +" windows" into Google Images, but it's hard to tell, except that FLTK probably can't do it. Many of you must know the answer off the top of your head...

Solution 1

I won't talk about FLTK as I don't know it.

• wxWidgets uses the native toolkit of the platform, (GTK on Linux, Win32 GUI API on Windows, Cocoa on MacOS X).
• GTK uses a theming API to fake the look and feel of the platform (custom theming engine on GTK2, CSS-based engine on GTK3).
• Qt uses styles to fake the look and feel of the platform.

wxWidgets API is quite ugly from my own experience, because it had too many method just available on one or the other platform making stuff non-portable unless you'd workaround it. Unlike GTK+ and Qt, it also adds its own layer of bugs above the toolkit it uses as a backend. However, it tries hard to have the platform's native look as it uses the native toolkit.

GTK+ 3 still has some rough edges on Windows, which it officially supports since GTK+ 3.6. The GTK+ project delegates to the MSYS2 project the distribution of Windows binaries. As you're already using MinGW, that's pretty much the same kind of environment. They have good C++ bindings with GTKmm. However, you may have some work to get the theming right for your version of Windows.

Qt is a good choice for cross-platform C++ development with the main target being Windows, tries to mimic the native look and feel of the platform but has its own theming limitations too.

To sum up, there are only 2 approches:

• toolkits that provide their own widgets and try to look like the native platform by providing theming (GTK+ and Qt)
• toolkits that use the native widgets but hide their API behind a layer of abstraction (wxWidgets)

Both have their pros and cons.

Solution 2

Implementation details aside, wxWidgets philosophy is, and has always been, to look as natively as possible. We, wxWidgets developers, don't always achieve the goal of looking indistinguishably from the native applications but we always strive to do it and. AFAIK this is not such an important goal for Qt and definitely not for GTK+, so in my (obviously biased) opinion, wxWidgets is your best choice if you are serious about providing the best experience for your users, especially under OS X.

To answer your question more precisely, everything you list above is implemented using native controls in wxWidgets for Windows (rich text control is not available natively under the other platforms though).

Solution 3

IUP - Portable User Interface library uses native widgets, C API and Lua bindings.

Solution 4

i used java for native cross-platform without changing the code, used c/c++ wxwidgets for exclusively cross-platform if you want go to little up performance and standalone executable, used c/c++ winapi for windows and x11 for gnu linux native platform and terminal console, used python for scripting console and platform if you want your software up to date fast, and used assembly for a little simple purely console. And sometimes i combined them all with shared library .dll on windows and .so on gnu linux. And i liked doing for do comparative performance on programming studies with small hardware requirements.

View more solutions

Comments

[Evgeni Sergeev]

I initially thought I'll go with wxWidgets, because the faking approach often gets it subtly wrong, and this itches the user. Also, it's not future-proof; consider pluggable themes, you can't fake them all. But then this answer stackoverflow.com/a/5800101/1143274 convinced me that I'll have to stick with plain WinAPI, because my application must be fast in terms of start-up delay. And I searched enough to confirm that there isn't a lightweight library that does commonsense default initialisation and macros for WinAPI for me, so I'll have to do it myself.

[NuSkooler]

How is wxWidgets "quite ugly" when it uses the native UI? Apps developed with wx are indistinguishable from those developed with the platform's standard toolkits.

[liberforce]

I was talking about the wxWidgets API, not the look and feel.

[liberforce]

@Evgeni: WinAPI loading time is fast because it's native. But that's a terrible choice, unmaintainable and so low level it take 3x or more code to do the same thing than a more advanced toolkit. Startup time isn't the only thing in life.

[waldyrious]

The wxWidgets wiki has a nice (honest and comprehensive) comparison with various other toolkits. One interesting point that's made there is that by using native bindings rather than emulating native look, wxWidgets apps are more likely to look, behave and feel native, but a negative side effect of this is that they are more likely to present platform-dependent behavior or manifest platform-specific bugs.

[waldyrious]

Another good point from the comparison at the wxWidgets wiki (from the discussion page): "Qt uses the native graphics APIs to render native-looking interface elements, etc, but it still doesn't actually use the native controls themselves. This means they ensure the native appearance, not the behavior. Controls in Qt may look native, but the operating system doesn't recognize them as what they are since they're not actually the native controls themselves, and as such, built-in accessibility tools like screen readers don't always work correctly (or at all) with Qt applications."

[Lothar]

Unfortunately wxWidgets is not looking nice, classes like rebar/toolbars and ribbons are not using the native controls. I just checked the 3.0 version and very fast decided to give up. And having visuals (Office blue) like MFC Featurepack is not possible.

[skan]

What is the easiest to use?. (Shorter code to get similar results)

[skan]

Can you give a list of some well-known applications using GTK, wxwidgets, FLTK, QT or Ultimate++, please? It could be good to compare their looking.

[liberforce]

Comparing random applications is pointless. The main target environment has an influence on design. What one would prefer is applications that switched from a toolkit to another and compare previous to new versions. Wireshark and subsurface both migrated from GTK to Qt, so it might be possible to run both versions on a Windows computer to compare the look and feel.

[niutech]

@Roberto Fixed.

[Marc.2377]

I'll try and put it more nicely than the previous commenter: This does not provide an answer to the question, in particular considering the other answers are much older.

[TFuto]

Actually, he is saying that there is no viable solution currently that measures up being a good developer, and maximizing use of what is currently available for the specific purpose. Unless you have the ca$h for Qt, probably this is the path everyone follows.