Porting LibreOffice to GTK3 [pdf]
skynet.ie
skynet.ie
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).
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 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.
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.
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?
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.
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.
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'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.
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
http://webserver2.tecgraf.puc-rio.br/iup/
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.)
https://www.mail-archive.com/iup-users@lists.sourceforge.net...
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.
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}.
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.
https://web.archive.org/web/20120429043003/http://byuu.org/a...
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.
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.)
From this I guess I need to take and port SalInstance and write my frontend for it.
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 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.
It's in C#, but it builds on Mono, and it's probably still easier than hacking LO to act as a library.
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.