OpenOffice 4 - wann-wo-wie-womit?

(DE) Anwendungen für Office, Multimedia und Spiele, Werkzeuge, Hilfsprogramme, etc
(EN) Applications for Office, Multimedia or Games, Tools, Utilities, e.g.
Antworten
ajunra
Beiträge: 375
Registriert: Mo 23. Dez 2013, 06:40
Wohnort: Insel Rügen

OpenOffice 4 - wann-wo-wie-womit?

Beitrag von ajunra »

Hallo zusammen,
da ich durch das abbrennen meiner Firma im Moment einen eingeschränkten Netzzugang habe, konnte ich die aktuelle Entwicklung nicht vollständig verfolgen. Daß eComStation nun von einer unbekannten holländischen Firma (welche ebenso maulfaul ist wie mensys) - nun ja - vertrieben wird, weiß ich. Mein Abo ist jedoch bei mensys bereits abgelaufen und angesichts der enormen Informationsfülle seitens mensys werde ich es auch nicht verlängern, kann daher aber auch nicht in der BETA-Zone nachsehen.
Daher nun meine Fragen: Gibt es neuigkeiten bezüglich OpenOffice 4 für eCS? Ist ein erscheinen in diesem Jahrzehnt noch wahrscheinlich?

Ich weiß daß daran gearbeitet wurde und daß es wohl vor einem oder zwei Jahren wohl mal eine ganz gut funktionierende Vorabversion (für Konferenzteilnehmer?) gab, jedoch fand ich irgendwie nichts aktuelleres...
Wird denn dann auch der JAVA-Teil (also die Datenbank) unterstützt? Wie stabil läuft es (Calc; ggf. Datenbank)? Wer vertreibt es wann, wo und wie?

Schöne Grüße aus dem sonnig-frischen Norden
ajunra
Schöne Grüße von Deutschlands größter Insel
ajunra
Markus
Beiträge: 77
Registriert: Mo 23. Dez 2013, 16:32

Beitrag von Markus »

Hallo ajunra,
ajunra » Mi 23. Jul 2014, 09:51 hat geschrieben: Daher nun meine Fragen: Gibt es neuigkeiten bezüglich OpenOffice 4 für eCS? Ist ein erscheinen in diesem Jahrzehnt noch wahrscheinlich?
Lies dir mal diesen Strang durch.

Hoffe geholfen zu haben.
Markus
Beiträge: 77
Registriert: Mo 23. Dez 2013, 16:32

Beitrag von Markus »

Als Info, die 4.1.1 RC3 ist verfügbar.

Näheres bei os2world.

Falls ich am WE Zeit finde werde ich mal die Version probieren.

Schönes WE noch.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Also die Info wäre im News-Bereich wohl besser aufgehoben. Ich habe es dort jetzt gepostet.
Benutzeravatar
Sepp Mayr
Beiträge: 150
Registriert: Mo 13. Jan 2014, 11:28
Wohnort: Bayern, oda wos hobt ihr dachd?
Kontaktdaten:

Beitrag von Sepp Mayr »

Hallo Gemeinde,

da aufgerufen wurde Erfahrungen mittzuteilen über das neueste OpenOffice 4.1.1 wollte ich dies versuchen, aber bin leider nur bis hier her gekommen:

Bild
Mia san mia
Markus
Beiträge: 77
Registriert: Mo 23. Dez 2013, 16:32

Beitrag von Markus »

Hallo Sepp Mayr
Sepp Mayr » Sa 30. Aug 2014, 12:00 hat geschrieben:Hallo Gemeinde,

da aufgerufen wurde Erfahrungen mittzuteilen über das neueste OpenOffice 4.1.1 wollte ich dies versuchen, aber bin leider nur bis hier her gekommen:
Lies dir bitte mal diesen Strang auf os2world durch. Unter anderem:
System requirements:
--------------------
- eComStation 1.x, 2.x
- OS/2 Warp
- 32bit tcpip stack
- the following packages must be installed (dll only)
libc 0.6.5
gcc 4.4.6
gcc 4.4.4 (ist im Archiv gcc-4_5_2-2_oc00.zip enthalten)
ssl
curl
jpeg
xslt
libicu
z
xml2
stdcpp
mmap
pthread
urpo


