I´ve never used or even seen Gobe Productive so I have no knowlegde about what was special about it. But before embarking on writing a new office suite for Haiku completely from scratch it would probably easier to write a native Haiku backend for LibreOffice, so we could use that instead of the KDE backend that is used now, and therefore removing the dependencies to the KDE libs.
Personally I´m not that concerned that we use the KDE backend, I´m just happy that LibreOffice is available on Haiku.
1 Like
Re: LibreOffice
I don’t know who you want to hire to work on that monster.
Re: ODF on a new software
Once we get roped into using ISO standard file formats, we also get roped into using all the features of those formats so we might as well forget the custom code and use LibreOffice as-is. IMO the whole advantage of using custom code is to make something system dependent that takes advantage of OS features entirely unlike LibreOffice.
1 Like
Something I forgot to mention in my previous post was that LibreOffice and Scribus are GPL licensed code while SumIt is a 4-clause BSD/Creative Commons hybrid license. Most of Haiku is MIT or BSD licensed so LibreOffice and Scribus’ code cannot be used directly by the OS for reusable code. The licenses are legally incompatible. One of my goals for this project is to make reusable code that can be adopted either by the OS itself or used as example code. If it uses a more modern programming language like Rust or Zig then that’s an educational bonus for me as a programmer.
Using the Textview from Haikudepot would be a good starting point for a word processor.
The “only” thing missing there is a posibility to add non text Objects and “laying them out” :).
But i also would say its the best to have a own Datafile format but have a good translator to and from Iso Standards growing with the level of support of the word processor.
It would be nice to have embedded document framework first like in GobeProductive. Similar embedded document embedding system is available in Blackbox.
3 Likes
Blackbox can be used as base for developing office suite. It has formatted text editor but it is currently very limited, it support text style, paragraphs, tab positions, links and embedded objects.
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?
BView embedding capability is limited. GobeProductive use its own embedded object system, BView is used only as root container.
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.
2 Likes
One could ponder porting Apple iWorks or use Google Workspace for Haiku… Amiga has Abiword, Gnumeric, and GIMP ported.
I very much like the Calligra approach:
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.
2 Likes
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.
1 Like
NeoOffice 2017.27:
1 Like
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.
1 Like
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).
1 Like
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.