Honestly I would like to know what the overhead is in continually maintaining a custom cross platform UI toolkit for one application is versus just rewriting the UI using an existing framework like Qt. It seems like an awful lot of effort must be duplicated here.
> just rewriting the UI using an existing framework
This would be one of those cases where "just" is a word meaning "with tremendous difficulty" ;-)
The OOo, hence LO, codebase is deeply entangled in VCL. Separating it out would mean a total rewrite, and basically nobody's going to pay for that to be done. There is arguably duplication, but VCL was started decades ago, so it's less work to maintain what they've got than it would be to throw it away and start over.
So what they actually do is (1) improve VCL for local purposes (see Michael Meeks' 5.0 summary, where he discusses work on the VCL event loop that's made LO 5.0 feel much snappier) and (2) polish up the backends, per this PDF.
In the general case, when you find yourself asking "why haven't they just ..." there's probably an actual good (-enough) reason.
If you really want to write your own UI, this is precisely what LibreOfficeKit is for: the LO devs are busy working on a completely new Android UI using LOK to do the hard stuff. (See discussion lower in this thread.)
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.
These days I do the same: I have an abstraction layer that can back-end to Windows, GTK, Qt, and for a time, Cocoa.
A huge advantage is not needing those run-times on Windows, which comprises 90-95% of the desktop market still. On average, Qt is around 40MB of DLLs. Even if you: compile it yourself with -Os, use a 40-line configure to disable everything possible, and upx --best the resultant DLLs (or binary if you statically link), you're still looking at ~5-10MB.
You can say that's not much today, but say you do one release a month at 100K downloads (which I did), that's 500GB-1TB of bandwidth gone, just for a run-time. Now imagine 1M, 10M downloads. This is a big deal when your tool is only ~50-200KB by itself, and you are giving away free software without ads.
Another problem is that Qt may use the native theming engine, but it most certainly doesn't use truly native widgets. Because it needs to do a lot of stuff the native platforms can't: like its CSS-style theming. When you move beyond the absolute basics, the seams start showing up. It's especially bad on OS X.
Next, there's the bugs. I was constantly encountering major bugs in Qt, and for Linux at least, you can't just patch Qt. You have to wait for the next distro release cycle before they are fixed, so you end up with dozens of platform-specific workarounds, which really undermines the point in the first place. You can ship your own 150MB of Qt source, but no Linux distro will use it for their packaging.
If you have your own abstraction, you can go in and fix bugs immediately.
Lastly, it's the portability. Toolkits like Qt try and do a trillion things. That's lovely, sure. But if you know you'll never need those things, it's nice to limit yourself to a smaller subset. That keeps the API simpler and cleaner, reduces the amount of possible bugs, and makes it substantially easier to port your applications to new platforms.
Imagine a new platform comes out, and either Qt is discontinued or uninterested in it. Porting Qt yourself would probably need 3-5 man years of work. But porting your own basic abstraction layer could be done in 3-5 weeks instead (the time is relative to the complexity of it.)
All this said ... I'd much rather have had someone else write the toolkit abstraction for me, but I couldn't find any that I liked. They were all too big, too small, too unportable, or too difficult to use.
Has anybody tried a different approach and just drew their own widgets? Kind of like what Sublime Text does I suppose. If so, what were the experiences?
I'm pondering making a port of LibreOffice without the Java dependency (to avoid the runtime and language model overhead) with my own custom user interface/UI framework.
From this I guess I need to take and port SalInstance and write my frontend for it.
Just because writing a whole new GUI would be a huge undertaking.
I mean, if you need to do it, don't let me stop you. But I don't think it makes sense if your goal is simply "lighter weight" (I don't even know what that means exactly)
I might not need to. I just have a feeling that layering my existing framework over VCL would mean a lot of redundant and unoptimized things happening during runtime.
I basically just want LibreOffice for it's mature support for Microsoft Office files. I think if I can just have that as a standalone library that would be ideal.
That might be better for compatibility. Except the mono/coreclr runtime requirement adds a bit of complexity. I'd have to port and optimize that as well as call into and from C# code. So for right now it's just not a good solution.
Also, I'm not sure if it can be used to open all MS Office files or just Office 2007+ or any files for that matter.
Look at the LibreOfficeKit API and the sample gtktiledviwer application, very easy to use (that the base of the Android and LibreOffice Online application), now all you need is writing the actual UI…
LibreOffice descends from StarOffice, an MS Office clone by a German company that was bought by Sun. When Sun bought it, they bolted Java onto it because they were Sun and they bolted Java onto everything, but Java's not integral to the operation.
Same here, hence my question. Probably because Sun bought Star Office, IIRC bundled it with SunOS and with the Java heavy marketing of the time I thought it was a Java program, even though SO is .. old : https://en.wikipedia.org/wiki/StarOffice#History