These files can be installed with the following command:

yum install libc gcc-4.4.4 gcc-4.4.6 openssl curl libjpeg libxslt libicu zlib libxml2 stdcpp mmap pthread urpo gcc-stdc++-shared-library

if you have a valid rpm/yum installation.
Otherwise you can grab the corresponding zip files from

http://rpm.netlabs.org/release/00/zip/

Only the dlls are needed.
Davon brauchst du die DLL's, die dann in einen Ordner der im Libpath steht kopiert werden müssen. Im allgemeinen x:\os2\dll oder x:\ecs\dll.
Ohne kommt obige Fehlermeldung.

Habe die DLL's (nur openssl noch nicht) nach ecs\dll kopiert und leider startet AOO immer noch nicht :( Mit dem popuplog kann ich nichts anfangen. Da mir im Moment die Zeit fehlt laß ich es erstmal dabei bewenden.
Mitte September habe ich Urlaub da ist dann etwas Zeit zum Probieren. :)
Batchheizer
Beiträge: 57
Registriert: Do 2. Jan 2014, 10:46

Beitrag von Batchheizer »

Eine Fehlerquelle könnte ein QUICKSTART-Prozess von einer anderen OpenOffice-Version sein. Diesen Prozess erst killen. Eine andere Fehlerquelle könnte (da bin ich unsicher) ein Leerzeichen im OpenOffice-Verzeichenis sein (z.B. E.\programs\OpenOffice 4.1 RC 3\ oder so).
Markus
Beiträge: 77
Registriert: Mo 23. Dez 2013, 16:32

Beitrag von Markus »

Hallo Batchheizer
Batchheizer » Sa 30. Aug 2014, 17:45 hat geschrieben:Eine Fehlerquelle könnte ein QUICKSTART-Prozess von einer anderen OpenOffice-Version sein. Diesen Prozess erst killen. Eine andere Fehlerquelle könnte (da bin ich unsicher) ein Leerzeichen im OpenOffice-Verzeichenis sein (z.B. E.\programs\OpenOffice 4.1 RC 3\ oder so).
Möglicher Fehler (?) ist auch dieser hier, was Quickstart einer anderen Version als Fehlerquelle nahe legt.
If you find that starting soffice.exe or swriter.exe from a prompt in the program directory does not get you anything, try setting:

Code: [Select]
BEGINLIBPATH=.;

to ensure that you aren't possibly trying to load a dll from your (most likely still installed) OOo 3.x installation.
Was anscheinend auch nicht geht sind zu lange Pfade
Do not use too long paths.
Code: [Select]
T:\Temp\Apache_OpenOffice_4_os2gcci_install123\Apache_OpenOffice_4.1.1_os2gcci_install-arc_en-US\OpenOffice 4\program\soffice.exe

does not work but

Code: [Select]
T:\Temp\Apache_OpenOffice_4_os2gcci_install12\Apache_OpenOffice_4.1.1_os2gcci_install-arc_en-US\OpenOffice 4\program\soffice.exe

