I'm not really seeing the need for an Office suite.
I have FinalWriter, PageStream 3, etc...etc...
It would be OK but would probably not get used much.

Not seeing the need for an Office suite? Really?!

I guess if Final Writer and PageStream 3 suits your needs then great.

Unless you don't need cross compatibility with other office suite files.

I may be behind the power curve, but those programs don't offer near what LibreOffice offers, unless FinalWriter, PageStream3, etc... can read/write the defacto standard of .docx, .xlsx, .ppsx etc files.

I think a lot of us here would like to have that ability and the only way to do it is to have a modern, native office suite.

[ Edited by SteveE617 02.02.2013 - 12:13 ]

Personally, I support the development of Cinnamon Writer, but I'm donating a system to this developer as well.
My feeling is that this project is going to be involved, it may take awhile, and may require mote then one developer.
Cinnamon Writer may be in the Alpha stage within the next month or two. And wil probably be ready long before Libre Office.
Libre Office will be great when finished.

I had advocated for this years ago. Hope it finally materializes

If there would be any need to open bounty, morphos.pl will be more than happy to organize it.

Jim wrote:,
Quote:


Yes, it could be a year or two before Libre Office is completely finished, if it ever gets finished for MorphOS3.x, so I also support Cinnamon Writer, or any other word processing program and better printer support for MorphOS3.x. I think that they are essential for some people to use their MorphOS3.x systems as their primary computer, though many people are already able to use MorphOS3.x computers as their primary computers and don't need to have a new, or different word processing program.

Andreas_Wolf wrote:,
Quote:


I just meant that AROS for PPC might benefit from some of the PPC specific code that was created during the porting process to MorphOS3.x (and/or AmigaOS4.x), not that AROS for x86/x64 could not also do their own port (probably much easier due to better tool chain(s) being available and not needing to cross architecture converting of the native Libre Office code). I am not a programmer (yet), so it will be no surprise if some (or all) of my ideas are rebuffed by any programmer with technical reasons why I am wrong in my assumptions.

[ Edited by amigadave 04.02.2013 - 11:42 ]

> the PPC specific code that was created during the porting process to
> MorphOS3.x (and/or AmigaOS4.x)

As I said, LibreOffice is written in C++. Porting C++ code (or any other high level language code) from one OS to another has (almost) nothing to do with CPU ISA as that's what the compiler takes care of. And as I said, that's why LibreOffice is also available for PPC:

http://download.documentfoundation.org/libreoffice/stable/3.6.5/mac/ppc/
http://download.documentfoundation.org/libreoffice/testing/4.0.0/mac/ppc/

> not that AROS for x86/x64 could not also do their own port (probably much
> easier due to better tool chain(s) being available and not needing to cross
> architecture converting of the native Libre Office code).

The "native Libre Office code" is written in C++. It's of minor difference whether this C++ code gets compiled into PPC machine code by means of a cross-compiler on an x86 OS or gets compiled into x86 machine code by means of a native compiler on that same x86 OS. It makes no difference from the toolchain viewpoint, because PPC is a primary target ISA of the GNU toolchain anyway.
In conclusion, AROS for x86(-64) wouldn't have to have its own port, rather it would be one and the same source code for AROS/x86(-64) and AROS/PPC, merely and simply compiled into different CPU machine codes.
In general, you may want to read up on the concept of high-level programming languages.
(I remember we had a similar conversation half a year ago.)

Is the author of scriba doing anything regarding this project?

xyphoid,
I think he's busy improving Scriba. Last public release was V1.6.0 from January 29th.

http://aminet.net/package/text/edit/Scriba_1.6.0

I understand the concept & practice of "High Level Programming Languages", but find it hard to believe that there would not be a significant amount of platform specific code that must be written for each architecture. Specially for a project as large as this one being proposed, but I will be happy if "After-the-Fact", when the project is completed, I am proven wrong, and there is almost zero platform specific code that is needed. I don't know what version of MUI AROS can use, or if it is used at all, as I am not familiar with AROS, but my limited understanding of AmigaOS4.x and MorphOS3.x suggest that quite a bit of coding for MUI4 on MorphOS3.x, and ReAction for AmigaOS4.x, would make the platform differences between the two binaries a significant amount of coding, but a small percentage of the total coding for each project.

As always, thanks for the reminder and link to our previous conversation.

I think the differencies from an application's POV are at an OS level (different API, the available function libraries, SDK, etc), not at the underlying CPU architecture/HW per se (the OS and the compiler deals with that.)

> I [...] find it hard to believe that there would not be a significant amount
> of platform specific code that must be written for each architecture.

I fail to see a reason why there should be *any* code specific to any CPU platform or CPU architecture in the LibreOffice C++ source code.
Even if there should be some, say, SIMD-optimized (and thus CPU-specific) routines in the source code, then they are already there in the existing PPC version as well (with AltiVec code instead of AVX/SSE code), or there's a generic scalar code path as fallback used in the existing PPC version. Either way, there's no need for any "PPC specific code that was created during the porting process to MorphOS3.x (and/or AmigaOS4.x)".

> Specially for a project as large as this one being proposed

I fail to see how larger C++ source code would require larger amount of code specific to CPU platform or CPU architecture.

