Was ist denn hier los? Üblicherweise spült doch jede KDE Update-Meldung ... egal.
Also für mich einfach ein gegebener Anlass, dem KDE Team meinen Dank auszudrücken. Ich benutze KDE nun schon länger wieder absolut gerne.
Und: ich freue mich trotzdem auf das, was nicht KDE 5 genannt werden wird! Es ist diesmal absolut eindeutig, dass es kein zweites 4.0 werden soll (denn dann wäre -not- 5.0 schon seit drei Monaten draußen ;-).
Von ,-.,.-,-.,.-,-,.- am Do, 14. Mai 2015 um 22:13 #
"KDE Applications" klingt halt sehr anonym. Nicht jeder hat noch die Kraft, unter den angegebenen Links nachzuschauen, welche auf QT5 portierte KDE-Software sich dahinter verbirgt. Von daher fehlte wohl die Diskussionsgrundlage.
Ich persönlich werde "KDE5" dann wirklich ausprobieren, wenn dieser in einer kommenden openSUSE als KDE-Standard-Desktop aufschlägt.
Dass "KDE5" kein KDE4.0-Desaster kreiert hat und auch wohl keines kreieren wird, ist IMO eine wirkliche Glanzleistung dieser neuen Dreifach-KDE-Veröffentlichungsstrategie.
Dass "KDE5" kein KDE4.0-Desaster kreiert hat und auch wohl keines kreieren wird, ist IMO eine wirkliche Glanzleistung dieser neuen Dreifach-KDE-Veröffentlichungsstrategie.
Die "Veröffentlichungsstrategie" ist jedoch nicht Ursache, sondern mehr Wirkung! Die Grundlage für eine Weiterentwicklung *ohne* harten Schnitt ist die *Modularisierung* des großen alten "KDE SC"-Blobs. Dank klarer Aufteilung in Frameworks, Plasma und Applications konnten und könen eben tiefer liegende Schichten unabhängig(er) von darauf aufsetzenden entwickelt werden. Das ermöglicht das "Voranpreschen" von Frameworks und Plasma *vor* den Anwendungen, die darauf fußen.
Dies ermöglicht es letztlich, die Komponeten in unterschiedlichen Zyklen zu veröffentlichen und ein neues Feature erst dann als Abhängigkeit in einer Anwendung zu nutzen, wenn es wirklich ausgereift ist.
Dies ist einfach ein etabliertes Vorgehen, welches in der Softwarewelt an allen Ecken und Enden auftritt. Welches Unternehmen nutzt jetzt schon Java 8? Sicherlich noch nicht die Mehrheit - dennoch kann sich die Sprache so viel einfacher weiterentwickeln, da unvermeidbare Fehler gelassener ausgemerzt werden können. Selbiges gilt dann für Frameworks, die darauf aufsetzen. Sie können gucken, ab welchem Zeitpunkt sie die Sprachversion anheben. Und Anwendungen ihrerseits können warten, bis das Framework Mit Java 8 Support so stabil ist, dass sie es einbinden wollen.
Bei der Desktopentwicklung unter Linux war das seit Jahr und Tag leider nicht so. Toolkits und simple (self made) Frameworks wurden immer als Teil des "großen ganzen" gesehen und entsprechend mit veröffentlicht. Es gab keine klaren Richtlinien, wer worauf aufsetzen darf usw. Erste Schritte sind ja mit KDE4 und der dortigen Idee, *interne* Frameworks sauberer zu definieren und die unabhängig von der eigentlichen initizierenden Applikation zu entwicklen und verfügbar zu machen (Solid, Akonadi, usw), gemacht worden. Aber erst durch die strikte Modularisierung ist der imho entscheidene Schritt gemacht worden.
Was ist denn hier los? Üblicherweise spült doch jede KDE Update-Meldung ... egal.
Also für mich einfach ein gegebener Anlass, dem KDE Team meinen Dank auszudrücken. Ich benutze KDE nun schon länger wieder absolut gerne.
Und: ich freue mich trotzdem auf das, was nicht KDE 5 genannt werden wird! Es ist diesmal absolut eindeutig, dass es kein zweites 4.0 werden soll (denn dann wäre -not- 5.0 schon seit drei Monaten draußen ;-).
Danke!
"KDE Applications" klingt halt sehr anonym. Nicht jeder hat noch die Kraft, unter den angegebenen Links nachzuschauen, welche auf QT5 portierte KDE-Software sich dahinter verbirgt. Von daher fehlte wohl die Diskussionsgrundlage.
Ich persönlich werde "KDE5" dann wirklich ausprobieren, wenn dieser in einer kommenden openSUSE als KDE-Standard-Desktop aufschlägt.
Dass "KDE5" kein KDE4.0-Desaster kreiert hat und auch wohl keines kreieren wird, ist IMO eine wirkliche Glanzleistung dieser neuen Dreifach-KDE-Veröffentlichungsstrategie.
Dies ermöglicht es letztlich, die Komponeten in unterschiedlichen Zyklen zu veröffentlichen und ein neues Feature erst dann als Abhängigkeit in einer Anwendung zu nutzen, wenn es wirklich ausgereift ist.
Dies ist einfach ein etabliertes Vorgehen, welches in der Softwarewelt an allen Ecken und Enden auftritt. Welches Unternehmen nutzt jetzt schon Java 8? Sicherlich noch nicht die Mehrheit - dennoch kann sich die Sprache so viel einfacher weiterentwickeln, da unvermeidbare Fehler gelassener ausgemerzt werden können. Selbiges gilt dann für Frameworks, die darauf aufsetzen. Sie können gucken, ab welchem Zeitpunkt sie die Sprachversion anheben. Und Anwendungen ihrerseits können warten, bis das Framework Mit Java 8 Support so stabil ist, dass sie es einbinden wollen.
Bei der Desktopentwicklung unter Linux war das seit Jahr und Tag leider nicht so. Toolkits und simple (self made) Frameworks wurden immer als Teil des "großen ganzen" gesehen und entsprechend mit veröffentlicht. Es gab keine klaren Richtlinien, wer worauf aufsetzen darf usw. Erste Schritte sind ja mit KDE4 und der dortigen Idee, *interne* Frameworks sauberer zu definieren und die unabhängig von der eigentlichen initizierenden Applikation zu entwicklen und verfügbar zu machen (Solid, Akonadi, usw), gemacht worden. Aber erst durch die strikte Modularisierung ist der imho entscheidene Schritt gemacht worden.
Und ja, ich denke das trägt jetzt schon Früchte