works. Seems there is some 128 char limit. I've created a ticket for that.
Leider finde ich nichts zum Bedarf von RAM von AOO 4.1.1. Mein System hat nur 1 GB, möglicherweise funktioniert es deshalb bei mir nicht. :(
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Code: Alles auswählen

{0}[m:\] which -lasu icuuc42
***
*** Warning - '.' found in your libpath
***
*** Which dll is used may depend on program start order and libpathstrict if
*** defined. Use pmseek.exe or similar tool to find all occurrences.
***
   1: 03/06/12 17:55:48    753371  p:\usr\lib\icuuc42.dll
Der Pfad legt nahe, dass es in irgendeinem .rpm dabei ist da ich nur selten was händisch in diese Verzeichnisse lege. Allerdings erinnere ich mich an meinen Test mit der ersten AOO4.0 Version beim letzten WSE wo auch die icuxx dlls fehlten. Nur weiß ich leider nicht mehr in welchem Paket die dabei waren.

Pfad mit Blank - sollte kein Problem sein für AOO. Allerdings funktionierte dann bei 4.0 Java in AOO nicht. Ob das schon gefixed ist weiß ich nicht. AOO startet aber jedenfalls auch mit Blank im Pfad.

Memory - shared mem ist da üblicherweise das Problem. Z.B. mit above512 und Wilfrieds script (suche hier im Forum) einfach auszulesen. Wenn AOO wegen zu wenig Speicher nicht startet meldet es üblicherweise einen Fatal Error, Return Code 8, Failing module und dann die dll die es nicht mehr laden könnte.

Bei Problem ohne diese Fatal Error Box tippe ich eher auf falsche/doppelte dlls. Also Systeme die entweder nicht mit RPM auf aktuellem Stand sind, oder wo die dlls mehrfach in unterschiedlichen Versionen ev. in verschiedenen Verzeichnissen liegen. Gründliche Suche und Bereinigen oder eCS2.2 installieren und dlls nur mit yum/rpm updaten.
Benutzeravatar
Sepp Mayr
Beiträge: 150
Registriert: Mo 13. Jan 2014, 11:28
Wohnort: Bayern, oda wos hobt ihr dachd?
Kontaktdaten:

Beitrag von Sepp Mayr »

Bevor noch weiter spekuliert wird, ein

yum install libc gcc-4.4.4 gcc-4.4.6 openssl curl libjpeg libxslt libicu zlib libxml2 stdcpp mmap pthread urpo gcc-stdc++-shared-library

hat die Sache erst mal zum Laufen gebracht.

Ich hatte den Hinweis in der zip-Datei gesucht aber nicht gefunden.

Im übrigen gibt es seit 28.8. noch ein Update:

"We just uploaded an update to the recently announced Apache OpenOffice 4.1.1 RC3. This update enables the so called category B modules. The most known module of this category is most likely the spellchecker. Where solver and scripting are others in this category."
Mia san mia
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Wenn ich die Probleme lese, die jedesmal im Zusammenhang mit RPM auftreten: warum nicht einfach mal die DLLs ins Paket packen, das kann doch irgendwie nicht das Problem sein.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Das war doch bei Sepp kein rpm Problem sondern nur, dass er die benötigten dlls (rpm Pakete) noch nicht installiert hatte.

Genau das dazupacken von dlls würde dazu führen, dass viele in den verschiedensten Verzeichnissen unterschiedlichste Stände der allgemein benötigten dlls hätten und deshalb abhängig davon welches Programm zuerst gestartet wurde die unterschiedlichsten nicht nachvollziehbaren Probleme damit haben. --> absolut unwartbar.

Also nie nicht solche allgemeinen dlls mitpacken oder in ein Programmverzeichnis kopieren.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Wieso, das ist doch nur die Frage, wo man die systemweiten DLLs installiert, zB. immer in x:\os2\dll (wie 20 Jahre üblich). Wo die DLLs installiert werden hat doch mit der Installationsmethode erstmal garnichts zu tun. Man könnte aber die OS2-Dateistruktur verwenden (die ist ja nun auch recht simpel), statt eine Unix-Hierarchie abzubilden, die dann parallel zu der alten Struktur besteht. Desweiteren bringt eCS ja schon zweite Locations für Systemdateien mit. Das war/ist auch schon 'suboptimal', aber zumindest noch einfach zu überschauen. Für mich ist das einfach kein gutes Design, tut mir leid. Früher haben wir uns über die DLL Hölle unter WIndows lustig gemacht. Jetzt haben wir das gleiche. Das liegt natürlich auch an der zu hohen Frequenz an neuen DLL-Versionen, aber auch an der Übernahme des RPMs ohne Anpassung an unser System. Die einfachste Lösung wäre ein Online Verzeichnis mit DLLs, das man mit dem DLL Verzeichnis x:\os2\dll synchronisiert, dazu braucht man aber kein RPM, das ginge mit mit jedem Sync-Tool, und wäre systemkonform.
Benutzeravatar
MikeK
Beiträge: 369
Registriert: Mo 23. Dez 2013, 13:51
Wohnort: Potsdam

Beitrag von MikeK »

Die Idee von Frank mit der Netzsynchronisation finde ich richtig gut. Ich benutze RPM/YUM auch nicht. Ich habe mir alle auf Netlabs liegenden ZIP-Dateien runter geladen und die DLLs daraus extrahiert und für mich zum einfachen Handhaben zusammengefasst. Generell packe ich alle neuen DLLs in das "neue" eCS DLL-Verzeichnis, so auch diese. Damit gibt es bisher keine Probleme mit OO411 oder FF24.
Grüße aus Potsdam,
Mike
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Wir könnten hier natürlich ein FTP-Verzeichnis erstellen, wo wir die DLLs reinladen. Noch viel besser wäre es, wenn die DLLs zu Hause bei Netlabs liegen würden.

Nur um das noch zu sagen, damit das o.g. nicht als unkonstruktive Nörgelei rüber kommt, mein Kritik beziegt sich nur auf das RPM Verfahren. Das OO selbst portiert wird finde ich super, Hut ab vor der Leistung. Ich benutze es zwar nicht, aber ich denke das ein verfügbares Office absolut wichtig für das Fortbestehen unserer Plattform ist.
_diver
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

Hallo zusammen,

ich verstehe nicht ganz wo das Problem liegt. Alle rpm sind auch als zip vorhanden. Das AOO readme, welches seit einiger Zeit am selben Ort wie die AOO Downloads befindet, sagt sogar wo die zip sind.

Als Zusatzhinweis für die, die es nicht mitbekommen haben: es gibt einen AOO update1.

Gruss
Silvan
Benutzeravatar
Thomas Müller
Beiträge: 424
Registriert: Di 24. Dez 2013, 13:14
Wohnort: Bremen

Beitrag von Thomas Müller »

Eine Frage an die "Macher" von AOO. wird es wie bisher bei Mensys auch eine CD geben, von der man die Anwendung dann installieren kann?
Das fände ich persönlich sehr angenehm.

Thomas
_diver
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

Hallo zusammen

Ich habe mir das einmal notiert.
Bitte solche Anfragen direkt an uns, weil wir sind aus diversen Gründen nicht sehr aktiv in Foren.

Gruss
Silvan
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Hallo Diver,
ich verstehe nicht ganz wo das Problem liegt.
sicherlich ist es kein unlösbares oder schweres Problem. Ich hatte nie Probleme, die DLLs zu finden. Allerdings ist es heute auch jedesmal übelst umständlich, ein Programm, dass mehrere dieser 'moving target' DLLs benutzt, zu installieren. I.d.R weiß ich nicht, welche Version der DLLs ich schon habe (ist ja nicht immer ersichtlich). Also probiere ich es erst ohne neue DLLs. Dann werden die DLLs schrittweise nachinstalliert.

Ich denke dass ist Euch ja auch klar, deswegen bietet Ihr ja RPM zur Vereinfachung an. Nur leider muß man da wieder andere Kröten schlucken, wurde in den letzten Jahren ja auch öfter mal diskutiert.

Soll ja auch kein Vorwurf sein, aber man könnte es sehr einfach dramatisch vereinfachen.

Ich habe jetzt mal Adrian von Netlabs angefragt, und er wird voraussichtlich ein Verzeichnis anlegen, wo die DLLs im Netz verfügbar sein werden. Dann kann man mit einem sync Tool das machen, was sonst nur RPM bietet, aber ohne die Probleme.
Bitte solche Anfragen direkt an uns, weil wir sind aus diversen Gründen nicht sehr aktiv in Foren.
Ja schade, aber eine Bitte: wenn Ihr es hier nicht posten wollt, sendet uns doch wenigsten die Presserklärungen von Bitwise per Mail zu, immerhin gehts ja auch darum Spender zu mobilisieren, oder gibt es einen Mail-Newsletter?

Weiterhin viel Erfolg!

Grüße
Frank
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Ich sehe RPM als besseres sync tool. Welches würdest du vorschlagen? Standard OS/2 replace oder xcopy ;)

