Indeed, there are two different VCL backends: Qt5 and KDE5. The latter screenshot uses KDE5 VCL backend which is much more complete.
great work, much appreciated! Is there a blog post on how you did it, what challenges you faced? I remember back in the day an effort was started and with the QT port things got a little easier, right?
Definitely need to install Haiku somewhere natively nowā¦
Wow, really amazing! Great work!
A questions. I remember that there were efforts to port LibreOffice/OpenOffice to Haiku many years ago and the comment was, that its very hard and probably will be easier to make new Office, than port OO, because is complex like entire OS or even more. Is this port a finished effort from those years ago, or is it new one? Does something happen, that it was easier to port this time, than 8 years ago? From the old days Ive got feeling that only Chuck Norris can port LibreOffice, and I havent saw him on this forum.
It`s a lot of ports at one time: Qt, now LibreOfficeā¦ While there was near nothing for last years.
Excellent news! Thankās for your hard work.
I can write a blog post about the effort, although the FOSDEM presentation covers it for the most part.
The first effort was by oco and this effort is completely independent. He started with OOo4Kids, since it was stripped of many dependencies. At this time LibreOffice didnāt exist and I remember from compilation instructions, that OOo even had itās own build tool (dmake). We didnāt have Java port and OOo depended (heavily?) on that. LibreOffice did a great job of rewriting all of this to GNU make and stripping Java, so that made things easier.
I think the main issue was that LibreOffice requires a lot of libraries. I see people blasting package management for making system unnecessarily complex, hard to tinker with, etc. Let me say this: I wouldnāt start working on this port if package management didnāt exist. I still remember a mess with gcc4 libs being picked up by gcc2 for linking which would throw mysterious errors.
Back to the libraries: porting them was pretty easy but tedious. Most of them compiled out of the box thanks to POSIX compatibility, but some had, for example custom library detection logic and they were PITA to get working (langtag, ixion, orcus).
Now to the VCL backends: currently there are two native backends in progress. First one [1] is completely BeAPI based, for LO 5.3 and that is what was presented at FOSDEM. After my presentation I got feedback that perhaps it would be better and easier if we took cairo backend for rendering and BeAPI for the rest, since VCL is kind of a mess. I started working on that [2], but it didnāt go far - rendering works fine since cairo handles that, but windows donāt even refresh properly on mouse move.
The main problem with implementing BeAPI based backend is Common Text Layout which ensures there are no document rendering differences between different OSes. It also handles right-to-left text, etc. I didnāt manage to figure out how to implement it. but the main issue is that we donāt have APIs for rendering RTL languages. So back to using external libraries like harfbuzz. That makes native backend kind of pointless. (EDIT: harfbuzz is not a bidi library) Now that we have Qt port, cairo is also pointless IMO since itās almost the same thing. (Using external thing to interface with OS.)
Some answers to this are above, additionally:
I donāt think thatās a worthwhile endeavor anymore.
- It looks pretty native now, and even with BeAPI backend you wonāt get much better - there is still VCL as a layer of indirection.
- (speculation) Iām afraid that LO might even drop native backends in favor of Qt. That would be a lot of work wasted, especially with our strained resources.
Iād love to see native backend, but I think my time can be better spent elsewhere (like WebKit, or fixing bugs in the OS itself). If anyone wants to work on it there is a rough diagram of how things work in BeAPI (5.3) backend [3].
Ending thoughts:
When I started working on the port (2014) there was only an idea on TDF wiki about using Qt for GUI.
IIRC Qt/KDE backend is sponsored by City of Munich which wanted better integration with KDE.
I believe a 1 month full-time contract would be enough to implement a somewhat working native backend, with another month for polishing.
And finally: Iām very glad to see LO finally working! Thanks diversys and 3dEyes for your tremendous work on Qt and KDE. 
[1] GitHub - KapiX/libreoffice_core: Read-only LibreOffice core repo - no pull request
[2] GitHub - KapiX/libreoffice_core at haiku-6.0
[3] LibreOffice for Haiku - kacperkasper.pl
14 Likes
Iām not seeing this happening. Years of effort has been invested in the GTK+3 backend, which is only now getting to a polished state.
For reference:
1 Like
This is pretty impressive news. Congrats to all involved. Now all the questions about when this or that office application will be ported āto make Haiku usefulā will not take up space in the forum database.
Will have to check out the FOSDEM video for this. Meanwhile (not to pour water on the parade) - we can port:
Darktable
Gimp
Inkscape
Davinci
Krita
Blender
Lightworks
Natron
- to Haiku on the Odroid XU4 platform! (kidding).
Great work guys !
- Ron
1 Like
Krita is at least already ported 
1 Like
Yuuussssssss!
Thanks for the tip!
Now I see blender is there too. Obviously, Iāve been away from Haiku for a while ā¦
1 Like
Donāt forget VLC.
1 Like
TBH, I think a maybe 25-50% longer version of this reply would make an excellent blogpost, especially the bits about how package management made this possible when it wasnāt before, and then the rationale behind using the Qt port rather than pursuing a native backend.
3 Likes
Great work guys! Works just fine on my Thinkpad. Great to be able to use the same office suit I use at work on my main system
- Darktable : depends on GTK
- Gimp : depends on GTK
- Inkscape : depends on GTK
- Davinci : ??? which one ??? Resolve is not open source.
- Krita : port already exist
- Blender: port already exist
- Lightworks : not open source
- Natron : looks possible.
3 Likes
It allways crash then i change the window size.
I downloaded the latest stable GTK source and ran ./configure. Seems like all dependencies except cairo-gobject are met.
Pardon, Dr. Google:
At the start (the selection window), it sticks out of the screen on the left. It does not look as good as it did in the preview, it leaves artifacts on the monitor and generates errors during the attempted application and exit.
The versions boost163, boost164, boost165 and boost166 are available ~ all are activated. The main thing, LO takes the right one ā¦
The tips given here (above) have not all led to the boost165 (missing) being installed. Only the search for it showed that the āmissingā boost165 (also) was already in the list, but apparently was not found (Install, pkgman)!?
Manually it worked (apparently). Not usable, but LO 6.2 is still alpha, not even beta ā¦ Does that make sense? To try porting a malformed (alpha) application?
Polli
It is a bit more complicated than just get the dependencies met.
It is certainly that. Unfortunately, I (and others) keep forgetting that Haiku itself is also alpha (R1 / Alpha 4.1) and that the nightly updates are for everyone, and especially for developers. There are still many dependencies that need to be investigated.
While waiting for Haiku Beta I miss (also) OS / 2 ā¦