8 ms·
Porting LibreOffice to GTK3 [pdf]
- ronjouch 11y agoSee 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-hood-5-0.html https://people.gnome.org/~michael/blog/2015-08-05-under-the-...
- bobajeff 11y agoI'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.
- agumonkey 11y agoHow much of Java is needed for LO ? I oddly believed it was limited to spreadsheets formulas..
- grandinj 11y agoNothing. Java is only there to run a couple of extensions, but none of the core functionality requires it.
- ZenoArrow 11y agoInteresting. I was under the impression it was mostly written in Java, looks like I was wrong. What's the majority of the code written in? C? C++?
- alexlarsson 11y agoc++
- agumonkey 11y agoSame 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 https://en.wikipedia.org/wiki/StarOffice#History http://toastytech.com/guis/sol10staroffice7.png http://toastytech.com/guis/sol10staroffice7.png
- thristian 11y agoLibreOffice 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.
- alexlarsson 11y agoJust build with --without-java
- bobajeff 11y agoThanks, 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 11y agoI feel like if you have to ask this question, the answer is "too hard".
- bobajeff 11y agoBecause building a frontend and other missing components from scratch is hard or because the backend is tied too closely with VCL?
- TD-Linux 11y agoJust 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 11y agoI 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 11y ago
- femngi 11y agoHonestly 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 11y agoLibreoffice looks far more native than Qt does on Windows or Mac IMHO. So it still seems to be worth it.
- kitsunesoba 11y agoLibreOffice 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).
- pdw 11y agoThat's what wxWidgets is supposed to be, I thought.
- byuu 11y ago> 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.