
Porting LibreOffice to GTK3 [pdf] - tomkwok
http://www.skynet.ie/~caolan/guadec2015/GUADEC-2015-GTK3.pdf
======
femngi
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.

~~~
TD-Linux
Libreoffice looks far more native than Qt does on Windows or Mac IMHO. So it
still seems to be worth it.

~~~
kitsunesoba
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).

~~~
byuu
> 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.

~~~
CyberDildonics
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.

~~~
byuu
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.

------
ronjouch
See also this nice summary by Michael Meeks of under-the-hood changes in
LibreOffice 5.0: [https://people.gnome.org/~michael/blog/2015-08-05-under-
the-...](https://people.gnome.org/~michael/blog/2015-08-05-under-the-
hood-5-0.html)

------
bobajeff
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.

~~~
alexlarsson
Just build with --without-java

~~~
bobajeff
Thanks, now the only question is how hard will it be to use my own UI
framework instead of VCL (to avoid complexity and overhead)?

~~~
TD-Linux
I feel like if you have to ask this question, the answer is "too hard".

~~~
bobajeff
Because building a frontend and other missing components from scratch is hard
or because the backend is tied too closely with VCL?

~~~
TD-Linux
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)

~~~
bobajeff
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.

~~~
icebraining
Microsoft has released an SDK for reading and writing Office files, under the
Apache 2 license: [https://github.com/OfficeDev/Open-Xml-
Sdk](https://github.com/OfficeDev/Open-Xml-Sdk)

It's in C#, but it builds on Mono, and it's probably still easier than hacking
LO to act as a library.

~~~
bobajeff
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.