> I don't know what version of MUI AROS can use, or if it is used at all

http://en.wikipedia.org/wiki/Zune_(widget_toolkit)

> my limited understanding of AmigaOS4.x and MorphOS3.x suggest that quite a bit
> of coding for MUI4 on MorphOS3.x, and ReAction for AmigaOS4.x, would make the
> platform differences between the two binaries a significant amount of coding,
> but a small percentage of the total coding for each project.

Rewriting the standard LibreOffice GUI code into GUI code for AmigaOS/MorphOS/AROS will be the biggest part of the total work to do. And yes, using different GUI toolkits for the ports to the various AmigaOS-like systems would multiply this amount of work.
Nevertheless, this matter of GUI-specific code has nothing to do with the matter of CPU-specific code. The current LibreOffice GUI source code looks the same for the x86(-64) versions and the PPC version of LibreOffice. Likewise, MUI/Zune source code looks the same on x86 and on PPC. That's why once a MUI/Zune GUI for LibreOffice exists, creating binaries for AROS/x86 and AROS/PPC (and AROS on any other CPU ISAs) will be just a matter of switching the compiler to the respective target CPU.

It really looks like this is going to happen.
More then one programmer has stated an interest in working on it.

Our "hobbyist" OS is developing real world utility.

Update:

> LibreOffice is also available for PPC

Official support for MacOSX/PPC has ended in October 2013 with version 4.0.6.2. Therefore, unofficial builds of new versions are being provided there:

http://ftp.osuosl.org/pub/manulix/other/libreoffice/

Unofficial support for Linux/PPC remains unaffected by this, of course.

No offense, but this is MorphOS. Let the OS4 guys figure their own way. I wouldn't contribute to any OS4 software.

Quote:

I tend to agree, as many OS4 packages are less than impressive.
So, Steve, any idea if you can talk Eric into picking this idea back up and running with it?

You said you have some G5s, and I'm sure we could dig up a laptop for Eric if portability is an issue.

Don't know if there was a discussion about it, and i know it is a half solution, but AFAIK Libreoffice has an option to work as a web app. So someone set up a server and install the needed files, and then you can use libreoffice under MOS and OWB.

https://wiki.documentfoundation.org/Using_LibreOffice_in_a_Web_Browser

[ Edited by Derringer 12.02.2014 - 00:19 ]

Quote:

Is this project dead, or alive? I would really like to see a modern word processor with full printer support and the ability to open and save-as, almost any of the currently used word processing file formats.

I know that it probably would be a huge task to port and it might take years to complete, but I would support such a project, if a bounty was set up to get Libre Office ported to MorphOS.

Quote:

This "browser-mode" is roughly the equivalent of running Libre Office via VNC on a separate machine, except that VNC would be a more flexible approach since you could run other applications as well (plus the image compression methods are likely more optimized and adaptive).

The only thing that OWB would do is download PNG files showing the LibreOffice user interface. None of the actual editing functionality would be run inside the web browser. To reach decent levels of performance, you will need a rather fast connection to the server.

Quote:

As far as I know, I have to accept responsibility for it's demise (Steve can correct me if I am wrong).

I wanted to ship Eric a better system than I had on hand so by the time I obtained what I wanted to send, Eric was no longer fired up about pursuing the project (at the time, Steve also had a few G5s but this was before support was introduced).

I played around with an earlier source myself, but later revisions are more monolithic making it difficult to port parts of the program (the word processor in the earlier version could be compiled separately).

As my record of shipping things in a timely fashion is not that great, currently I'm just focusing on making amends to the friends I still owe stuff too.

A word to the wise (which means I probably can not take my own advice), if you are going to support something, do it passionately.

BTW - David, are you back in the US?

> at the time, Steve also had a few G5s but this was before support was introduced

He said he had 3 G5 machines just 2 days before MorphOS for G5 was released:

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=9&topic_id=9163&start=57

Quote:

Here, yes, but he told me about them earlier.
But in any case this was long after I should have sent a G4 to Eric.
Therefore I still feel responsible for this situation.

I did have four PM G5s, two of which ended up not being 100% health wise. Now, I have two G5s, one dedicated MOS 3.4 machine and the other configured as an OSX 10.5.8 machine. I also have a Mac Mini G4 1.42 machine.

The learning curve for Eric would be pretty steep. He's never done anything with Amiga or anything Amiga-like. He knows nothing about MUI and that would be a steep curve for him as well. I think he got discouraged due to the fact that he would be starting from square one with something completely new to him...not the standard coding that he does on an everyday basis.

Myself, I'm not a programmer. I'm a reliability engineer. I look at failures and analyze the what, where, when and why it failed type stuff. So, I really would be no help at a port besides the overall reliability of a product and the going through testability and finding problems and ascertaining a root cause.

Personally, I think this would be a great project. I would love to see it happen and I'd like to help out with it, but looking back when we started this, it may have been a little to advantageous for Eric to handle given what would have been involved.

Steve

[ Edited by SteveE617 13.02.2014 - 09:28 ]

Well, that relieves me of some of the guilt.
At this point, I support Cinnamon writer's further development and would do the same for Libre Office, but we would need a dedicated developer.

Right now my spare time is be absorbed by work with a Coldfire development system.