[jcranmer]

You've inadvertently answered your own question. There are actually several "cross-platform native" toolkit wrappers, but they solve the problem at best poorly, since they all suffer from the same deficiencies:

1. C has an almost non-existent standard library, and C++ has a relatively weak standard library (compare Java or Python). This means that relatively basic concepts like "lists" or "iterators," which end up being common in GUI code, end up needing to be massaged slightly differently for any library that uses them.

2. Invariably, the desire list for GUI libraries starts requiring platform support logic that's very, very different for different platforms. File picker dialog? Now you need to handle filesystems. Printer dialog? Goodbye!

3. Even where features are more or less identical between different platforms, how they work actually tends to differ at a fine-grained level. Change the font, and all of a sudden text flows differently; what may have fit a fixed-size window no longer fits. When you ask for the union of possible features instead of the intersection, you also make sure that the toolkit has to get into very low-level details of this stuff (e.g., double-buffering, damage rectangles, pixel drawing), where these differences are much more noticeable.

4. UI conventions themselves are actually very different across platforms, particularly if you include mobile or tablet form factors in addition to desktops. So a toolkit that wants to be as-native-as-possible would require UI to be designed and specified only at very high levels, to the point where it's not a thin layer around the UI toolkit but rather a component that dictates the design of your application.

[tracker1]

As an extension to 4, generations of OSes and applications add to that variability... compare Windows 10, and the latest MS-Office UI to Windows 2000/Office 2000... Very different... the same to a lesser extent with OSX.

I think your best bet is to create a UI that is as clean as possible within the context of your application, and try to map those things that make the most sense per environment (IE the top of window menu vs screen/app menu in OSX) and Some of the placement conventions for menu options.

This makes sense in native-is as well as web based applications. The fact is, with as much variety as there is, there really isn't a canonical application profile that's consistent everywhere... so trying to make a nice looking app should be the first priority over making it look like {insert os here}.

[kitsunesoba]

>This makes sense in native-is as well as web based applications. The fact is, with as much variety as there is, there really isn't a canonical application profile that's consistent everywhere... so trying to make a nice looking app should be the first priority over making it look like {insert os here}.

Looks are nice, but it's about behavior too. One of the reasons I hate web apps and web apps in desktop wrappers is because their behavior is totally inconsistent with that of the OS (and often, of any OS). I really hate this because it greatly dilutes OS choice for all the wrong reasons.