LibreOffice looks fine on Windows, but anything but native on Mac.
Honestly I kind of wonder why nobody has written a library that acts as a thin layer around and abstraction of native UI toolkits (AppKit, .NET, GTK+, etc) instead of a monolithic do-most-things-or-everything-yourself sort of approach like Qt and GTK take. It'd prioritize feeling native over being consistent and would only write in new functionality to fill in platform gaps (for instance, .NET has no notion of an OS X/AppKit popover, so the .NET portion would have a custom popover implementation that was functionally equivalent yet adherent to typical Windows UI conventions).
> I kind of wonder why nobody has written a library that acts as a thin layer around and abstraction of native UI toolkits
That's what I'm working on. Targeting C++, calling it hiro. So far, I have Windows, GTK, Qt and a dormant Cocoa layer. It truly uses native widgets (although I had no choice but to use custom draw on the Windows ListView), it compiles to ~50-100KB, it uses a fully shared memory model (reference counted) so you never have to call new or delete on anything, uses C++11 so you can bind lambda callbacks, and it uses UTF-8 ubiquitously, even on Windows. So no more L"foo" strings and W function variants.
I've been working on it for several years now, but it's still somewhat in flux. I hope to get a stable API version along with documentation out this year. If anyone really wants to see it right now, take a look at higan and the source to its UI.
I actually downloaded and tried it out as a test. It worked pretty well (for the window and button I created). Keep up the good work! Modern C++ makes a lot of old things new again. Also, although you probably know of it, look up fltk, it was originally written with same goals (and it accomplished them) albeit in C.
Neat, thank you for trying it! It's in a bad state right now with zero examples/documentation. Plus the move to shared ownership was done this year, and has required massive rewrites (Windows/GTK finished, Qt underway, Cocoa not started.)
(I can't begin to express how unbelievably difficult it was to force a fully shared ownership model onto Windows, GTK, Qt, etc. That took several months of effort and is really complex behind the scenes.)
So I don't have much to show off, but I'd really like to get feedback on making the API cleaner and more consistent; as once a stable 1.x series is released, we'll be stuck with any poor choices that were missed for a long time.
I'll try and finish the Qt port, get some basic documentation up, and share it on HN then as a 0.x beta release.
FLTK definitely seems interesting, but seems to use its own widgets instead of being a wrapper around the native platform ones. This has pros (consistency and flexibility) and cons (they stand out as looking non-native.)
I've strongly considered a raster-based backend to my toolkit as well (for things like running apps directly on a framebuffer, or what have you), but have held off so far because it's undoubtedly a massive undertaking. Even if I do go this route, I'll surely write a hiro wrapper for this as well.
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.
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}.
>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.
Honestly I kind of wonder why nobody has written a library that acts as a thin layer around and abstraction of native UI toolkits
They have. Repeatedly.
It never quite works, partly because the shared code has to deal with widgets behaving slightly differently, and mostly because the Human Interface Guidelines for different platforms are contradictory due to being based on different underlying visions.
> I kind of wonder why nobody has written a library that acts as a thin layer around and abstraction of native UI toolkits
Because a native UI is more than just widgets. It's also the layout and naming of buttons. It's the number of toolbars and how they're arranged. It's the phrasing of dialogs. It's integration with the platform keychain. It's the colouring of your icons. And hundreds of other little things.
There are plenty of libraries -- QT, wxWidgets, etc -- that all try to wrap or emulate native widgets, but there's always something subtly wrong, because getting all that right is hard.
The problem with existing libraries is that they try to do away with the notion of different platforms in favor of a metaplatform. In reality, the divergent nature of platforms must be embraced in some ways. I imagine the aforementioned hypothetical thin wrapper as providing really easy ways of getting per-platform right; for instance, it could know the standard control heights and whitespace on each platform and automatically adjust your program's UI accordingly. It also wouldn't be hard to set up a system that allows for per platform verbiage, icon assets, etc.
It's also widget selection; On Android, for example, you may want a hamburger menu. On KDE, your menus get reshuffled compared to your OSX or Windows UI.
I've seen plenty of systems that allow you to do mediocre UIs on all platforms. I haven't seen one that allows you to do an excellent UI without doing once per platform.
I think the answer here is to have a "base menu" that all applications start with instead of starting from zero and having developers fill in the blanks. The base menu knows where to put common special items (Preferences/Options and About for example) on each system, and developers build on top of this by adding their own custom items.
I'm not saying that it's possible for a cross-platform UI toolkit to be perfect, but it's certainly possible to get a lot closer to right than current toolkits do.
Qt and GTK+ are supposed to be those portable GUI toolkits. That people end up writing additional layers above them suggests that those toolkits haven't done their job as well as they should have. But to the best of my knowledge, both Qt and GTK+ have it as a design goal to feel native on each target platform, to the extent those target platforms have a concept of "feeling native".
Any good examples where GTK+ or Qt doesn't feel native on a given platform? And, any particular reason those can't be bug reports that get fixed? Is there any fundamental reason that stops those toolkits from looking and feeling native?
It's not so obvious on Windows, but a thing written with non-native tool kits stick out sorely on OS X simply because AppKit is so much more detailed, nuanced, and in some cases functional than the average Windowsesque UI toolkit. It's incredibly rare for cross platform apps to get this right because they more often than not take the "lets do everything ourselves" route and set "basic windowslike" as the goal. In other words, lowest common denominator.
Point in case: every Cocoa text field has emacs keybinds, spellcheck, dictionary/thesaurus/Wikipedia lookup, and more baked into them. The ubiquity of these features between applications on the platform is excellent and rather jarring when it's suddenly not there (as is often the case with cross platform software).
> Point in case: every Cocoa text field has emacs keybinds, spellcheck, dictionary/thesaurus/Wikipedia lookup, and more baked into them. The ubiquity of these features between applications on the platform is excellent and rather jarring when it's suddenly not there (as is often the case with cross platform software).
That's not fundamental to portability, though. There's no reason both GTK+ and Qt couldn't use those same text fields.
Honestly I kind of wonder why nobody has written a library that acts as a thin layer around and abstraction of native UI toolkits (AppKit, .NET, GTK+, etc) instead of a monolithic do-most-things-or-everything-yourself
IUP is exactly this. Native GUI focused and nothing more to be thin and lightweight. It's small (under 800K). It's written in pure C so language bindings can be made for any language. It is funded by the same university that created Lua. Liberal MIT license.
Its weakness is it still lacks a native OS X backend. (People use GTK on Mac as a workaround.) There was an abandoned port attempt in 2010. Somebody just started trying to port it again a couple of weeks ago. (I'm sure additional volunteers/help are welcome.)
Its functionality hasn't advanced beyond OpenOffice 3.1, which it forked off in 2009. All changes since then have been tweaks. LibreOffice is six years' active development ahead of it.
Honestly I kind of wonder why nobody has written a library that acts as a thin layer around and abstraction of native UI toolkits (AppKit, .NET, GTK+, etc) instead of a monolithic do-most-things-or-everything-yourself sort of approach like Qt and GTK take. It'd prioritize feeling native over being consistent and would only write in new functionality to fill in platform gaps (for instance, .NET has no notion of an OS X/AppKit popover, so the .NET portion would have a custom popover implementation that was functionally equivalent yet adherent to typical Windows UI conventions).