Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 35

Thread: Apache OpenOffice 4.0 Has A New Sidebar

  1. #11
    Join Date
    Sep 2011
    Posts
    707

    Default

    Quote Originally Posted by timofonic View Post
    A proper modular design avoids any kind of bloat. I hope LibreOffice splits the format support into a modular library thing, so all Office Suites/Text Editors/Viewers could use the same code for reading/writing.
    It would probably still require updates when ever the native format that it import to changes. I don't know what OOo's situation is but if they are low on maintainers this could be a necessary move even though it might not be an improvement.

  2. #12
    Join Date
    Nov 2011
    Posts
    300

    Default

    Quote Originally Posted by Ericg View Post
    LICENSE-wise? They can cherry-pick, OpenOffice is under the Apache license now. Interestingly enough, OpenOffice CANT cherry-pick from LibreOffice due to LO's license. TECHNOLOGICALLY-wise? I'm not sure. LO is moving away from Java more and more, and OO is moving closer to Java more and more. If nothing else they can cherry pick ideas and methodology, but not the exact implementation.
    Ironic, isn't it? LO inherited the license of the defunct OO.o (GLP3+ and LGPL3+) while AOO switched it.

  3. #13
    Join Date
    Feb 2009
    Location
    UK
    Posts
    43

    Default

    Quote Originally Posted by timofonic View Post
    I hope LibreOffice can cherry pick the interesting bits from this code, that's all I'm interested about it
    They've already done so many times over the course of LO development.

    I hope LibreOffice splits the format support into a modular library thing, so all Office Suites/Text Editors/Viewers could use the same code for reading/writing. This could make possible that other projects could be more interested about contributing in better supporting those formats, providing fixes or better support of those (or even new supported formats).
    Once again, this is already the case AFAIK. At the very least, publisher and visio support is implemented using libraries that are not directly tied to LO.

    http://fridrich.blogspot.ch/2012/06/...rt-filter.html

    http://fridrich.blogspot.ch/2012/12/...filter-20.html

  4. #14
    Join Date
    Oct 2012
    Posts
    107

    Default

    I dunno, I had to keep Apache Open Office 3.4 around with LibreOffice 4, as LibreOffice (at least for me) seems to have regressed quite a bit in their Word/PowerPoint filters. I have a few of both that get horribly currupted in LO, but AOO open them fine.

  5. #15
    Join Date
    Feb 2008
    Posts
    213

    Default

    Quote Originally Posted by ModplanMan View Post
    They've already done so many times over the course of LO development.



    Once again, this is already the case AFAIK. At the very least, publisher and visio support is implemented using libraries that are not directly tied to LO.

    http://fridrich.blogspot.ch/2012/06/...rt-filter.html

    http://fridrich.blogspot.ch/2012/12/...filter-20.html
    But what about a common FFMpeg-like framework for it? So they share the same API and all them can implement common read/write stuff easily, maybe even word processor stuff too.

  6. #16
    Join Date
    Dec 2011
    Posts
    2,122

    Default Waste

    Seems rather a waste to have both Apache OpenOffice and LibreOffice.
    Divided resources.

    It would be nice if they could be merged back to one again.

  7. #17

    Default

    Quote Originally Posted by bakgwailo View Post
    I dunno, I had to keep Apache Open Office 3.4 around with LibreOffice 4, as LibreOffice (at least for me) seems to have regressed quite a bit in their Word/PowerPoint filters. I have a few of both that get horribly currupted in LO, but AOO open them fine.
    Did you try 4.0.4 they fixed a lot of import bugs https://wiki.documentfoundation.org/Releases/4.0.4/RC1

    Have you filed a bug? https://www.libreoffice.org/get-help/bug/

  8. #18
    Join Date
    Sep 2008
    Posts
    244

    Default

    Quote Originally Posted by timofonic View Post
    Did you know European Union and others invest a lot money in digital preservation?

    http://www.digitalpreservationeurope.eu
    eh. This isn't argument.
    UE invested a lot of money in many horrible projects and They still want to keep that trend.

  9. #19
    Join Date
    Jan 2013
    Posts
    525

    Default

    Quote Originally Posted by timofonic View Post
    I hope LibreOffice can cherry pick the interesting bits from this code, that's all I'm interested about it

    Any news about upcoming LibreOffice too?

    PS: They removed support for opening old StarOffice documents (if the code is so sucky, they can rewrite it), that's too negative for interoperability. And they are making OO more attached to Java too.
    This is ironic in a way, since Libreoffice was wanting to make their suite less dependant on Java.
    It's plain to see that this is a 'me too' scenario so that AOO doesn't appear to be gaining new features, and if AOO ever stops being developed it'll be ripped out.

  10. #20
    Join Date
    Dec 2010
    Posts
    1,191

    Default

    Quote Originally Posted by finalzone View Post
    Ironic, isn't it? LO inherited the license of the defunct OO.o (GLP3+ and LGPL3+) while AOO switched it.
    LibreOffice made a massive re-sync with Apache OpenOffice and now the majority of LO's code is under Apache License.
    However, every single modification to to that code is licensed under MPL.
    If any other FOSS project acted that way, it would be at least considered rude to make modifications to a forked file under a different license than the original. It may even be considered hostile.

    So far I didn't see any hostility of Apache's OO team against LO, only the other way around. A few months ago Document Foundation members accused Apache of lying, claiming that no Symphony code was ever donated to Apache by IBM. Yet, LO 4.1 now has that “non-existing Symphony sidebar code”.
    Personally, I have more sympathy for Apache because of these actions by TDF.
    Technology-wise, though, both projects are rotting meat. Both projects still use VCL and both projects still run in a single monolithic process. Calligra has the superior architecture. Sadly few people realize that which is why Calligra lacks a bit of robustness a handful of additional bug-squashing contributors could remedy…

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •