I am not a developer, only starting learning this. So… I know all most nothing about making or porting software. I hope to learn something about this. With yours help. Also, if we get more people working on this, work get finish sooner.
Ok. Lets start.
It is clear, that one must rewrite GUI and move file management to Haiku translators.
It is clear, that one must adapt some native Haiku building system (jam?)
It is clear, that one must remove not needed non Haiku code.
It is clear, that one must develop some algorithm of porting-rewriting.
It is clear, that one mus get some knowledge of doing all these things.
Rewriting the build system would be a waste of time. We have the tools to use Abiword’s current one, which will be much less work.
Here is how I would do it (but it’s just one way…)
Get latest AbiWord sources
Try to get it to compile
Find out that there are many dependencies (at least, I know they use various libraries for loading and saving files in different formats)
Port the libraries
Get Abiword to compile. Not necessarily remove the non-Haiku code, but disable it and add “stubs” (empty functions) for the Haiku implementation. For later help, the stubs can do something like print a message to the output (“I’m $functionName and I’m not implemented!”)
You will get a binary that runs, but does nothing or crashes.
See which stubs are called, and start filling them in one after another, until you get the whole program running.
Later on we can see about more integration with Haiku: using translators, etc, and maybe adding new features.
The existing port of Abiword is an old version and there are some broken design decisions in it. But it could still serve as a reference for some things. In particular, it shows how much code is needed.
For reference, the code for that is here: https://github.com/HaikuArchives/AbiWord
The history of this repo starts with an import of AbiWord sources, hopefully unmodified. Then, there are several changes to get it to run on BeOS, then on Haiku.
Well, at some point I had the UI running and could type in some text. It was very crashy however, because the people who did it didn’t take into account the threading model of BeOS/Haiku (the window and the app run in separate threads).
Thanks for documenting your research in these blogposts, it gives a more accurate view what the journey will be like.
Acutally they should have know better because the person who is maintaining it, was one of thedeveloper of BePDF … but i am not shure if he started the port :-D. At least he knows BeOS verry well
In other words, what I had in mind:
distinguish (take out) AbiWord document engine and put it in Haiku GUI;
separate AbiWord plugins in to Haiku translators.
Simple porting is not enough to get useful product.
I am not shure if you understand the ammount of work… just simply to port abiword… so if … i realky mean if we are able to port abiword…then i woul first try to look improoving abiword to an usefull stage and after this we can talk about replacing parts with nativ solutions… its not at easy as writing a new plugin wich uses translators e.g since loading and saving is directly implemented in the app.
If its so easy you are welkome to port libgsf (update the recepie) so you can help bringing at least a port of abiword closer. Btw this is something i am also learning atm.
I know very little about developing and porting software. And I write not about what I can do, but about what I want do. I like good challenge and good result. And I want good app to work with in Haiku. I need a good word processor.
TBH I would think that a better way to go would be to make a really good text view widget for haiku and grab the document import bits of abiword and then write a native app around that, possibly reusing some of the OOffice work (http://urnenfeld.blogspot.co.uk/search/label/OOffice).
libwalter is/was a collection of extra widgets to extend the interface kit. The README has a list of what’s included.
Over time, some of this was integrated (sometimes with a different implementation) into Haiku.
Actually its not really “dead” urnenfeld has agreed to provide the source, and also to publish it, when it was cleaned up (buildsystem is a BeIDE project and a some zeta specific code is in there and some more stuff todo like adding copyright and stuff to the source)
But to make it clear, it uses a modified standard BTextView so it was/ is limited to just showing text nothing else (no bullet list no margings of paragraphs and so on). It was a case study what UI elements need to be developed to make a Offficesuite happens and what could be achived with “onboard” tools.
I do not intend to beat a dead horse at all… but anyting happens with this effort? While I am not a coder, but would be more than happy to help if the effort is indeed there.
I am happy if style edit will become more user friendly. Some Icons for easy choosing font and fontsize are welcome. The dropdown-menu is just a big mess! Of course not if you use one font only…
Important would be a working PDF-translator!
P.S.: (The exporter though… working in “Scribus” is just doing its job! Printing PDFs!)…
There were StyledEdit-compatible text editors produced back in the BeOS days (Elvenedit and Hotedit, both available on my repo), so I imagine the documentation must be out there somewhere.I’ve tried looking at the attributes of a SE file, to find out how it stores text styles in file attributes, but it looks like they are all stored in one big binary blob.
But in principle, yes, a StyledEdit on steroids would seem to be the way to go.
Back in 2006 time frame, I had the Abiword 2.41? BeIde source pkg for Zeta that was being advertised with being available with the Zeta 1.5 release, I remember I modified it a bit and was able built Abiword 2.42. I got it to a point where I was able to write somewhat with it before it would crash (I actually shared a copy of it, the day that Zeta ceased). When Magnussoft pulled the plug on Zeta, I got highly discouraged as Haiku was not mature at that time, and I gave up and went back to Linux. I probably have somewhere on a disk, the BeIde source pkg,and maybe the one I made with changes. I don’t know if Paladin would be able to build it, as I never tried.
… so i geuss you can only estimate the code needed for the “base functionality”
because the person who is maintaining it, was one of thedeveloper of BePDF 