rsync ist auch schon eine portierte SW welche sicher auch einige der dlls braucht. Also warum nicht gleich RPM?

Ich zumindest will diese dlls (und die portierten Programme) nicht auf meinen Systempartitions (\os2\dll, \ecs\dll). Da ist mir %unixroot%\usr\lib allemal lieber. Dies zeigt bei mir auf P: wo alle anderen Programme, portierte und native, auch sind. Ich kann also von allen Systempartitions zugreifen.

Ich verstehe einfach die Abneigung gegen RPM nicht (mehr). Ja am Anfang war ich auch skeptisch. Aber ein anderes sync tool kann das sicher auch nicht besser als RPM.
... welche Version der DLLs ich schon habe (ist ja nicht immer ersichtlich). Also probiere ich es erst ohne neue DLLs. Dann werden die DLLs schrittweise nachinstalliert....
'yum update' finde ich da schon einfacher als deine Methode. Und probieren mit alten DLLs - selbst wenn etwas/einiges auch mit einer alten Version funktioniert, die neuere Version wurde ja nicht nur spaßeshalber gemacht.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Andi, Du kannst es doch machen wie Du willst, ich will niemanden überzeugen.

Den vorgeschlagenen Dir-SYNC kann zudem auch jeder machen wir er will. Er kann sich die DLLs einzeln runterladen. Ich würde Netdrive und dSYNC benutzen (weil ich das für andere Zwecke schon habe), Du kannst auch ein Directory Compare in einem FTP fähigen Filemanager (oder Filemanager mit Netdrive) benutzen, oder ein WGet-Script, oder Rexx, tausend Möglichkeiten, wie man eben ein Verzeichnis synchronisiert.
Und probieren mit alten DLLs - selbst wenn etwas/einiges auch mit einer alten Version funktioniert,
Alte DLLs im Sinne von älteren Versionen funktionieren eigentlich nicht, hatte ich noch nicht, mal davon abgesehen ist es nicht gerade zielführend, diese Variante zu diskutieren, wenn wir gedanklich einen Schritt weiter sind, und über einen andere Art der Synchronisierung reden. "Alte" DLLs funktionieren, wenn es halt immernoch aktuelle Version ist.

