Gobe Productive 2.0 (clone)

Development
22

Well, before I let the subject drop off the face of the map, let me throw out some reusable code ideas:

A rich text editor gadget that can column-wrap text to another instance of itself would make simple DTP style editing of documents possible though Scribus is enough of a DTP for professional use already.

A metadata-aware file BFS derived media database that could be expanded to a serialization file format and network filesystem would make a nice feature. It wouldn’t be SQL style but would complement existing file formats like Oasis OpenDocument XML file formats do for LibreOffice. The downside is the requirements for this are vague and LibreOffice uses Zip to compress its XML already.

About the only thing that spreadsheets do that sets them apart from databases are the charts and graphs being generated more easily and having a generic user interface. What would happen if a GUI builder existed that could make a spreadsheet into a more specialized database format like the BFS idea? Like I alluded to earlier, it might not kick SQL to the curb but maybe a MongoDB/DocumentDB wrapper would be useful.

Other than that, the replicant idea works for me.

Edit: I see MongoDB Compass is available for Node.js so that might help.

23

At least port it to 64 bits. I tried but something is still wrong.

1 Like
24

I bought Gobe Productive, way back in the day. I used it religiously because BeOS was my main OS and I really liked Productive.

These days, I’m a bit of a weirdo in that I usually use the word processors that go along with the operating system: Word for Windows, and Pages on the Mac. Unless I’m doing creative writing, in which case I use Scrivener which is more tuned for such things.

If a someone, or a group of someones, wanted to make a Haiku native word processor or suite, I would not be the one to tell them they shouldn’t. I wouldn’t tell anyone not to do anything, really. You can stick with the status quo or you can take a risk and see if something better can come along.

After all, to most people, working on Haiku and using it is generally considered foolish. There are three major operating systems that are much better supported.

But people work on it because they want to. People use it because they like it enough to use it. Why would an office suite be any different?

On the other hand, I would not be of much use for such a project because I have no desire to pick up C++ again. Maybe when I retire an can spend more time re-learning all of it, but not these days. I would, however, be more than happy to purchase such a thing if the price was in line for what the product offered. I wouldn’t say no to open sourced and free, of course, but I have no problem supporting software if that’s the direction it took.

Honestly, if Gobe were to suddenly come back and make a 64-bit Haiku version, I’d buy that again, too.

So there’s my unasked for, and probably unwanted, two cents.

3 Likes
25

I was also wanting to look at Sum-It (the name seems to have a dash, which is easier to read.)

Is the only source this SourceForge page? Feels like a first step for updating Sum-It might be to get this source into Github, maybe under HaikuArchives. There are some bugs in the SourceForge project which are probably still relevant as well.

2 Likes
26

Agreeing with @apgreimann. While a native Office Suite would be awesome, maybe webcam support, USB networking, USB audio, ARM support, and other things might be more deserving of limited developer time. But people are going to work on what they want to, which isn’t a bad thing.

2 Likes
27

The Depot version links to this one: GitHub - beos-zealot/OpenSumIt: Sum-It is a native spreadsheet for BeOS.

1 Like
28

Looks like it’s at haikuports: https://github.com/haikuports/haikuports/blob/14c2cab5428145b93232cb69683a67bbe68a9f06/haiku-apps/sum_it/sum_it-0.2beta.recipe

29

Thanks for the links! Having existing software to debug isn’t always as bad as starting something new. I might get a chance to look at Sum-It later.

2 Likes
30

Anyone here have contact with any of the Gobe developers who could offer some insight?

31

Here’re the names of (some?) ex-GoBe engineers, you may try contacting them via Linkedin or other ways:
Scott Holdaway
Bob Hearn
Tom Hoke
Bruce Q. Hammond
Scott Lindsey
Kurt von Finck
Ben Chang
Carl Grice
Joël Spaltenstein

2 Likes
32

Here’s some additional information:
https://www.osnews.com/story/1520/exclusive-gobeproductive-to-be-released-under-the-gpl/

33

