Es wird die letzte Version von Plasma sein. SC wird es 4.12 durchaus geben.
"Before going into more details, let me offer a preemptive clarification:
This does not effect, in any way, anything other than the code currently in the kde-workspace repository. Applications are not affected, kdelibs and kderuntime will continue on as they currently are (with kdelibs in a feature freeze of its own already). I fully expect there to be a 4.12 and likely a 4.13 release of the applications, and how long that goes on will be up to the application developers and release team."
Warum wird der Übergang von Qt4 auf Qt5 im KDE-Projekt nicht fließend bewältigt? Ich fürchte man möchte, wie bei KDE4, wieder alles von ganz vorne entwickeln. Wäre es nicht möglich, immer Teile neu- und umzubauen und in das bestehende System integrieren?
Und genau das machen wir ja auch. So arbeiten wir seit einiger Zeit daran zum Beispiel Plasmoide in QML neu zu schreiben. Auch KWin ist größtenteils bereits portiert. Aber irgendwann kommt man an den Punkt wo man in einer Quellcodebasis nicht mehr Qt 4 und 5 unterstützen kann. Dafür sind für die Workspaces die Unterschiede doch zu groß.
Für die meisten Anwendungen wird der Übergang sehr fließend.
Ich denke, mit QML hat auch der Umstand ein Ende, dass einige Plasmoids abstürzen und in einem Atemzug den Desktop mit runter reißen. Was ich unschön finde, ist, dass man statt auf Python auf ne eigene Scriptsprache gesetzt hat. Ich versteh nicht ganz, wo da der Vorteil liegen soll?!
Wenn du bei UIs nur an etwas statisches denkst, dann ja. Aber QML ist eben nicht statisch sondern ziemlich dynamisch. Da hat man ja Zustände zwischen denen animiert wird und die bindings etc. anpassen. Das lässt sich nicht mit so was wie QtDesigner umsetzen.
Ich fürchte man möchte, wie bei KDE4, wieder alles von ganz vorne entwickeln.
Kommt jetzt drauf an was man unter KDE4 versteht, manche Leute interpretieren dass ja als das was den Workspace umfasst, andere die gesamte Produktpalette.
Nachdem im zweiten Fall die Aussage nicht zutrifft, können wir hier aber davon ausgehen, dass mit KDE4 das Workspace Produkt von KDE gemeint war.
Ich denke teilweiser Umstieg, z.B. KDesktop ersetzen, Kicker erstmal beibehalten und später ersetzen, hätte auch seine Probleme gehabt und zusätzlich die Portierung einer schon ziemlich schwer wartbaren Codebasis erfordert.
Unter anderem ist Qt5 zu Qt4 zwar größtenteils sourcekompatibel, jedoch wird es keine binärkompatibilität geben und auch die sourcekompatibilität ist eingeschränkt. Nicht die major version number zu erhöhen würde jedoch binärkompatibilität suggerieren. Ich glaube das versucht man unter anderem zu vermeiden.
Ich hoffe mal KDEPIM zwingt einen nicht zum Upgrade auf die neue Version, indem sie nur noch für das neue KDE5 entwickeln. Zwang ist zwar relativ aber KDE PIM ist leider eine der letzten KDE4 Komponenten die immer noch nicht wirklich problemlos benutzbar sind.
Leider ist Kontact auch einer der wenigen Mail Clients die vollständige Groupware Unterstützung bieten. Wenn KDE PIM sich also entscheidet nur noch für KDE5 zu entwickeln, dann wird mir als Anwender auch nichts mehr anderes übrig bleiben als auf KDE5 zu wechseln. Die aktuelle Implementierung hat einfach noch zu viele Bugs als das ich damit für die nächsten zwei Jahre arbeiten wollte.
Der Rest von KDE funktioniert ja sehr gut, nur E-Mail ist leider immer noch eines der wichtigsten Anwendungen auf dem Desktop überhaupt. Also bitte liebe KDEPIM Entwickler, bitte stellt auch weiterhin Updates für KDE4 zur Verfügung. Ansonsten gibt es die gleiche Katastrophe wie mit KDE4.
Von KDE genial - KDEPIM auch? am Fr, 24. Mai 2013 um 01:44 #
KDE ist wirklich genial, ich benutze es seit den Alpha-Versionen, also von Anfang an. KDEPim hat mir aber in der ganzen KDE4-Geschichte nur Ärger gemacht. Akonadi empfinde ich einfach als einen Krampf. Toll gedacht und unglaublich umständlich. Ich arbeite in der Regel mit einem Rechner, brauche aber den Zugriff auf die E-Mail Ordner auch von meinem Notebook aus. Vor Akonadi habe ich schnell und unkompliziert das Maildir-Verzeichnis auf das Notebook kopiert und alles war bestens. Jetzt muss ich auf dem Hauptrechner erst einmal die E-Mail Ordner archivieren und das Archiv auf dem Notebook importieren. Ein Chaos ohne Ende, da ich tausende von Mails verwalten muss. Die Zeit, die dabei drauf geht, ist enorm. Vielleicht ist IMAP da die Lösung. Ich kenne mich damit aber noch nicht aus. Dennoch: KDE ist einfach fantastisch. Danke an die Entwickler.
Akonadi empfinde ich einfach als einen Krampf. Toll gedacht und unglaublich umständlich. ... Vor Akonadi habe ich schnell und unkompliziert das Maildir-Verzeichnis auf das Notebook kopiert und alles war bestens.
Also wenn Du schon so lange dabei bist, müsstest Du doch wissen, dass die Mails nachwievor in einem Maildir-Ordner auf der Platte abgelegt werden und nicht in Akonadi, wie Du schreibst. Bei mir liegen die Mails in ~/.local/share/local-mail Natürlich kannst Du jederzeit Deinen Mail-Ordner ohne umständliches Exportieren/Importieren zu einem anderen Zielort kopieren.
Aber IMAP wäre wohl doch eher DIE Lösung :-) Da brauchst du dich gar nicht gross mit auskennen. Einfach ein IMAP Konto in KMail einrichten und sehen, wie´s dir gefällt.
Ich nutze Thunderbird und sichere da immer den Profilordner. Falls ich mal komplett neu aufsetzen muss, einfach den ganzen Profilordner zurückkopieren und fertig. Ansonsten müssten bei IMAP ja alle Nachrichten nochmal runtergeladen werden, damit die auch lokal offline zur Verfügung stehen.
Man muss in diesem Zusammenhang im Blick behalten, dass eines der Ziele von KDE Frameworks 5 und darauf aufbauender Initiativen das stufenweise Veröffentlichen von Produkten ist.
D.h. KDE Frameworks 5 wird vermutlich im Laufe des Sommers als Preview verfügbar werden, als Release vielleicht Ende des Jahres. Aber der Preview Phase könnte vielleicht ein ähnlichens Unterfangen für KDE's PIM Bibliotheken gestartet werden.
Den Umfang würde ich mal grob auf ein Jahr schätzen bis ein Preview der KDE PIM Frameworks 5 soweit ist das man Applikationen portieren versuchen könnte.
Durch die dienstorientierte Architektur ist es auch leichter möglich, verschiedene Komponenten in verschiedenen Versionen zu benutzen, sollte das zwischenzeitlich nötig sein.
Es wird die letzte Version von Plasma sein. SC wird es 4.12 durchaus geben.
"Before going into more details, let me offer a preemptive clarification:
This does not effect, in any way, anything other than the code currently in the kde-workspace repository. Applications are not affected, kdelibs and kderuntime will continue on as they currently are (with kdelibs in a feature freeze of its own already). I fully expect there to be a 4.12 and likely a 4.13 release of the applications, and how long that goes on will be up to the application developers and release team."
Warum wird der Übergang von Qt4 auf Qt5 im KDE-Projekt nicht fließend bewältigt?
Ich fürchte man möchte, wie bei KDE4, wieder alles von ganz vorne entwickeln. Wäre es nicht möglich, immer Teile neu- und umzubauen und in das bestehende System integrieren?
es gibt nichts zu befürchten, schliesslich gabs bei kde nie ernsthafte probleme...
nee, war er nicht.
doch.......,zu Problemen
Und genau das machen wir ja auch. So arbeiten wir seit einiger Zeit daran zum Beispiel Plasmoide in QML neu zu schreiben. Auch KWin ist größtenteils bereits portiert. Aber irgendwann kommt man an den Punkt wo man in einer Quellcodebasis nicht mehr Qt 4 und 5 unterstützen kann. Dafür sind für die Workspaces die Unterschiede doch zu groß.
Für die meisten Anwendungen wird der Übergang sehr fließend.
Ich denke, mit QML hat auch der Umstand ein Ende, dass einige Plasmoids abstürzen und in einem Atemzug den Desktop mit runter reißen. Was ich unschön finde, ist, dass man statt auf Python auf ne eigene Scriptsprache gesetzt hat. Ich versteh nicht ganz, wo da der Vorteil liegen soll?!
Schon mal Oberflächen mit QML erstellt? Ja? Dann weißt du doch warum man auf QML setzt.
Eigentlich hätte man wohl auch fast gleich nen QGraphicsItem-Editor machen können, der ein nen QML-File oder XML-file ausspuckt.
Wenn du bei UIs nur an etwas statisches denkst, dann ja. Aber QML ist eben nicht statisch sondern ziemlich dynamisch. Da hat man ja Zustände zwischen denen animiert wird und die bindings etc. anpassen. Das lässt sich nicht mit so was wie QtDesigner umsetzen.
Geht denn nur noch QML für die GUIs, oder kann ich weiterhin noch Python nutzen? Oder bleiben diese Bindings "nur" für DataEngines erhalten?
Ich habe leider noch keine Zeit und Muße gefunden, mich in QML einzuarbeiten.
UI wird nur noch in QML möglich sein.
Danke für die Info
Kommt jetzt drauf an was man unter KDE4 versteht, manche Leute interpretieren dass ja als das was den Workspace umfasst, andere die gesamte Produktpalette.
Nachdem im zweiten Fall die Aussage nicht zutrifft, können wir hier aber davon ausgehen, dass mit KDE4 das Workspace Produkt von KDE gemeint war.
Ich denke teilweiser Umstieg, z.B. KDesktop ersetzen, Kicker erstmal beibehalten und später ersetzen, hätte auch seine Probleme gehabt und zusätzlich die Portierung einer schon ziemlich schwer wartbaren Codebasis erfordert.
Unter anderem ist Qt5 zu Qt4 zwar größtenteils sourcekompatibel, jedoch wird es keine binärkompatibilität geben und auch die sourcekompatibilität ist eingeschränkt. Nicht die major version number zu erhöhen würde jedoch binärkompatibilität suggerieren. Ich glaube das versucht man unter anderem zu vermeiden.
Ich hoffe mal KDEPIM zwingt einen nicht zum Upgrade auf die neue Version, indem sie nur noch für das neue KDE5 entwickeln. Zwang ist zwar relativ aber KDE PIM ist leider eine der letzten KDE4 Komponenten die immer noch nicht wirklich problemlos benutzbar sind.
Leider ist Kontact auch einer der wenigen Mail Clients die vollständige Groupware Unterstützung bieten. Wenn KDE PIM sich also entscheidet nur noch für KDE5 zu entwickeln, dann wird mir als Anwender auch nichts mehr anderes übrig bleiben als auf KDE5 zu wechseln. Die aktuelle Implementierung hat einfach noch zu viele Bugs als das ich damit für die nächsten zwei Jahre arbeiten wollte.
Der Rest von KDE funktioniert ja sehr gut, nur E-Mail ist leider immer noch eines der wichtigsten Anwendungen auf dem Desktop überhaupt. Also bitte liebe KDEPIM Entwickler, bitte stellt auch weiterhin Updates für KDE4 zur Verfügung. Ansonsten gibt es die gleiche Katastrophe wie mit KDE4.
KDE ist wirklich genial, ich benutze es seit den Alpha-Versionen, also von Anfang an. KDEPim hat mir aber in der ganzen KDE4-Geschichte nur Ärger gemacht.
Akonadi empfinde ich einfach als einen Krampf. Toll gedacht und unglaublich umständlich.
Ich arbeite in der Regel mit einem Rechner, brauche aber den Zugriff auf die E-Mail Ordner auch von meinem Notebook aus.
Vor Akonadi habe ich schnell und unkompliziert das Maildir-Verzeichnis auf das Notebook kopiert und alles war bestens. Jetzt muss ich auf dem Hauptrechner erst einmal die E-Mail Ordner archivieren und das Archiv auf dem Notebook importieren.
Ein Chaos ohne Ende, da ich tausende von Mails verwalten muss. Die Zeit, die dabei drauf geht, ist enorm.
Vielleicht ist IMAP da die Lösung. Ich kenne mich damit aber noch nicht aus.
Dennoch:
KDE ist einfach fantastisch. Danke an die Entwickler.
Bei mir liegen die Mails in ~/.local/share/local-mail
Natürlich kannst Du jederzeit Deinen Mail-Ordner ohne umständliches Exportieren/Importieren zu einem anderen Zielort kopieren.
Aber IMAP wäre wohl doch eher DIE Lösung :-)
Da brauchst du dich gar nicht gross mit auskennen.
Einfach ein IMAP Konto in KMail einrichten und sehen, wie´s dir gefällt.
Ich nutze Thunderbird und sichere da immer den Profilordner.
Falls ich mal komplett neu aufsetzen muss, einfach den ganzen Profilordner zurückkopieren
und fertig. Ansonsten müssten bei IMAP ja alle Nachrichten nochmal runtergeladen werden,
damit die auch lokal offline zur Verfügung stehen.
IMAP ist subba
Ich hatte dieses Verschieben von local-mail zuletzt bei KDE 4.3 oder 4.4 versucht. Das endete damit, das anschließend nichts mehr klappte.
Ich habe es eben noch mal mit dem aktuellen KDEPIM versucht - und siehe da, es geht.
Jetzt kann ich Frieden mit akonadi schließen. Endlich.
Man muss in diesem Zusammenhang im Blick behalten, dass eines der Ziele von KDE Frameworks 5 und darauf aufbauender Initiativen das stufenweise Veröffentlichen von Produkten ist.
D.h. KDE Frameworks 5 wird vermutlich im Laufe des Sommers als Preview verfügbar werden, als Release vielleicht Ende des Jahres. Aber der Preview Phase könnte vielleicht ein ähnlichens Unterfangen für KDE's PIM Bibliotheken gestartet werden.
Den Umfang würde ich mal grob auf ein Jahr schätzen bis ein Preview der KDE PIM Frameworks 5 soweit ist das man Applikationen portieren versuchen könnte.
Durch die dienstorientierte Architektur ist es auch leichter möglich, verschiedene Komponenten in verschiedenen Versionen zu benutzen, sollte das zwischenzeitlich nötig sein.
Hallo Linuxer,
ich ziehe mich zurück und werde dem Forum:
"Pro Linux"
ab sofort nicht mehr zur Verfügung stehen.
MfG Acader
Und wen, glaubst Du, interessiert das?