Blackbox looks interesting but I also see it is using a cross-platform framework. The GUI might be more natively Haiku than LibreOffice but I’m still concerned that this is not Haiku-specific enough to be a good tutorial piece for teaching Haiku programming. As a bonus, it seems to be written in an Oberon variant and Pascal variant, however.
I personally would prefer the TextView gadget as Paradoxon suggested or a variant thereof since it is Haiku from the ground up. It will also allow more integrated reuse with the OS. If it can be made to link text to another instance of itself as a means of making text flow from one column or page to the next, it would upgrade from a word-processor to a more modular desktop-publishing app.
The pictures and vector art could also use some of the same code as the Haiku icon rendering for an added layer of integration. Of course it would need to embed PNG or JPEG images as well. Is there an ImageView gadget in the OS or on HaikuDepot that would work for that also?
Hmmmm… It seems we’re drifting off-topic from the original post. Should I rename the thread or should we start a new one? It’s established that the original Gobe Productive source is unavailable and may not be useful in a new project.
If so, what should the topic be or the new focus? Is making a competitor to LibreOffice or others more important to the rest of you than making an open-source example code for Haiku?
I don´t want to hire anybody because I´m happy with the current office suite situation on Haiku.
Besides that, what makes you think the native office suite codebase would be less of a “monster” once it halfway reaches feature parity with LibreOffice?
LibreOffice is a huge codebase in part, because it has a large following on Linux and a large team of developers working on it. From my experience on the Amiga platforms, the modular GUI plugin system of LibreOffice is difficult enough to work with that a cut-down version of the OpenOffice fork called OO4Kids couldn’t even be ported to AmigaOS 4.1 despite having an eager following and actively developed codebase. LibreOffice doesn’t even exist on AmigaOS 4.1 because of all the dependencies it requires. On AmigaOS, it is established that bringing up-to-date of old 90’s vintage office software is more practical than trying to port a monster project that was originally written for Solaris and Linux first.
In short, the only reason that LibreOffice works on Haiku and doesn’t on AmigaOS is that Haiku has a vaguely POSIX compliant architecture that can run the Qt framework.
It is clear and simple, if reduced to the most common needs, and still powerfull if expanded.
That would be nice to have with a lot of drag/drop support in Haiku.
On AmigaOS 4.1, there is an emulation layer for the X-Server that allows those 3 programs to work called AmiCygnix. It allows some interoperability with Linux code. iWorks was what I think new code for Haiku could represent. A system-conforming example code that other applications would be judged against.
Thanks for putting up with my rants. I’ve started a new thread about how a style-guide should affect the Haiku ecosystem: What makes Haiku software special so maybe I can diffuse the whole idea of natively written code over there.
It is possible to make LibreOffice kind-of Haiku native. See NeoOffice, it is a LibreOffice fork specifically for macOS.
Still, I reckon, that starting a new project from scratch and plugging in document translation libraries would be less work than trying to tailor LO for Haiku.
I am probably wrong, or maybe stating the obvious, but I feel like the “haiku way” of doing an office suite might consist of:
A native internal format for text documents, spreadsheets etc
An API for creating, rendering and editing them
Disk formats based on converting the internal format using the translation kit
A GUI hanging on top of the API
Not exactly ground breaking ideas, but it would integrate nicely and allow embedding of documents into other documents and apps fairly neatly I would think. It’s definitely a silly amount of work…
I agree with the view that there are much bigger fish to fry if you want to work on a big task that can bring a lot to haiku… helping on webpositive, GPU support, hardware video decoding and virtualisation come to mind. But if working on this can scratch an itch for someone (to paraphrase @Zenja) then it could be really awesome.
These surely do have precedence. But to note, ported Haiku software are generally slow, and hard-lock occurrences are just too often. Often enough to give a very bad look on the general system.
I do still doubt though, maybe these locks and slowness are something inherent in the design of Haiku.
Just as a sidenote: Besides GP we also had BeatWare’s Be Basics. The earlier mentioned “Sum-It” was the Spreadsheet part and “Writer” was the Text editor (very simple, but enough to write a letter).
Yes and one part would be to make a “copy” of BeOS/Haiku translation kit to handle office files same way as images… Gobe had that, except no other program could use that.
I wouldn’t say it is. Yes, there is a lot of cruft, but it seems nowadays everything just goes through Skia anyway, so all you need is to give it a window it can paint on, and figure out how to marry the application event loop with Haiku’s threaded nature. Then if you want a native look a bit more work would be needed to implement the necessary methods. It’s not that hard, it’s just time consuming.
If you google Marc Verstaen, you can find his Linkedin profile quite easily (and it mentions Beatware, so it is the same guy.)
Did anyone ever follow up with him? Maybe the source is not in his possession? I mean, writing something and keeping the source are two different things. I wrote a Pascal UI framework early on for BeOS and I think the only reason I have it still is that I am a pack rat. But on the other hand, I also ported a lot of SDL games to BeOS and I don’t have any of the source anymore, and worked for a lot of companies any probably don’t have any source for any of the products I worked on.
