GoBe Productive on Haiku


#21

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.


#22

I would be willing to help. But am not really reliable… :frowning: :wink: and am i not such a good programmer.

Just gained back my interest to haiku (thanks to package management merge).
So i still have a big ToDo list from when i last time dropped haiku. (bring projectconceptor to beta level, rework scripture guide and maybe later make rundumvideo compile… )

But i could offer at least like 1h - 2h per month, i know it is not much but i am very busy at the moment. Or at least for such a project i would donate some money.
(need to check where my bachelor thesis is, wich i wrote in gobe :smiley: )

So my dream would be
Remove the spellchecker code (disable this feature) and replace it later with aspell or something like this…

And make the whole software open source…


#23

What are the possibilities for open sourcing GoBe 2, and picking up development again, since it is already compatible with BeOS/Haiku? It sounds like GoBe 3 would be more trouble than its worth to get working.


#24

Has anyone had any contract with the new owner?


#25

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.


#26

Good news from Haiku side: Stippi has made several fixes to our app_server to make GoBe Productive work better on Haiku. This includes the improved clipping code (made for WebKit, but GoBe also makes use of it), as well as fixing various bugs with scaling, and improving the font rendering.

Even without access to the source, we can make this app work better, and this will make it easier for other apps (both old and new) to run.


#27

I beleve that the GP2 code are gone/lost.

With the GP3 code perhaps we could recreate the translation of dokuments the same way images are done and have that on the OS side.


#28

Don’t need Gobe 3 or anything to be able to do that. Those can just be made into a new framework for that as it is.


#29

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 :slight_smile:


#30

I believe that GoBe did just that. The translator translate the other files to there standard. As you say it’s a lot of different information other wise.

If we hade the code even the GoBe 3 then part of it could become the framework.

Perhaps not part of the OS but if that part of the GoBe would have been free then the office could live on same way as some of the picture applications does :slight_smile:

//Fredrik


#31

don’t web browsers work this way?


#32

Just making the point that you don’t NEED Gobe to do that at all… I have no issue with gobe becoming the framework to wrap that with.

Though, you CAN, STILL write a framework to do exactly that either way without it. It’s not impossible at all. Yes it’s a lot of work. With translations from say an image heavy document to text, you have to assume that yes you will loose the images. That’s not really a counter argument as text doesn’t support images period. Either way though, I’m not attempting to be argumentative about it. I’m just pointing out simply, if gobe doesn’t work out, it can still be done outside of that. That’s all :slight_smile:

Though my biggest point to making an actual framework for those document handler is the simple fact that any application can then take advantage of that. Of course there are always caveats to how it has to be used, what can be translated to what. i.e. A powerpoint type file can’t be translated to an xls type because the formats are not compatible (the powerpoint data doesn’t adhere to a table format / spreadsheet and isn’t supposed to).


#33

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.


#34

On top of Windows, Mac OS and OS/2 it was also available for such specific OS as MorphOS: http://www.titan-computer.com/html/papyrus_screens.html#popup

Therefore your idea makes sense. Maybe someone from Haiku dev team could contact the devs behind Papyrus Office?


#35

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?


#36

Why should the Haiku devs handle this? If you want a port to Haiku to happen what you need is lots of users sending mails to them, to show them there is interest in a port.


#37

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.


#38

[quote=spinach]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?[/quote]

There were linking issues I didn’t care enough to try fix last time I tried to build kdecore (which calligra requires). The dependencies for calligra (half of KDE and then QT as a result) are fairly hefty.

Libreoffice is another level of complexity altogether.


#39

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?


#40

I would definitelly love to see Gobe on Haiku in a maintained manner.

It even runs on a current nightly (r47144) fairly well.

I have just created an hpkg package and runs absolutely fine.

(for the record, I do have a full legit copy of Gobe 2.0.1)