Naja, das solte auch vorerst reichen auf einem Maemo-Device. Mal sehen, wie sich das entwickelt. Auf jeden Fall ist die Beteiligung an der MS-Formatkompatibilität zu begrüßen!
Nö: "Nokia has created a document viewer for the Maemo 5 platform (Fremantle) based on KOffice and uses the KWord and KPresenter applications to load and display word processor and presentation documents. The application uses a custom user interface specifically designed to fit in with the Maemo 5 style."
Von micha6270 am Do, 17. September 2009 um 16:58 #
Also, ich find, die UI ist eine der guten Ideen, die man dort hatte. Konzept? Nun, das Konzept ist es wohl, eine moderne, in KDE integrierte Office-Suite zu entwickeln. Zur Entwicklung kann ich nichts sagen...
Also das UI ist absolut Bon Bon like... ob man damit dauerhaft arbeiten will? Nichts passt richtig zusammen, alles sieht wie in einem Grafikadventure zusammengeklickt aus... mit Konzept meine ich, dass die Entwicklung nicht so richtig konsequent vorankommt. Schon der Vorgänger wurde nie richtig fertig, hier kommen immer nur Entwicklerversionen. KOffice macht eher den Eindruck eine Spielweise für Entwickler zu sein als den Anwendern ine zuverlässige Office Suite zu bieten.
Von Jo:rg Zweier am Do, 17. September 2009 um 18:42 #
++
Sehe ich sehr ähnlich. Komischerweise versuchen alle immer auf den Microsoft-Zug aufzuspringen, obwohl die Konzepte und Ideen gar nicht mal die besten sind. Zum Beispiel muss man starke Einbußen bei Tastaturnavigation und Barrierefreiheit in Kauf nehmen. Darauf sollte man in erster Linie direkt beim Entwerfen eines UI-Konzeptes achten.
Dass sich sogut wie jeder Browser den Mozilla Firefox als Vorbild nimmt, ist auch nicht sonderlich klug. Erst durch Erweiterungen wie VIMperator wird der Mozilla Firefox einigermaßen benutzbar. Richtig umgesetzt haben Barrierefreiheit und Usability nur die beiden Programme uzbl und w3m. Ich zähle bewusst nicht Links, Elinks und Derivate auf, da diese Konsolenbrowser sehr überladen sind und sie navigationstechnisch nicht mit den ausgeklügelten Konzepten von w3m mithalten können. uzbl ist ideal, wenn man Bilder sehen möchte, CSS-, Adobe-Flash- oder JavaScript-Unterstützung benötigt. Allerdings geht bei uzbl die Modularisierung so weit, dass man bewusst (!) Performanceeinbußen in Kauf nimmt (bspw. wird für jedes Laden einer Webseite ein eigener Prozess aufgerufen, der speziell dafür gedacht ist, die aktuelle Seite in der Chronik zu vermerken). Sinnvoller wäre an der Stelle eher ein Browser, der mithilfe von Lua-Code konfigurierbar ist, sodass nicht für jede Kleinigkeit externe Prozesse aufgerufen werden müssen.
Bitte sicher dir diesen Post und lies ihn dir in 5 bis 10 Jahren noch einmal durch. Es werden sich dir wahrscheinlich die Fußnägel vor lauter Peinlichkeit aufrollen. Ich mein das ernst.
Zum Vorposter. Als Vorbild haben derzeit alle Google Chrome, wohl auch die Mozilla Leute.
An uzbl ist doch gerade das gute, dass es ein UNIX-Tool ist, d.h. ein Tool für jeden Anwendungsteil. Wenn man z.B. die History asynchron schreibt, sehe ich nicht, wieso das Performance kostet. Das wird ja wohl noch gehen. Per Script steuerbar ist Firefox ja schon, das braucht uzbl nicht nachmachen.
Ich habe gerade Konqueror für Firefox aufgegeben, weil ich ja jetzt eh kein KDE mehr benutzte, und der ohnehin nicht mehr genug Liebe bekommt. Habe mich mit ca. 10 Extensions beglückt, und bin interessiert überrascht, dass Browser eine von mir wahrgenommene Applikation geworden ist. Wenn ich jetzt für uzbl bessere Dokumentation hätte, würde ich unbedingt dafür sorgen wollen, dass ich mir einen sogar noch besser (für mich) geeigneten Browser schustere.
Warum? Weil er sein System lieber hauptsächlich per Tastatur bedient? Durch diesen Grafikhype gehen meiner Meinung nach tatsächlich auch einige Vorteile verloren. Für Profianwender wäre eine sinnvolle Kombination von GUI und eben der Bedienungsart wie er sie nennt (gibt es dafür eine Bezeichnung?) sicher sehr produktiv.
Von Jo:rg Zweier am Do, 17. September 2009 um 18:54 #
Da scheinst du den Forschritt von KOffice nicht in den letzten Versionen beobachtet zu haben.
Klar, es ist halt kein zweites "Open Office" mit hunderten von Entwicklern. Somit ist es auch kaum verwunderlich, dass man nicht mit der selben Entwicklungsgeschwindigkeit voran kommt. Doch es werden selbstverständlich Fortschritte erzielt und mit jeder Version wird KOffice stabiler und Feature-reicher. Dass der Vorgänger nicht fertig wurde, hatte mehrere Gründe. Ein ganz entscheidender war das Erscheinen von Qt4, sodass zusätzlich der Drang zur Umorientierung entstand. Primär wurde nämlich der gesamte Code refaktorisiert. Nach Außen sind solche Änderungen, die "unter der Haube" geschehen natürlich kaum sichtbar. Somit kann vielleicht ein falscher Eindruck entstanden sein, die KOffice-Entwickler seien untätig. In der Tat nahm allein das Portieren von Qt3 auf Qt4 schon sehr viel Zeit in Anspruch. Das brachte in erster Linie keine neuen Features. Dafür kann man sicher gehen, dass die Codequalität gestiegen ist und Anfangsfehler (unangemessene Implementierung bestimmter Komponententen) direkt vermieden werden konnten.
Deine Aussagen sind leider sehr pauschal gehalten, auch, wenn sie einen kleinen Funken Wahres beinhalten, spiegeln sie nun mal nicht die gesamte Wahrheit wieder.
> Klar, es ist halt kein zweites "Open Office" mit hunderten von Entwicklern.
Ich denke wenn Nokia auf den Zug aufspringt ist das schon ein Zeichen dass es mehr Entwickler werden. Man muss auch sehen dass jetzt die Umstellung auf KDE 4 so ziemlich überstanden ist. Jo ich denke der Zug rollt langsam schneller. ;o)
"... In a healthy project we would expect to see a large number of volunteer developers involved, in addition - we would expect to see a large number of peer companies contributing to the common code pool; we do not see this in OpenOffice.org. Indeed, quite the opposite we appear to have the lowest number of active developers on OO.o since records began: 24, this contrasts negatively with Linux's recent low of 160+. Even spun in the most positive way, OO.o is at best stagnating from a development perspective."
Ich habe mir die Seite nicht durchgelesen, aber du ja sicher. Ich gehe einfach mal davon aus, dass dort auch steht warum OOo solche Probleme hat Entwickler zu finden. Es geht darum, dass der Code nicht wirklich modular und sehr komplex ist. Des weiteren werden einige Lösungen eingesetzt, die sonst nicht so verbreitet sind. Das Problem ist, dass man kaum gute Beiträge machen kann, wenn man sich nicht sehr aufwendig in das Projekt eingearbeitet hat. Des weiteren gibt's noch ein paar politischere Hindernisse (siehe Go-OO). Bei KOffice ist so ziemlich alles anders. Gerade die Probleme vom OOo treffen hier kaum zu. Natürlich gibt es ganz andere Gründe, warum auch KOffice nicht die Türen eingerannt werden. Nur kann man die beiden Projekte in dieser Hinsicht nicht so einfach vergleichen.
Irgendwo habe ich mal gelesen dass SUN sehr rigide darin war die Richtung in welche OOo marschieren soll selbst zu bestimmen und das mit ein Grund war dass Go-OO und Lotus Symphony sich abgespalten haben.
Ansonsten um zu KOffice zurückzukommen es ist ja nicht nur so dass die Umstellung auf QT4.x vorbei ist sondern dass es auch für Windows verfügbar ist durchaus ein Grund welcher mehr Entwickler anziehen wird.
Von Jo:rg Zweier am Do, 17. September 2009 um 18:30 #
Mir gefällt die UI sehr gut. Es ist auf jeden Fall ein Fortschritt zu Open Office bzw. Microsoft Office < 2007, weil der Platz sinnvoller genutzt wird.
Dass ein Konzept fehlt, kann ich zwar nicht beurteilen, aber braucht ein Office-Programm wirklich ein fein ausgearbeitetes Konzept? Es sind doch immer die gleichen Features, die ein solches Programm besitzen soll: Import-Filter für Word, Open Document usw.
Auch, wenn es bereits ein gutes Office-Programm für Linux gibt - Open Office - sehe ich dennoch Bedarf für ein Weiteres. Das fängt bei Kleinigkeiten wie der Toolkit-Frage an, geht über die Wahl der Programmiersprache, und hört bei KDE-Integration auf. Open Office ist seit geraumer Zeit geschwindigkeitstechnisch schneller geworden. Dennoch sehe ich Java nicht als idealste Wahl an. Open Offices erster Start dauert immer etwas, dafür ist es danach sehr schnell. Doch zu welchem Preis? Schaut euch einfach mal die Prozessübersicht an... Java läuft im Hintergrund weiter und verbraucht unnötig Arbeitsspeicher. Open Office funktioniert einfach, nur deshalb nutze ich es. GTK-Programme verhalten sich auch trotz QtCurve etc. immer anders als ein "richtiges" Qt-Programm unter KDE.
Von André Schnabel am Fr, 18. September 2009 um 09:53 #
> aber braucht ein Office-Programm wirklich ein fein ausgearbeitetes Konzept?
Oh ja - das braucht es (zumindest wenn es eine Anwenderzahl > 10 Mio haben will). Du hast zwar recht - es sind immer wieder die gleichen Features, die ein Office-Programm besitzt (und 80% der Anwender nutzen eh nur 20% davon), aber genau deshalb kommt es darauf an, wie schnell und effizient Anwender diese Funktionen benutzen können. Wenn es dazu kein einigermaßen gutes Konzept gibt, gibt es zwar etwa 5 Möglichkeiten, die Rechtschreibprüfung zu starten, der Thesaurus ist aber nur per Menü erreichbar und die Grammatikprüfung muss erstmal nachinstalliert werden. Eigentlich gehören diese Werkzeuge alle irgendwie zusammen, der Anwender muss aber für jedes Werkzeug einen neuen Weg finden, es zu nutzen. Wenn der Anwender dann zu oft neue Wege suchen muss .. und nicht findet, kommt schnell mal der spruch "geht nicht".
> Auch, wenn es bereits ein gutes Office-Programm für Linux gibt - Open Office - sehe ich dennoch Bedarf für ein Weiteres.
Mindestens ein weiteres, welches auch eine größere Anzahl von Nutzern erreicht. (Insofern würde ich es gut finden, dass die Windows- und Mac-Portierungen von KOffice vorankommen). Nur, wenn die Anwender Alternativen auch benutzen, können wir lernen, was wirklich sinnvoll für die Anwender ist (denn alle Theorie ist grau).
...die könnten auch einfach KDE um die Funktionen erweitern, die sie brauchen und das dann als GUI benutzen. Warum die ihr Maemo entwickeln mussten, bleibt mir ein Rätsel.
Weil maemo nicht nur die GUI ist, zudem ist KDE viel zu Fett für das Gerät (wie GNOME auch, deswegen wirds nicht genutzt sondern nur Teile). Und die Steuerung passt zu garnicht zu einem Mobilgerät
Wir haben während des Plasma Meetings in der Schweiz vor zwei Wochen KDE auf vergleichbarer Hardware (800Mhz ARM, 512MB RAM) flüssig zum Laufen bekommen, von den Ressourcen her sollte es also kein Problem sein.
Die Inputmethoden sind zumindest in Plasma nicht hardcoded im Stack, sondern nur in der jeweiligen Shell (plasma-desktop für Desktop Systeme, plasma-netbook für Netbooks). Plasma ist entwickelt mit Internet Tablets und anderem mobilen Geräten im Hinterkopf.
"Wir haben während des Plasma Meetings in der Schweiz vor zwei Wochen KDE auf vergleichbarer Hardware (800Mhz ARM, 512MB RAM) flüssig zum Laufen bekommen, von den Ressourcen her sollte es also kein Problem sein."
Wir hatten keinen passende Grafiktreiber zur Verfügung, da wird noch dran gearbeitet. Animationen in QGraphicsView liefen aber auch ohne schon recht gut (für den Windowmanager hatten wir natürlich so kein Compositing zur Verfügung). Als Distro haben wir ARM Builds von Kubuntu genommen, Qt und KDE selber (mittels des Maemo SDK) gebaut. Ich glaube, dass jemand das auch aufgenommen hat. Die Filme von Tokamak3 sind noch nicht online.
Artur hat noch ein paar mehr Details dazu: http://blog.morpheuz.cc/04/09/2009/white-as-snow/
ich hoffe die KDE-PR rotiert schon. Die KOffice News hier ist so ziemlich das Wichtigste Ereignis seit Apple Safari damals. Wenn dann KOffice 2.2 als ODF und .doc Viewer taugt, dann ist das ein ungeahnter Fortschritt, der das Projekt sicher beschleunigen wird.
Also läuft es selbst nicht-hardwarebeschleunigt ganz ordentlich. Aber gerade bei den ARM-Chips ist die Nutzung der ganzen Zusatzchips notwendig, z.B. der 2D-Chip den der Fenstermanager nutzen sollte, ansonsten ist es wie Software-Emulation.
Von vicbrother am Do, 17. September 2009 um 17:21 #
Eine sehr gute Nachricht für koffice, kommt es doch einem Adelsschlag gleich: Ein internationales Großunternehmen entdeckt koffice und portiert es. Dann wird demnächste wohl auch Weiterentwicklung und Bugfixing von Nokia unterstützt werden. SUPER!
Nokia besitzt auch Qt... warum sollten sie ein Office auf anderer Basis nehmen als KOffice mit Qt? Selbstverständlich nimmt Nokia da KOffice. Das hat nichts mit dem Projekt oder der Qualität zu tun, es ist eine rein betriebswirtschaftliche Entscheidung.
Als ob man eine Anwendung aufgrund des Toolkits wählt, wenn man nicht von deren Qualität überzeugt wäre, bzw. davon, die benötigte Qualität erreichen zu können...
Hast Du neben Deinem ziellosen KOffice-Gebashe auch noch Substanz zu bieten?
"Als ob man eine Anwendung aufgrund des Toolkits wählt, wenn man nicht von deren Qualität überzeugt wäre, bzw. davon, die benötigte Qualität erreichen zu können..."
Sicherlich, aber zweifellos hat man es eben auch besonders wegen Qt gewählt. Das passt zusammen mit dem was Nokia in Zukunft mit Maemo vorhat. Jetzt eine GTK/andere Lösung zu suchen würde keinen Sinn ergeben.
Von Jo:rg Zweier am Do, 17. September 2009 um 18:58 #
Wo ist das Problem? Ist doch völlig legitim. Wenn man seinen Code unter die GPL stellt, wird man schon bei der Entscheidung in Betracht gezogen haben, dass andere von dem Code profititieren und Verbesserungen zurückfließen lassen. Nokia trägt zur Stabilisierung der Viewer-Komponente(n) bei. Insofern kann ich deinen kritischen Unterton nicht ganz nachvollziehen.
> Ich sehe hier nur übliches KDE Gejaule von der Weltherrschaft.
Man sieht eben nur das, was man sehen will. Ich glaube beide Seiten nehmen sich absolut nichts. Die eine Fraktion ist der Meinung ihr Favorit ist fortschrittlicher die anderen kontern, dass man nur mit ihrem System vernünftig arbeiten kann und die andern ja nur kleine Spielkinder sind.
Wer nur eine Seite sehen will ist nicht besser als die die er ankreidet.
... ist genauso richtig wie "Nein, denn die Libs sind LGPL."
Es kommt immer darauf an, was man modifizieren will. Ein kommerzielles Produkt darf LGPL Bibliotheken _unverändert_ nutzen. Wenn man jedoch die Bibliotheken selbst verändern will oder muss (und ich vermute mal, das ist hier der Fall), muss das Ergebnis dieser Änderungen wieder (L)GPL sein.
Nix viewer, KOffice komplett!
KOffice hat viele gute Ideen aber kein Konzept, kein vernünftiges UI und eine chaotische Entwicklung.
Sehe ich sehr ähnlich. Komischerweise versuchen alle immer auf den Microsoft-Zug aufzuspringen, obwohl die Konzepte und Ideen gar nicht mal die besten sind. Zum Beispiel muss man starke Einbußen bei Tastaturnavigation und Barrierefreiheit in Kauf nehmen. Darauf sollte man in erster Linie direkt beim Entwerfen eines UI-Konzeptes achten.
Dass sich sogut wie jeder Browser den Mozilla Firefox als Vorbild nimmt, ist auch nicht sonderlich klug. Erst durch Erweiterungen wie VIMperator wird der Mozilla Firefox einigermaßen benutzbar. Richtig umgesetzt haben Barrierefreiheit und Usability nur die beiden Programme uzbl und w3m. Ich zähle bewusst nicht Links, Elinks und Derivate auf, da diese Konsolenbrowser sehr überladen sind und sie navigationstechnisch nicht mit den ausgeklügelten Konzepten von w3m mithalten können. uzbl ist ideal, wenn man Bilder sehen möchte, CSS-, Adobe-Flash- oder JavaScript-Unterstützung benötigt. Allerdings geht bei uzbl die Modularisierung so weit, dass man bewusst (!) Performanceeinbußen in Kauf nimmt (bspw. wird für jedes Laden einer Webseite ein eigener Prozess aufgerufen, der speziell dafür gedacht ist, die aktuelle Seite in der Chronik zu vermerken). Sinnvoller wäre an der Stelle eher ein Browser, der mithilfe von Lua-Code konfigurierbar ist, sodass nicht für jede Kleinigkeit externe Prozesse aufgerufen werden müssen.
Zum Vorposter. Als Vorbild haben derzeit alle Google Chrome, wohl auch die Mozilla Leute.
An uzbl ist doch gerade das gute, dass es ein UNIX-Tool ist, d.h. ein Tool für jeden Anwendungsteil. Wenn man z.B. die History asynchron schreibt, sehe ich nicht, wieso das Performance kostet. Das wird ja wohl noch gehen. Per Script steuerbar ist Firefox ja schon, das braucht uzbl nicht nachmachen.
Ich habe gerade Konqueror für Firefox aufgegeben, weil ich ja jetzt eh kein KDE mehr benutzte, und der ohnehin nicht mehr genug Liebe bekommt. Habe mich mit ca. 10 Extensions beglückt, und bin interessiert überrascht, dass Browser eine von mir wahrgenommene Applikation geworden ist. Wenn ich jetzt für uzbl bessere Dokumentation hätte, würde ich unbedingt dafür sorgen wollen, dass ich mir einen sogar noch besser (für mich) geeigneten Browser schustere.
Gruss,
Kay
die mad
Klar, es ist halt kein zweites "Open Office" mit hunderten von Entwicklern. Somit ist es auch kaum verwunderlich, dass man nicht mit der selben Entwicklungsgeschwindigkeit voran kommt. Doch es werden selbstverständlich Fortschritte erzielt und mit jeder Version wird KOffice stabiler und Feature-reicher. Dass der Vorgänger nicht fertig wurde, hatte mehrere Gründe. Ein ganz entscheidender war das Erscheinen von Qt4, sodass zusätzlich der Drang zur Umorientierung entstand. Primär wurde nämlich der gesamte Code refaktorisiert. Nach Außen sind solche Änderungen, die "unter der Haube" geschehen natürlich kaum sichtbar. Somit kann vielleicht ein falscher Eindruck entstanden sein, die KOffice-Entwickler seien untätig. In der Tat nahm allein das Portieren von Qt3 auf Qt4 schon sehr viel Zeit in Anspruch. Das brachte in erster Linie keine neuen Features. Dafür kann man sicher gehen, dass die Codequalität gestiegen ist und Anfangsfehler (unangemessene Implementierung bestimmter Komponententen) direkt vermieden werden konnten.
Deine Aussagen sind leider sehr pauschal gehalten, auch, wenn sie einen kleinen Funken Wahres beinhalten, spiegeln sie nun mal nicht die gesamte Wahrheit wieder.
Ich denke wenn Nokia auf den Zug aufspringt ist das schon ein Zeichen dass es mehr Entwickler werden. Man muss auch sehen dass jetzt die Umstellung auf KDE 4 so ziemlich überstanden ist. Jo ich denke der Zug rollt langsam schneller. ;o)
"... In a healthy project we would expect to see a large number of volunteer developers involved, in addition - we would expect to see a large number of peer companies contributing to the common code pool; we do not see this in OpenOffice.org. Indeed, quite the opposite we appear to have the lowest number of active developers on OO.o since records began: 24, this contrasts negatively with Linux's recent low of 160+. Even spun in the most positive way, OO.o is at best stagnating from a development perspective."
http://www.gnome.org/~michael/blog/ooo-commit-stats-2008.html
Ansonsten um zu KOffice zurückzukommen es ist ja nicht nur so dass die Umstellung auf QT4.x vorbei ist sondern dass es auch für Windows verfügbar ist durchaus ein Grund welcher mehr Entwickler anziehen wird.
Es wäre ja schön, wenn OpenOffice.org "Hunderte" von Entwicklern hätte.
Tatsächlich sind es etwas mehr als einhundert und die müssen auch noch plattformübergreifend den eigenen Grafikunterbau (VCL) mitentwickeln.
Dass ein Konzept fehlt, kann ich zwar nicht beurteilen, aber braucht ein Office-Programm wirklich ein fein ausgearbeitetes Konzept? Es sind doch immer die gleichen Features, die ein solches Programm besitzen soll: Import-Filter für Word, Open Document usw.
Auch, wenn es bereits ein gutes Office-Programm für Linux gibt - Open Office - sehe ich dennoch Bedarf für ein Weiteres. Das fängt bei Kleinigkeiten wie der Toolkit-Frage an, geht über die Wahl der Programmiersprache, und hört bei KDE-Integration auf. Open Office ist seit geraumer Zeit geschwindigkeitstechnisch schneller geworden. Dennoch sehe ich Java nicht als idealste Wahl an. Open Offices erster Start dauert immer etwas, dafür ist es danach sehr schnell. Doch zu welchem Preis? Schaut euch einfach mal die Prozessübersicht an... Java läuft im Hintergrund weiter und verbraucht unnötig Arbeitsspeicher. Open Office funktioniert einfach, nur deshalb nutze ich es. GTK-Programme verhalten sich auch trotz QtCurve etc. immer anders als ein "richtiges" Qt-Programm unter KDE.
Oh ja - das braucht es (zumindest wenn es eine Anwenderzahl > 10 Mio haben will).
Du hast zwar recht - es sind immer wieder die gleichen Features, die ein Office-Programm besitzt (und 80% der Anwender nutzen eh nur 20% davon), aber genau deshalb kommt es darauf an, wie schnell und effizient Anwender diese Funktionen benutzen können.
Wenn es dazu kein einigermaßen gutes Konzept gibt, gibt es zwar etwa 5 Möglichkeiten, die Rechtschreibprüfung zu starten, der Thesaurus ist aber nur per Menü erreichbar und die Grammatikprüfung muss erstmal nachinstalliert werden. Eigentlich gehören diese Werkzeuge alle irgendwie zusammen, der Anwender muss aber für jedes Werkzeug einen neuen Weg finden, es zu nutzen.
Wenn der Anwender dann zu oft neue Wege suchen muss .. und nicht findet, kommt schnell mal der spruch "geht nicht".
> Auch, wenn es bereits ein gutes Office-Programm für Linux gibt - Open Office - sehe ich dennoch Bedarf für ein Weiteres.
Mindestens ein weiteres, welches auch eine größere Anzahl von Nutzern erreicht. (Insofern würde ich es gut finden, dass die Windows- und Mac-Portierungen von KOffice vorankommen). Nur, wenn die Anwender Alternativen auch benutzen, können wir lernen, was wirklich sinnvoll für die Anwender ist (denn alle Theorie ist grau).
Die Inputmethoden sind zumindest in Plasma nicht hardcoded im Stack, sondern nur in der jeweiligen Shell (plasma-desktop für Desktop Systeme, plasma-netbook für Netbooks). Plasma ist entwickelt mit Internet Tablets und anderem mobilen Geräten im Hinterkopf.
Hardwarebeschleunigt?
Welche Hardware/Distribution?
Gibt es davon ein Video?
Artur hat noch ein paar mehr Details dazu:
http://blog.morpheuz.cc/04/09/2009/white-as-snow/
ich hoffe die KDE-PR rotiert schon. Die KOffice News hier ist so ziemlich das Wichtigste Ereignis seit Apple Safari damals. Wenn dann KOffice 2.2 als ODF und .doc Viewer taugt, dann ist das ein ungeahnter Fortschritt, der das Projekt sicher beschleunigen wird.
Gruss,
Kay
Also läuft es selbst nicht-hardwarebeschleunigt ganz ordentlich.
Aber gerade bei den ARM-Chips ist die Nutzung der ganzen Zusatzchips notwendig, z.B. der 2D-Chip den der Fenstermanager nutzen sollte, ansonsten ist es wie Software-Emulation.
Go, KDE, go!
Der Omega13.
Ein internationales Großunternehmen entdeckt koffice und portiert es. Dann wird demnächste wohl auch Weiterentwicklung und Bugfixing von Nokia unterstützt werden. SUPER!
"It is important to point out that all contributions to KOffice have been made directly inside the KOffice subversion repository." [ link ]
Das heisst:
- Nokia trägt zur Entwicklung von KOffice bei
- Nokia tut dies im Rahmen des KOffice Entwicklungsmodells, also offen
Ich glaube, da gibt's wenig zu meckern.
Hast Du neben Deinem ziellosen KOffice-Gebashe auch noch Substanz zu bieten?
lg
Erik
Sicherlich, aber zweifellos hat man es eben auch besonders wegen Qt gewählt. Das passt zusammen mit dem was Nokia in Zukunft mit Maemo vorhat. Jetzt eine GTK/andere Lösung zu suchen würde keinen Sinn ergeben.
Ja, KDE und Qt sind allem anderen Lösungen hoffnungslos überlegen und wenn es Klopapier von KDE geben würde müsste man selbst das verwenden.
Understatement, Realitätsbezug oder ein bisschen weniger Selbstbeweihräucherung würden der KDE Community und den Entwicklern gut stehen.
Man sieht eben nur das, was man sehen will.
Ich glaube beide Seiten nehmen sich absolut nichts. Die eine Fraktion ist der Meinung ihr Favorit ist fortschrittlicher die anderen kontern, dass man nur mit ihrem System vernünftig arbeiten kann und die andern ja nur kleine Spielkinder sind.
Wer nur eine Seite sehen will ist nicht besser als die die er ankreidet.
Gruß
Also ich lese aus Deinem Posting nur das übliche Gnome Gejaule, daß eine "böse" KDE Lösung genommen wurde.
Etwas weniger Verfolgungswahn würde den Gnome-Anwendern und -Entwicklern gut zu Gesichte stehen...
Wieso sollte KDE das Bugfixing von Nokia unterstützen?
Hätten die denn bei der KOffice Lizenz eine andere Wahl gehabt?
Das mit der LGPL Lizensierung war doch jahrelang deren Lieblingsargument für Gnome.
Und jetzt kommst Du daher und weist darauf hin das die KOffice Bibliotheken auch LGPL sind...
Gruss,
Kay
Allerdings ist LGPL vom Standpunkt anderer Lizenzen als GPL aus gesehen besser.
Was besser ist, hängt also NUR vom Standpunkt ab, sonst von gar nichts.
lg
Erik
... ist genauso richtig wie "Nein, denn die Libs sind LGPL."
Es kommt immer darauf an, was man modifizieren will. Ein kommerzielles Produkt darf LGPL Bibliotheken _unverändert_ nutzen. Wenn man jedoch die Bibliotheken selbst verändern will oder muss (und ich vermute mal, das ist hier der Fall), muss das Ergebnis dieser Änderungen wieder (L)GPL sein.