CODEWITHSUNDEEP
c++cocoaqtuser-interfacegtk
user2642129
user2642129

Reputation: 9

What's the solution to native GUIs?

From what I understand from SO, Qt doesn't look native at all on OS X.

So how do you fix this? Do you use another GUI library such as GTK? But then it won't be native on anything other than Linux, right?

Do you have to write a GUI for each OS? So you write one Qt GUI for Windows, one Qt GUI for Linux, and one Qt GUI for OS X? Or will it still look non-native?

Do you have to use different GUI libraries depending on the OS? So you use Qt for Windows, GTK for Linux, and Cocoa for OS X? But Qt is more than just a GUI library; it has so many features. So does that mean that you will need to reinvent the wheel for Linux & OS X?

Upvotes: 0

Views: 438

Answers (1)

Joel
Joel

Reputation: 1145

It's been my experience that you have two competing goals when developing GUIs:

  • Avoiding duplication of work in re-coding for each platform
  • Looking like it 100% "belongs" on the platforms it runs on

As it stands, you basically have to pick the one that matters the most to you.

There is no GUI toolkit I know of that achieves that ideal perfection of both being portable and looking like the result "belongs" on every platform - this includes both C++ and Java options. There are definitely things that achieve near-native look, but there are always those things that just aren't quite right about them. Personally, I've come to prefer what I would call "engine portability," and I'm sure there are fancier names for it. Basically, it would be to make the core of your logic as portable as possible while being able to - but not required to - port the GUI if necessary.

This would basically mean not relying on all the non-GUI features of libraries like Qt unless you know for sure they are going to be available on every target platform you will ever need to run on. For example, I had to port some C++ code to Android once, and Qt on Android didn't exist at the time. If my core logic had relied on it, I would have been in trouble. And if my engine hadn't been separated pretty well from my GUI, I would have been in trouble. As it was, I had to recode the UI in Java and then just called the engine through JNI. I also had to port some of the lower-level features such as threads, because C++11 hadn't been finalized at the time, I couldn't use boost threads, and the original code was for Windows. But the core logic didn't make direct calls to the operating system threading library, so the vast majority of the code didn't need to be touched.

(As an aside: This is not to say you can't use the non-GUI features of things like Qt, but if your code is integrally tied to it then you will be stuck if you have to code for a platform that the library doesn't support. If you have an abstraction layer between your code and Qt, then you only need to port the abstraction layer.)

Portability is not easy. Things have definitely come a long way, but we haven't achieved what we developers would all like to have, and I'm not convinced we ever really will.

This is all just IMHO, but it's based on experience.

Upvotes: 4

Related Questions