Wir planen einen Umbau der Bibliotheken, der grösstenteils Quelltext-kompatibel ist.
Mit stärkere Modularisierung wird es: - einfacher, einzelne Teile aus kdelibs zu verwenden, was die Abhängigkeiten verringert - einfacher, schlankere System zu bauen und zu installieren
Das läuft unter den Namen KDE Frameworks 5. Zur nächsten Generation des Desktops und der Apps haben wir noch nicht viel geplant, ausser, die Umstellung auf QML 2 und Qt Scenegraph voranzutreiben, und selbstverständlich Wayland.
Benutzer dürften aber auch davon weitgehend unbetroffen bleiben, hier ist der Plan weiter inkrementell zu stabilisieren, und mehr und mehr Apparate zu erobern.
Schau dir mal die Doku an. Für jedes Widget gibts meistens ein paar zusätzliche Member. Allerdings fast immer in Abh. zu KDE. Viele Sachen sind richtig cool, aber leider profitieren Programmierer, die Anwendung auch für Windows schreiben wollen, nicht davon. Die meisten Sachen sind in Qt (was seinerseits sehr sauber strukturiert ist) einfach nicht vernünftig unter zu bringen.
Nun da gibt es mehrere Gründe. Zuerst einmal gab es bis vor etwas mehr als einem halben Jahr keine Möglichkeit zu Qt beizutragen. Das hat sich jetzt geändert und unsere Frameworks Entwickler sind dabei einiges upzustreamen.
Das ist aber auch nicht immer einfach und hat einige Hindernesse. Fängt an bei Kleinigkeiten wie KDE dokumentiert in den header Dateien und Qt dokumentiert in den cpp Dateien. Ist also nicht man nehme Code und schiebt es einmal rüber. Dann gibt es auch Lizenzprobleme, die es nicht einfach machen Sachen zu übergeben. Qt erforder ein CLA und bei Klassen, die vor Jahren entwickelt wurden, ist es nicht einfach die Erlaubnis aller Copyrightholder einzuholen (besonders schwierig wenn die Klasse mal migriert wurde mit Code gegebenenfalls aus anderen Klassen und so weiter).
Last but not least gibt es Sachen in den KDE libs, die man wirklich nicht in Qt braucht. Wer braucht denn schon eine Bibliothek um Fenstermanager unter X11 zu erstellen?
Lange Rede kurzer Sinn: KDE Frameworks werden benötigt, aber nicht in der Form wie aktuell die KDE Libs. Die Inter-Modul Abhängigketien müssen aufgebrochen werden und so viel wie möglich muss nur von Qt abhängen, was es einfacher mach diese Module zusätzlich bereitzustellen. Das ist was unsere Frameworksentwickler machen und auch von Qt sehr begrüßt wird.
Gibt es eine Seite wo verwaiste KDE Projekte sind die nicht nach KDE 4 portiert wurden bzw. keinen Maintainer mehr haben ? Ich habe diesbezüglich nitchts gefunden. Alternativ würde ich einen billigen Daemon Tool clone aka "KMount" entwickeln. Meine zweite Projektidee fällt mir grad nicht ein.
Ich hät da ne Idee: KDE und Unity verwenden ja das gleiche, von freedesktop.org als Standard definierte DBus Protokoll um die sogenannten Notifications anzuzeigen. Zum Erstellen solcher Notifications gibts Python & Vala Libraries, aber mir ist keine Qt-Bibliothek dafür bekannt (man muss selber mit DBus sprechen). Wär echt cool wenn man als Qt Entwickler auch auf sowas zurückgreifen kann.
Weitere Infos unter: http://developer.ubuntu.com/resources/technologies/notification/ http://www.galago-project.org/specs/notification/0.9/x408.html#command-notify
Würds selber machen, aber arbeite gerade an einer Qt Bibliothek mit der man Ubuntu One einfacher in seine eigene App integrieren kann (launchpad.net/QUbuntuOne). Könnte dir auch helfen bezüglich DBus & QDBus.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Jul 2012 um 16:16.
Auch das ist aus Sicht eines KDE/Gnome Entwicklers vielleicht eine nette Sache. Aber da Qt auch auf Mac oder Windows ausgerichtet ist und beide Desktops nicht dem Konzept folgen..... naja ich lass mal das Gerede. Wär außer KDE würde denn die Library auf Basis von Qt nutzen? Gnome sicher nicht.
Ja klar wärs nicht Plattform-Unabhängig, MS hat ja kein Notification-System afaik.
Da Gnome 3 sich nicht an den Freedesktop.org Standard hält funktionierts auch nur unter Unity & KDE. Aber man kann dann theoretisch auch in der Library automatisch erkennen unter was für einem System / DE man läuft und so auch Gnome 3, Meego und weitere Notification Systeme von anderen OS / DEs unterstützen.
Nun Gnome selber wird es vermutlich nicht verwenden. Aber ich als Entwickler der gerne mit Qt Entwickelt und möchte das sich mein Programm auch gut in den Gnome / KDE / Unity Desktop integriert würds auf alle fälle verwenden.
Der Link im Wiki zu 'Finding the unloved, 2011, part I" war verweist und wurde gerade aktualisiert. Ein weiterer Vorschlag wäre die Quanta Plus Portierung abzuschließen.
ließ noch mal genau: sebas schrieb, dass es ein Umbau in den Bibliotheken bei Quelltext-Kompatibilität ist.
D.h. einmal neu kompilieren, im Normalfall. Ließ dazu zum Beispiel http://www.kdab.com/porting-from-qt-4-to-qt-5/
auf dem gleichen Blog findet sich auch ein Blog Post, in dem beschrieben wird, wie man mit Hilfe eines llvm basierten Tools die Quellcodeanpassungen automatisch machen kann.
Mir ist bisher nur eine Anwendung bekannt, die etwas mehr Portierungsarbeit bei dem Umstieg auf Qt 5/KF5 brauchen wird: KWin. Und so viele Fenstermanager gibt es nicht in KDE und dank der Modularisierung kann KWin auch auf Qt 4 bleiben wenn andere Komponenten schon auf Qt 5 sind (wobei ich davon ausgehe, dass KWin eine der ersten portierten Anwendungen sein wird).
Wir planen einen Umbau der Bibliotheken, der grösstenteils Quelltext-kompatibel ist.
Mit stärkere Modularisierung wird es:
- einfacher, einzelne Teile aus kdelibs zu verwenden, was die Abhängigkeiten verringert
- einfacher, schlankere System zu bauen und zu installieren
Das läuft unter den Namen KDE Frameworks 5. Zur nächsten Generation des Desktops und der Apps haben wir noch nicht viel geplant, ausser, die Umstellung auf QML 2 und Qt Scenegraph voranzutreiben, und selbstverständlich Wayland.
Benutzer dürften aber auch davon weitgehend unbetroffen bleiben, hier ist der Plan weiter inkrementell zu stabilisieren, und mehr und mehr Apparate zu erobern.
Um was für Apparate handelt es sich dabei?
Den Zuse Z1 natürlich
http://kde-look.org/content/show.php/SteampunK+KSplash+Theme?content=142138
Da du dich anscheinend auskennst kannst du mir vielleicht folgende Frage beantworten:
Was kann das KDE Framework was Qt nicht kann?
Wieso braucht man da noch extra libs?
Alle desktop-bezogenen Sachen, sind - glaube ich - in die kdelibs ausgelagert. Plasma ist drin, die kate-editor-Komponente wahrscheinlich auch... etc.
Hab auch kürzlich irgendwo gelesen, dass es eine Annäherung von Qt und den kdelibs geben soll...
Schau dir mal die Doku an. Für jedes Widget gibts meistens ein paar zusätzliche Member.
Allerdings fast immer in Abh. zu KDE. Viele Sachen sind richtig cool, aber leider profitieren Programmierer,
die Anwendung auch für Windows schreiben wollen, nicht davon.
Die meisten Sachen sind in Qt (was seinerseits sehr sauber strukturiert ist) einfach nicht vernünftig unter zu bringen.
Nun da gibt es mehrere Gründe. Zuerst einmal gab es bis vor etwas mehr als einem halben Jahr keine Möglichkeit zu Qt beizutragen. Das hat sich jetzt geändert und unsere Frameworks Entwickler sind dabei einiges upzustreamen.
Das ist aber auch nicht immer einfach und hat einige Hindernesse. Fängt an bei Kleinigkeiten wie KDE dokumentiert in den header Dateien und Qt dokumentiert in den cpp Dateien. Ist also nicht man nehme Code und schiebt es einmal rüber. Dann gibt es auch Lizenzprobleme, die es nicht einfach machen Sachen zu übergeben. Qt erforder ein CLA und bei Klassen, die vor Jahren entwickelt wurden, ist es nicht einfach die Erlaubnis aller Copyrightholder einzuholen (besonders schwierig wenn die Klasse mal migriert wurde mit Code gegebenenfalls aus anderen Klassen und so weiter).
Last but not least gibt es Sachen in den KDE libs, die man wirklich nicht in Qt braucht. Wer braucht denn schon eine Bibliothek um Fenstermanager unter X11 zu erstellen?
Lange Rede kurzer Sinn: KDE Frameworks werden benötigt, aber nicht in der Form wie aktuell die KDE Libs. Die Inter-Modul Abhängigketien müssen aufgebrochen werden und so viel wie möglich muss nur von Qt abhängen, was es einfacher mach diese Module zusätzlich bereitzustellen. Das ist was unsere Frameworksentwickler machen und auch von Qt sehr begrüßt wird.
Cool, dann freu ich mich auf eine Menge neuer Qt Module die mir die Arbeit erleichtern
Wenn hier schom Entwickler sind.
Gibt es eine Seite wo verwaiste KDE Projekte sind die nicht nach KDE 4 portiert wurden bzw. keinen Maintainer mehr haben ? Ich habe diesbezüglich nitchts gefunden.
Alternativ würde ich einen billigen Daemon Tool clone aka "KMount" entwickeln. Meine zweite Projektidee fällt mir grad nicht ein.
Du suchst also arbeit? ;D
Ich hät da ne Idee:
KDE und Unity verwenden ja das gleiche, von freedesktop.org als Standard definierte DBus Protokoll um die sogenannten Notifications anzuzeigen. Zum Erstellen solcher Notifications gibts Python & Vala Libraries, aber mir ist keine Qt-Bibliothek dafür bekannt (man muss selber mit DBus sprechen).
Wär echt cool wenn man als Qt Entwickler auch auf sowas zurückgreifen kann.
Weitere Infos unter:
http://developer.ubuntu.com/resources/technologies/notification/
http://www.galago-project.org/specs/notification/0.9/x408.html#command-notify
Würds selber machen, aber arbeite gerade an einer Qt Bibliothek mit der man Ubuntu One einfacher in seine eigene App integrieren kann (launchpad.net/QUbuntuOne). Könnte dir auch helfen bezüglich DBus & QDBus.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Jul 2012 um 16:16.Was hast du nur gegen Python ? ;-)
Ich schau es mir mal an, besser wäre noch, man könnte daraus eine Masterarbeit stricken ^^
Nun ich kann ja keien Python Library aus C++ verwenden.
Und eine Qt/C++ Bibliothek kann man dann auch von Python aus verwenden.
Für eine Masterarbeit wärs wohl zu klein, denke ich.
Aber da ich keinen Master hab weiss ich das nicht.
Auch das ist aus Sicht eines KDE/Gnome Entwicklers vielleicht eine nette Sache. Aber da Qt auch auf Mac oder Windows ausgerichtet ist und beide Desktops nicht dem Konzept folgen..... naja ich lass mal das Gerede.
Wär außer KDE würde denn die Library auf Basis von Qt nutzen? Gnome sicher nicht.
Ja klar wärs nicht Plattform-Unabhängig, MS hat ja kein Notification-System afaik.
Da Gnome 3 sich nicht an den Freedesktop.org Standard hält funktionierts auch nur unter Unity & KDE. Aber man kann dann theoretisch auch in der Library automatisch erkennen unter was für einem System / DE man läuft und so auch Gnome 3, Meego und weitere Notification Systeme von anderen OS / DEs unterstützen.
Nun Gnome selber wird es vermutlich nicht verwenden. Aber ich als Entwickler der gerne mit Qt Entwickelt und möchte das sich mein Programm auch gut in den Gnome / KDE / Unity Desktop integriert würds auf alle fälle verwenden.
Andere Qt benutzenden Entwickler, z.B. die Leute, die Applikationen für Razor-Qt schreiben, oder die Entwickler von VLC, usw.
KDE Entwickler sind zwar die größte Gruppe von Entwicklern die Anwendungen mit Qt für FLOSS System schreiben, aber bei weitem nicht die einzigen
Anwendungen, die das Ende des Lebenszyklus erreicht haben finden sich in http://websvn.kde.org/tags/unmaintained/
Wenn du an aktuellen Sachen interessiert bist, dann schaue auf http://community.kde.org/KDE/Finding_The_Unloved
Danke für die Info
Der Link im Wiki zu 'Finding the unloved, 2011, part I" war verweist und wurde gerade aktualisiert.
Ein weiterer Vorschlag wäre die Quanta Plus Portierung abzuschließen.
Das habe ich mir auch gedacht, arbeitet da noch jemand dran ?
Wie würde man da am besten vorgehen ?
Klingt super!
Aber ers mal hoffe ich, dass KDE 4.9 ein Knaller wird.
> Wir planen einen Umbau
Schon wieder? Waren unnütze und blödsinnige Umbaus nicht das, was KDE4 um Jahre zurückgeworfen, wenn nicht geradezu gekillt hat?
Die gleiche Funktionalität immer und immer und immer wieder neu implementieren und debuggen macht sowas von Spaß, nich?
ließ noch mal genau: sebas schrieb, dass es ein Umbau in den Bibliotheken bei Quelltext-Kompatibilität ist.
D.h. einmal neu kompilieren, im Normalfall. Ließ dazu zum Beispiel http://www.kdab.com/porting-from-qt-4-to-qt-5/
auf dem gleichen Blog findet sich auch ein Blog Post, in dem beschrieben wird, wie man mit Hilfe eines llvm basierten Tools die Quellcodeanpassungen automatisch machen kann.
Mir ist bisher nur eine Anwendung bekannt, die etwas mehr Portierungsarbeit bei dem Umstieg auf Qt 5/KF5 brauchen wird: KWin. Und so viele Fenstermanager gibt es nicht in KDE und dank der Modularisierung kann KWin auch auf Qt 4 bleiben wenn andere Komponenten schon auf Qt 5 sind (wobei ich davon ausgehe, dass KWin eine der ersten portierten Anwendungen sein wird).