In der Nacht auf den heutigen Freitag war der große Freeze für die KDE Plattform, Workspaces und Application Releases in Version 4.6. D.h. es dürfen keine neuen Features eingespielt werden und keine Änderung an Texten vorgenommen werden. Die KDE Entwickler Community wird sich nun ganz auf das Stabilisieren und Bugfixing konzentrieren bis zum Release Ende Januar. Die erste Beta Version wird bereits am 24.November erscheinen.
Wie man sich vorstellen kann, war der gestrige Abend noch etwas stressig. Code wollte noch geschrieben werden (sonst müssten die User noch ein halbes Jahr auf ein Feature warten), Review Requests angeschaut, getestet und kommentiert werden und so weiter. Zum Glück ist das Release Team nicht ganz so streng was das Einhalten der Frist angeht und so hat ein KWin Entwickler heute morgen um halb sieben noch einen Commit eingespielt 😉
Für mich war der 4.6 Entwicklungszyklus auch sehr interessant. Es war der erste Zyklus in dem ich nicht mehr Student bin und musste diese Doppelbelastung auch erst einmal organisiert bekommen. Gerade wenn man als Softwareentwickler arbeitet, hat man ja abends nicht immer die Lust noch einmal zu programmieren. So muss ich leider auch erkennen, dass ich weit weniger für KWin implementieren konnte, als ich mir eigentlich vorgenommen hatte.
Das 4.6 Release ist aus KWin Sicht nun für mich besonders interessant, da es das erste Release ist, bei dem mein Name in den aboutData als Maintainer aufgeführt ist. Natürlich fühle ich mich geehrt Maintainer einer der wichtigsten, ältesten und ausgereiftesten Komponenten des KDE Workspaces sein zu dürfen. Wenn mir jemand vor drei Jahren gesagt hätte, dass ich Maintainer von KWin werde, hätte ich ihn wohl nur verwirrt angeschaut. Aber das ist ja das schöne, dass man nicht in die Zukunft schauen kann.
Trotzdem werde ich das nun machen. Mit dem Freeze hinter sich, hat man mehrere Monate Zeit um sich Gedanken zum nächsten Zyklus zu machen. Was wollen wir in 4.7 neues bieten, worauf sollen wir achten? In den letzten Wochen hat sich für mich angedeutet worauf wir uns konzentrieren müssen. Wayland wird vermutlich kommen, genauso wie ARM. KWin ist hier sicherlich die Anwendung aus dem KDE Lager, welche am stärksten angepasst werden muss. 4.7 wird also der erste Releasezyklus auf dem langen Weg zu Wayland. Insgesamt ist es nicht so viel Arbeit wie ich anfänglich dachte, jedoch wird es sicherlich mindestens zwei Jahre dauern, bis diese Anpassung abgeschlossen sind. Ich hoffe hier vor allem mit den Compiz Entwicklern zusammenarbeiten zu können.
Insgesamt bedeutet das nun eine Verschiebung meiner Implementierungsideen. Wollte ich eigentlich KWin zuerst auf OpenGL ES 1.1 portieren, werde ich die Arbeit daran nun einstellen und direkt auf OpenGL ES 2 gehen. Dies ist nicht nur für mobile Geräte interessant, sondern wird auch benötigt um Wayland zu unterstützen. Alle Änderungen, die ich dabei mache, werden auch direkt für die aktuelle Desktop Version vorteilhaft sein. So plane ich das einfache Rendern von Fenstern (keine Effekte aktiv) auf einen moderneren Code zu heben. Der Shader dafür liegt schon auf Papier niedergeschrieben auf meinem Schreibtisch 😉 Leider ist das auch immer eine Gratwanderung: Optimierung bei einem Treiber kann zu riesigen Performanceproblemen bei einem anderen führen. Da aber der alte Code nicht entfernt wird, sollte es problemlos zurückschaltbar sein.
Interessante Zeiten liegen vor den Entwicklern von s/Fenstermanagern/Compositor/.
=-=-=-=-=
Powered by Blogilo
Nette Aussichten 🙂
Darf der interessierte Leser auch erfahren, wo du gerade beruflich Software entwickelst?
Beim DKFZ
Wenn man schon mal die Gelegenheit hat zu einem Entwickler in den alltag zu schauen, würde ich gerne wissen wie Ihr solche Sachen organisiert. Wenn ihr mit anderen Entwicklern korrespondiert werden da einfach Codebestandteile herumgereicht, gibt es bei euch so etwas wie eine Bibliothek mit Häufig verwendeten Codes, die man dann nur noch bedarfsgerecht anpassen muss? Wie informiert ihr euch untereinander, welcher Code mit welchem Code Probleme bereitet, und welche Elemente zum alten Eisen gehören? Es wird ja wohl hoffentlich nicht einfach nur suchen der Zeilen hinter der # sein.
Wenn du das so im Blog schreibst, tönt es ja fast schon so, als ob man eiligst irgendwelche Feature entwickelt, um möglichst viel einbringen zu können und dann nach dem Codefreeze erst angefangen wird die Fehler im eigenen Code zu suchen und zu beheben oder sogar sich nur noch auf noch mehr neues konzentriert als bestehendes zu warten.
Wie arbeitest du eigentlich nun mit Canonical und Fedora zusammen? Da die ja Wayland so gross angekündigt haben, müsstet ihr dort bestimmt Kontaktpersonen haben.
Gruss
ein nie-nicht-nur-ein-bischen-Programierer bzw. Ubuntu Desktop user 🙂
(ja ich weiss bestätigte Vorurteile)
Oha merke gerade, das ich etwas die Sache mit den Features doch etwas sehr Provokant geschrieben habe, was so nicht meinen eindrücken entspricht.
War nicht meine Absicht.
Sorry
Hmm die Frage zu beantworten ist sehr schwierig, da du offensichtlich nicht viel weißt wie die Entwicklung abläuft. Kommunikation geschieht meistens in IRC und Mailinglisten – code Beispiele sind da eher selten. Zum Anschauen von Code haben wir spezielle Werkzeuge, bei denen man auch Kommentare hinterlassen kann. Probleme finden wir durch Lesen des Codes bzw. einfach durch Erfahrung.
Hallo
Ich hab mal eine frage.
Und zwar kann man nicht zb kwin-nvidia ,kwin-ati usw machen ? das man Die Optimierungen in den Paketen vorhanden ist ? ich bin kein Programmierer , das war nur das erste an das ich gedacht habe als ich deinen “blog” las.
Sorry, aber die Frage verstehe ich nicht
Ich nehme an, er meint die Aufteilung der Grafikchip-spezifischen Teile in getrennte Pakete
genau das meine ich:)
Das wäre unmöglich. Wir bräuchten nicht zwei oder drei kwin Pakete sondern so an die hundert. Es gibt so viele Kombinationen von GPU und Treiber, dass wir keine Ahnung haben was mit welcher Karte funktioniert oder nicht. Deswegen haben wir Methoden um die Treiber zu fragen was sie unterstützen und passen uns dann zur Laufzeit an.
Tja, dass ist eines der Probleme von OpenSource. Viele der Programmierer sind Schüler/Stunden. Sobald die im Berufsleben landen und/oder eine Familie gründen schrumpft das Engagement.
Soll keine Anschuldigung sein, dass ist der Lauf der Dinge.
Ja, ich kann deine “bedenken” nachvollziehen.
Genau deshalb benötigt die OpenSource-Community auch Firmen wie z.B. Google, RedHat, Canoncial, Novell usw. Ohne jene Firmen, gäbe es kein OpenSource (mehr).
Zumindest ist das meine Meinung zu diesem Thema. Ohne Firmen, die OpenSource finanziell fördern (wollen), sähe es schlecht aus um Linux und Co.
OpenSource gäbe es dann schon noch. Aber Linux wäre nicht da, wo es jetzt ist sondern wäre wirklich noch das oft zitierte “Frickelsystem”
Bei reinen Hobbyprogrammierern wäre die Fluktuation zu groß, so dass sich nur sehr wenig kompetente und erfahrene Programmierer langfristig an den Projekten beteiligen
es ist immer schön über deine kde-arbeit zu lesen, und so möchte ich dir vorallemy dafür danken. für die arbeit an kde, für deine blogbeiträge.
ich selbst würde kde sehr gerne viel öfters nutzen, jedoch finde ich,dass kde einfach keinen “stiel” hat. das mein ich gar nicht bôse, nur könnte man nach außen viel mehr machen. die distribution die in dieser richtung im moment wohl am meisten macht(ubuntu) kümmert sich leider um kde “gar nicht”. ebenso find ich es schade,dass mit all den paneln, widgets etc jede distribution “gleich aussieht”,anstatt auch mal neues auszuprobieren. vielleicjt kommt ja durch nokia ein wenig mehr schwung darein,bei deren momentanen situation hab ich aber leider noch starke schmerzen…
Hmm, zumidest Kubuntu hat sich doch mittlerweile zu einer richtig guten KDE-Distri entwickelt. Aber ich weiß natürlich nicht, wie die Unterstützung seitens Canoncial aussieht.
Vielleicht kann Martin etwas dazu sagen? Mich würde das auch mal interessieren.
Aber bezüglich “gleich aussehen”, war es doch bei Gnome bisher auch nicht anders, oder? Soweit ich weiß, haben die verschiedenen (Gnome-)Distris doch auch nur die Skins und Hintergrundthemen ausgetauscht (abgesehen jetzt mal von OpenSuse mit YAST). Nur Canoncial brecht jetzt bei Gnome3 mit Unity vor und versucht, ein Alleinstellungsmerkmal für Ubuntu zu entwickeln. Ok, da es OpenSource sein wird, können es natürlich auch andere Distris implementieren, aber es wird ja wohl auch speziell auf Ubuntu angepasst und deshalb könnte die Implementierung vielleicht problematisch für andere Distris werden.
Ich finde jedenfalls, dass Canoncial auf einem sehr guten weg ist.
Dass KDE Plasma überall gleich aussieht, ist kein Zufall, sondern gewollt. KDE hat sehr gute Designer und Distributionen können und wollen da nichts eigenes machen, da es das hohe Level von Upstream nicht erreichen könnte. Anpassungen bei den Distributionen werden zusammen mit unseren Designern vorgenommen um die visuelle Identität beeider Projekte zu wahren – sieht man z.B. sehr schön in openSUSE oder beim Kubuntu Installer.
um ehrlich zu sein empfinde ich es als großen Vorteil von KDE, das Canonical sich da wenig einmischt. Canonical kann im besten Fall manche Sachen in Gnome verbessern. Aber von KDE haben sie sehr wenig Ahnung. Und wenn Canonical etwas für KDE “verbessern” möchte, was bei Gnome notwendig war, dann ist das Resultat oft weniger gut als das was KDE eh schon mitbringt (Ayatana). Ich war immer froh, dass Canonical den fähigen KDE-Leuten wenig “hilft” (= aufzwingen möchte).
Ich find‘s ja schon grausig, dass man Kubuntu dieses PulseAudio aufgzwungen hat. Das ist so ziemlich das allererste, was rausfliegt. Bei Kumpels auch immer: „hm, der Ton geht nicht“ – „Probier mal sudo apt-get remove pulseaudio und starte neu“ – „Ah, thx“. Mag ja für Gnome ganz gut sein und PulseAudio hat vielleicht auch Vorteile, aber für mich ists einfach nur unausgereift und nervig. Ich hoffe, dass die GStreamer-Umstellung in 11.04 nicht auch so ein Desaster wird.
also bis 10.04 hätte ich dir da jetzt voll und ganz aus eigener erfahrung zugestimmt… mit 10.10 hatte ich bis jetzt (zum glück) auf mehreren maschinen keine probleme mit pluse audio.. die möglichkeit die einzelnen anwendungen separat zu steuern (kommt ja von pulseaudio wenn ich nicht irre) finde ich auch ganz nett…
vielleicht tut sich da ja doch mal was in richtung einer besserung ?!
Ich liebe und hasse KDE.
Wenn ein Linux Desktop – dann KDE. Warum ber hat KDE, welches so massiv Qt einsetzt, so Probleme mit dem skalieren von Fenstern unter NVIDIA Karten?
Klar, es gibt workarounds, aber sie funktionieren mehr schlacht als Recht. Andere Fenstermanager wie Metacity oder Openbox bekommen das Butterweich hin – egal ob nun 3d oder nicht.
Dabei ist es egal ob ich KDE unter Gentoo selber baue, Kunbuntu oder Fedora verwende. Es ist egal ob ich den Closed- oder Open-source Treiber verwende. Auch die hundertfach beschriebene “Tricks und Abhilfen” funktionieren nicht. Sogar der Wechsel auf ein anderes NVIDIA Modell hilft nicht.
Eure/Deine Arbeit in ehren – aber wieso schafft KWin nicht das was jeder simple WM schafft – sauber zu funktionieren?
Dieses sehr nervige Thema begleitet die ganze KDE4 Serie und sollte endlich mal angegangen werden!
Nun genau das ist aber das Problem: weder Metacity noch Openbox können OpenGL (also 3D). Compiz umgeht das Problem sehr geschickt (KWin kann den Trick von Compiz auch). Flüssiges Vergrößern mit OpenGL ist mit dem NVIDIA blob nicht möglich – liegt nicht an uns, sondern an NVIDIA. Kannst einfach mal mit Nouveau dir das anschauen.
Wirkliches flüssiges Resizen wird es aber erst mit Wayland geben…
Hallo,
selbst mit deaktvierten 3D-Effeckten besteht das Problem. Ob nun NVIDIA oder Nouveau – beide liefern das gleiche Ergebnis.
Wenn Kwin diesen Compiz Trick beherscht, wie aktiviert man ihn und wieso ist er nicht per Default aktiv? Die meiste Dokumentation zu diesem Thema ist sehr wiedersprüchlich und enthält Options für xorg.conf. Das KDE Projekt stellt zwar selber Dokumentation zu diesem Thema – aber eine wirkliche Lösung ist nicht in sicht.
Das ist einer der Gründe warum ich gespannt auf Wayland warte. Ich hoffe diesen kleinen nervenden Dinge verschwinden dann endlich. Man kann zwar mit leben, aber sie nerven halt ungemein ;).
Was das deaktivierte OpenGL angeht, weiß ich nicht warum es langsamer ist. Jedoch sollte dir hoffentlich bewusst sein, dass die Oberfläche jeder KDE Anwendung bedeutend komplexer ist als Anwendungen anderer Desktopumgebungen. Solltest du jetzt sagen: ja aber unter GNOME hab ich auch schon KDE Anwendungen getestet, dann weise ich dich darauf hin, dass unter GNOME KDE Anwendungen GTK zum Rendern verwenden. Das flüssige Skalieren einer Anwendung ist ein sehr aufwändiger Prozess und kann unter X einfach nicht schnell erfolgen, wenn die Oberfläche komplex ist. Man kann halt nicht alles haben.
Der Trick von Compiz ist keine Live Updates beim Vergrößern zu machen. Dafür hat KWin auch eine Option namens “Display content in resizing windows”. Deaktiviert man diese, ist das Vergrößern schnell. Zusätzlich gibt es für Compositing auch noch einen Resize Effekt, der entweder schnelles Texture scaling verwendet oder eine Outline zeichnet und ist gedacht in Kombination mit dieser Option.
Danke für die klaren Fakten. Ein “so schaut es aus” ist mir lieber als dieses überall zu findene “NVIDA ist schuld”.