GoBe Productive on Haiku

This would be great and I hope that the agreement can be revived.

A couple of questions, which likely only the (four) developers could answer:

What were the implications for further developing Productive for Haiku - say a R3.5, R4, etc?

Did GoBe reserved their rights to back-port into their Windows version any improvements to the base code made by the Haiku team? If so, and without being too greedy, could Haiku secure a small "royality" (steady stream of funds for Haiku development) for such back-ported code?

Java already has a port of one type. Feel free to port LibreOffice. Outside of that, I myself would prefer a native app over java any day of the week. More efficient, runs better, faster, plenty of ups to that side of things. Gobe was very good back in the day. Aside from that coming back up, it would definitely need some updates hence.

That's a very valid point; I myself had looooong forgotten. That's just another testament to the point though ;)

KOffice is the way to go, then ! ;)

http://tiltos.com/drupal/node/17

Just like Softmaker Office! http://www.softmaker.com/english/ofwpress_en.htm

Thanks for the clarifications.

Given that Productive 3.x would essentially have to be "back-ported" to Haiku, it would appear that a native office suite for Haiku would have to start from scratch since the code for Productive 2.x was locked in the code-safe.

This is rather unfortunate.

Which one will be easier to do? - Re-creating (with improvements) the API and object model underlying Productive or porting Office which is based on foreign API and object model?

Office as a native app / bunch of apps is great. I wish we had native, up-to-date office suite with open license. In the meantime there's online stuff like Google Docs, Office.com and some others (I know one that even could be run on localhost with web interface).

Having fully featured WebKit port and native WebPositive browser or ports of Firefox/Chrome is more important today than offline Office suite.

Let me correct a few incorrect notions about Gobe Productive and the state of the code. I have been in touch with Bruce Hammond and had discussions about getting GP running on Haiku. First of all, although Gobe is no longer a legal corporation, the source code to GP still belongs to the original members of the company. The intellectual property is not in limbo and doesn't belong to that Indian company. The Indian company licensed a Windows port, that's it.

The main reason that GP3 was not open sourced is because it contains commercial 3rd party source code. Most of that code is the spell checker code. That's why the code cannot just be open sourced and given to Haiku.

Other issues with running GP3 on Haiku: the OS changed, the compiler changed, the version of C++ changed. About 2 years ago Bruce spent a day working to get the code to compile on Haiku. Apparently there are significant changes needed in most source files just to to get a compile.

Based on discussion at the time it would require many man-months of development time. Many as in 3 - 6 solid months, minimum.

GP was the largest, most complicated and sophisticated application to run on BeOS. There is a ton of code involved. Lots of code, written by serious developers.

So where does it stand? I was working through some intellectual property issues with Bruce on this project. He is involved in other development projects and doesn't have a lot of time to put into this. I'll poke him again and see if I can stir up some interest.

AndrewZ,

Thank you for clarifying the state of the GP3 code and your work in trying to get that code where it could be open sourced. Seeing as Bruce Hammond is very busy maybe these suggestions will help.

1. Ask if it is possible to open source GP2 for BeOS, so we have something to work with for now.

2. See if it is possible to replace the commercial 3rd party source code (spell checking and other) with remarks/placeholders so GP3 could be open sourced, as is, so Bruce's time isn't tied up.

This works for things like a Picture or even vor some basic text. Because then you can say.. The Input of the translator is a file or a stream an the output will be a Bitmap.

But with word or compareable documents like .odt .pages or .awb its not so easy, because it contains Tex, Pictures, Tabels, Page and formatting information or even macros.

So if you just Translate it into text, all the page, formating and pictures stuff get missing, if you translate it into a Bitmap then you just can see the "picture" of the document but in wich resolution do you want to view it? And also to process the whole file (layout, arrangement, text flow and so on) need to be calculatet wich is actually one of the biggest parts of an office suite. So if you write anyway all the necessary code... then why should we put it all in an translator and not write a Officesuite?

But again then its becoming soo complex that´s it not easy manageable.

The only idea would be that such a translator would return a BView or a BPicture (i doupt that BPicture is komplex enougth to archive this)
But again you need all the layout, drawing code and so on so that it would make sense to go directly for an office suite e.g. like GoBe (prefferd) or Abiword or Libreoffice

So the idea of a Framework dont work from my point of view but i am open to any other suggestion or correction to my view. Or let GoBe become the Worprocessor Framework for Haiku :)

don't web browsers work this way?

With the likelyhood of Productive being resurrected for Haiku being close to zero, would there be any merit in approaching the Papyrus Office team (ROM Software) for a port to Haiku?

Nibble and small and already existing for OS/X and Windows. From what I gather, their first release was for Atari TOS and for a few years an OS/2 version was also available. So, they could have a decent OS-indepedent code which, in theory, would be somewhat easier to port than something first designed for OS/X or for Windows.

Just a thought.

with qt5 coming to haiku through gsoc and kde 5 due to release this june, wouldn't we already have a friend in the calligra suite?

how possible is it to port libre office?

oh no, i'm not suggesting that someone should, just trying to figure out where to start, should i suddenly find myself with some free time to learn the system some more.

from the language at kde.org, kde 5 is broken down into separate libraries (kde frameworks) that depend, with just a few exceptions, solely on qt5. that should make things easier to port, but i guess we'll see come june.

what hampers porting libreoffice?

I was a big fan of GobeProductive when it came out in 1998, way ahead of its time back then.
However, it's more that it has a lot of nostalgia going for it, but it's 2014, time has moved on, and I think there are now better alternatives in the end, where CalligraOffice has the most similar spirit I think (everyhing is lightweight, live, approachable, easy to use, and has a modern, task centric look&feel), at least looking at the current office solutions landscape:

• KOffice/now Calligra has a Pages-inspired and modern, lightweight UI but needs some more work on that imho, also tends to crash here and there, but has decent OpenDocument support and is *very* fast and comparably small.
• LibreOffice is so bloated and has long standing bugs, just like MSOffice (which seriously improved over LibreOffice since the 2010 version, I must say) and the new Renaissance UI is still not there, but it is the most comprehensive free office suite out there.
• Softmaker Office is quite impressive and fast, but I didn't have enough time to really work with it, also it's not free but a port may be possible under similar conditions as for GoBe, and the code as well as feature set is more than up to date
• there's Papyrus, but only the authoring tool "Papyrus Autor" is left of it, but that seems pretty impressive and would be cool to have on Haiku (as a creative OS:)

So from what I gathered, a modern version of Calligra suite on top of Qt5/KDE5 seems quite feasible, as KDE5 is - as someone noticed - very modularized and modern, so porting should be easier.

As for translators, I think they'd still make a lot of sense, but only in a functional, practical way, translating office documents to text for indexing and searching, and for generating thumbnails for a preview in Tracker. So this would combine both ideas, extracting text content and generating images, in a useful way imho.
But we can use the excellent POI library for that, no need to port GoBe here.

Wouldnt be it less time & resource consuming if we make the same approach that kaliber (from TILTOS) did? Just port x server and needed components to create some kind of compatibility layer for heavy linux apps to haiku? tiltos package could come with hpkg package

http://tiltos.com/drupal/

Please inform us about progress :D

I'm afraid that would be a waste of time, considering how out of date it is. If someone is able to port a program, best it be an up to date piece of software, to make it worth their effort.