Follow up: https://www.osnews.com/story/2308/obstacles-leave-gobeproductive-closed/

34

That would be some of the things that would have to be sorted out. I was aware that Gobe licensed some third party libraries to implement some functionality. We just need to figure out how such can be replaced where needed.

35

Yeah as SamuraiCrow says, the GPL release of Gobe Productive did not work out.

Also I believe some people had looked at the GP code at some point and after all the efforts to port it to other systems it had become quite a mess. I think people can overvalue code sometimes, though maybe that is a bit of my developer tendency to want to write something new.

For example Be released the Tracker and Deskbar code, and they work, and we have added on to them, but honestly the code is not great and both could use some major refactoring. Efforts have been made with Tracker to refactor it and break up the god class PoseView but those have generally stalled. Sometimes software can be good and work well but the code is not great. I suppose much of BeOS is like that. But for an open source project the code is kind of part of the output of the project and ideally it should be clean, well written, well designed, etc.

Of course it would be better to have the Gobe Productive code, but if we can’t get it maybe just being inspired by its ideas, UI design and maybe even the file format would be nice. On that note has anyone inspected the .pve file format?

Also regarding the history of Gobe Productive and its spiritual precursor ClarisWorks Bob Hearn (mentioned in a previous post) has a nice history page: https://groups.csail.mit.edu/mac/users/bob/clarisworks.php

I think the key thing they did with ClarisWorks, and which they duplicated with Gobe Productive, is to have each kind of document type (word processor, spreadsheet, graphics) in a “frame” and they could be embedded in each other. And there is just one file type that can host any of those. I think that idea was maybe lost to time and might be worth resurrecting. Especially if combined with something more modern like easy sharing/collaboration over the internet and excellent HTML output.

Also related to this there has been a Google Summer of Code idea about improving the basic text editing widget in Haiku and doing that would be maybe a good first step in making the components needed for something like a new Gobe Productive. It would also improve an aspect of Haiku. Then Sum-It could maybe be used for the spreadsheet part, Stephan’s work on Wonderbrush 2 could be part of the vector graphics part, etc. It might just be a matter of code clean-up, integration and then maybe fair amount of work on the word processor part, which is admittedly a hard project.

1 Like
36

I think one of the reasons I liked Gobe Productive so much was due to its likeness to AppleWorks and ClarisWorks. I used AppleWorks for years on Mac both personally and professionally and I’ll say that Apple missed the mark with iWork in some respects when it came to lack of some features. I’m not advocating for pushing to get Gobe Productive open sourced since that seems to be an impossible task. However, it does provide a great blueprint for a successor made for Haiku. I make no assumptions that it would be easy and figure it’s going to take some time to deliver an MVP. I’d be curious of the Haiku app developers out there who would be interested in embarking on such a journey.

37

I haven’t looked at LibreOffice or any other office. Perhaps one of them can be used as a backend API or something like that.

38

The file formats used by LibreOffice are all zipped XML formats. Perhaps having an alternative archive format that preserves BeFS attributes could be used as an alternative. Likewise BSON parses faster than text-based formats like JSON and XML. Being able to import Oasis OpenDocument formats (the formats used by LibreOffice and Apache OpenOffice as well as the AbiWord word processor) would be a smart secondary goal.

@thread

I’ve looked at the SumIt sources and it looks like good, solid C++ without any optimizations. If speed becomes a concern, however, we may look at adding LLVM JIT support with polyhedral vectorization, OpenCL support or a way to spawn a spreadsheet into a more specialized database format before processing the data.

4 Likes
39

But with a lot of hardcoding to 32 bit CPU.

40

I didn’t look through the GUI code nor did I try to compile it on my 64-bit system yet. The only hard coding I saw was 8 bits in a byte being assumed in their Set implementation.

41

ODF should be the primary format used in a possible GoBe rewrite. Office documents mainly exist to be shared with others. It would be delusional to use a niche format. OOXML support can be added through the help of the Document Liberation Project libraries.

1 Like