https://github.com/opendocument-app/OpenDocument.core is a simple OpenDocument viewer for phones and the like where HTML webview gadgets are standard fare. It’s written in C++ and could be foundational to making something native that fulfills the same purpose as LibreOffice but using Haiku APIs instead of Qt.
It’s a long way from a document parsing library to a full blown office suite. If you want to get rid of the QT (and KDE) requirements of LibreOffice on Haiku the better way would probably be to write a native Haiku API GUI backend for LibreOffice.
As for the translator mentioned in the title: From my understanding, a translator converts from a standard format to a Haiku native one (eg jpeg to BBitmap). That means we would need something like a BTextDocument or a BSpreadsheet. Isn’t it easier to just use the open document format?
I think something got lost in the translation. I posted this in “native” because some people in this website have fetishes regarding the avoidance of ports. I have few problems with using ports, myself.
If somebody wants to bust their chops on remaking GoBe Productive or something just to prove a point, it wouldn’t be me. A translator is used to give global file format access to any application for a particular class of file formats.
Note: Adding an OpenDocument translator would allow owners of GoBe Productive to view and potentially, edit LibreOffice files from within GoBe Productive!
LibreOffice? That’s aiming a bit high.
LibreOffice’s ability to read and write ancient file formats is legendary. I’ve used it to load old DOC files that MS-Word didn’t even recognise any more.
Yes, but the app itself has to access that facility first.
Haiku still ships with an RTF translator, and AFAIK nothing uses it. There was an experimental version of StyledEdit that could save to RTF, just before Be, Inc went under IIRC. I don’t think it could load RTF back in. Getting that functionality back into StyledEdit would be the way to go (not that I have any idea how to do it!). Then one could think of creating ODT and DOCX translators. A similar process for Sum-It, and some way to move extended attributes into SQL files, and you’d have the raw beginnings of an office suite. The next step would be a scripting language (Lua?) so you could for, example, mail-merge data from People files into StyledEdit. Sorry, just thinking aloud.
Yes, and that would be great if we had the GBP code and a 64-bit HPKG in the repos. I don’t see anyone putting in work to benefit a handful of still-legal owners and an unknown number of pirated copies.
Re:Lua scripting
I submitted a patch to Luau a while back to make it work on Haiku beta 5. It is about as fast as LuaJIT but doesn’t require inline assembly in code generation due to clever usage of C++20. My patch just replaced a Linux-specific behavior with something more POSIX compliant. I upstreamed the patch so no maintenance is required for me and I’d recommend steering clear of mainline Lua. It has compatibility breakage quite frequently. Luau, as a fork, is used by the Roblox game engine so it is an attractive alternative, IMHO.
Re:Translators
Modularity is one of the things I liked better about Haiku/BeOS and the earlier Amiga-likes. If maintainability could be applied to such systems, harvesting additional file importing data from the LibreOffice codebase would be an option.
I remember testing that translator way back when… it made it possible to use StyledEdit to open RTF files.
(bit later) Just tested it with some very old .rtf files… Was able to just double click on them and get them open in StyledEdit (with formatting mostly preserved).
That hadn’t occurred to me. I was a bit fixated on exporting rtf from Stylededit. Great to hear there some life in it yet!
There was a native gui for libreoffice a while ago (done by KapiX I think?). He did a talk about it at FOSDEM with a demo. But there is pretty much no advantage compared to using the Qt one. The code is probably still available somewhere.
Indeed, it’s still there GitHub - KapiX/libreoffice_core: Read-only LibreOffice core repo - no pull request
Would expanding StyledEdit to handle documents from LibreOffice Writer be possible over time? I’m pretty sure it isn’t but maybe someone will surprise me.
Not really? BTextView can’t handle stuff that, well isn’t text. There is nothing stopping you from making a native app that can support this, just not in StyledEdit ![]()
Is the process of breaking up a monster codebase consistent with people’s desire for “native” apps? I’m not volunteering but it would be better than completely starting over, I would assume.
Is the process of breaking up a monster codebase consistent with people’s desire for “native” apps? I’m not volunteering but it would be better than completely starting over, I would assume.
Let me say that I deeply appreciate that we have LibreOffice on Haiku. I salute everyone who ported it and who keep it current.
But … the procedure for starting LO is something like this:
- click on Icon
- Go to kitchen and make coffee
- Come back and drink the coffee
- Program starts
This is not Haiku’s fault or even this port’s fault. LibreOffice is painfully slow to load even on my M2 Mac. It is descended from StarWriter, which came out as a DOS program in 1985.
We’re talking about forty years of cruft and a codebase that rivals some operating systems.
If the reason we want a native office app is to have it “flash” onto the screen instantly, then starting from scratch would be the way to go.
What are the alternatives?
- Adopt a set of external apps (QT6, probably, for some future-proofing) and haiku-fy them. Get the “hey” experts to make up some sort of scripting language to tie them together. yes, that means getting over the “Native or nothing” mindset. Sorry.
- Trim down LO to a Haiku-specific version. I don’t mean porting it with even more
ifdefcruft, but really strip it down to essentials and make it more and more Haiku-like. NeoOffice did that on the Mac. I know, the project is dead now, but it had a good decade. - Decide that we like Calligra better and Haiku-fy that instead
Any of which would be an enormous amount of work - I’m not seeing the spare capacity around here. It might be easier to just figure out a way to pre-cache LO or run it from a RAMDisk.
Or maybe I just have to learn to be patient.
fwiw there already is a calc alternative written for Haiku (though I am lacking the name atm…)
“Sum It” is the name.
Ironically, Sum-It was originally part of a BeOS office suite: “Beatware Basics”. When Beatware closed up shop they opensourced the spreadsheet but not the word processor.
How about installing NextCloud to a NAS on your LAN? WebPositive? Maybe?
I don’t think you can require every Haiku user to operate a NAS.
But more generally speaking, webapps have come a long way. Heck, I’ve even packaged a few, just for fun. None of our browsers can really make an SSB (although you can get close to it with Falkon).
But it’s supplementary. Call me old-fashioned, but when I take my laptop with me on holiday and I’m sitting somewhere far from a reliable internet connection, I want my main programs and files to be right there. I wouldn’t want to turn Haiku into a Chromebook.