Ein Standard Dir-Sync hätte daneben noch den Vorteil, DLLs anzubieten, für die es keine RPM Pakete gibt.

Ist auch alles nur ein Gedanke für mehr Comfort, ich komme sonst auch so klar.
_diver
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

Hallo Diver,
Soll ja auch kein Vorwurf sein, aber man könnte es sehr einfach dramatisch vereinfachen.
Das habe ich auch nicht so verstanden.
Ich habe jetzt mal Adrian von Netlabs angefragt, und er wird voraussichtlich ein Verzeichnis anlegen, wo die DLLs im Netz verfügbar sein werden. Dann kann man mit einem sync Tool das machen, was sonst nur RPM bietet, aber ohne die Probleme.
Ich schalte mich da mal mit Adrian kurz. Weil im Prinzip sind ja schon alle rpm als zip vorhanden. Nur halt nicht ausgepackt.
Ja schade, aber eine Bitte: wenn Ihr es hier nicht posten wollt, sendet uns doch wenigsten die Presserklärungen von Bitwise per Mail zu, immerhin gehts ja auch darum Spender zu mobilisieren, oder gibt es einen Mail-Newsletter?
An wen sollen wir das per mail senden? Und einen Mail-Newsletter wird es bald geben.

Gruss
Silvan
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

An wen sollen wir das per mail senden? Und einen Mail-Newsletter wird es bald geben.
Ich schicke Dir morgen eine Mail. Danke!
Benutzeravatar
Sepp Mayr
Beiträge: 150
Registriert: Mo 13. Jan 2014, 11:28
Wohnort: Bayern, oda wos hobt ihr dachd?
Kontaktdaten:

Beitrag von Sepp Mayr »

Überwiegend (d.h. im Schnitt 1x im Monat) benutze ich Star Writer zum Brief schreiben.
Letztlich stand aber die Aufgabe eine Präsentation zu erstellen mit der Maßgabe, da auch Filme und Klänge einzufügen. Nur - in welchem Format? MP3, WAV, MPEG, AVI - alle Format wurden von Apache OO als falsch erkannt. Ist das Einfügen von Film und Klang eine von OO unter OS/2 nicht unterstützte Option?

-- Sent from my Palm Pre3 using Forums
Mia san mia
Antworten