Posted on

New Decoration control module

There are a few things in KDE’s desktop shell which have not changed for a very long time. For example I remember that the first KDE version I used (that was a 3.x with x << 5) had the same control module for window decorations as the one we will have in KDE SC 4.4. The interface displays a dropdown list with the names of the available decorations, a configuration panel for the selected decoration and a preview. This results in wonderful tabs inside tabs user interfaces – just look at the Oxygen configuration in 4.4.

With KDE SC 4.5 there will be a new interface which could be called the Qt 4 port of the decoration control module. The dropdown is replaced by a list view displaying previews of each decoration. The configuration panel is moved to a dialog which is accessible from a configure button next to the preview.

New decoration KCM

As I think it’s important to honor those who should be honored a button to access about data has been added. So if you have written a decoration please add your author information to the desktop file of your decoration.

Aurorae themes are included in the list just like "normal" decorations. The fact that Aurorae is a theme engine is an irrelevant implementation detail for the user and by that it should be hidden. And so KWin finally supports Get Hot New Stuff for decorations – that’s just awesome. I hope we will be able to integrate deKorator themes in the same way.

Unfortunately I was not able to finish this for 4.4.

=-=-=-=-=
Powered by Blogilo

Posted on

Wie man Entwicklern bei Bugs helfen kann

Gestern hab ich ja darüber geschrieben wie der Weg von Bug zu Fix ist. Nun hab ich einen wichtigen Punkt vergessen: Du, ja genau Du, kannst den Entwicklern dabei nämlich helfen. Du brauchst dazu nicht mal programmieren zu können.

Ich hatte ja erwähnt, dass etwa 40 % aller Bugs die für KWin gemeldet werden, bereits gemeldet sind. D.h. ich gehe hin suche den korrekten und markiere ihn als Duplicate. Ein Beispiel aus der Beta 1: KWin crashed after a Konqueror crash Uns ist kurz vor Beta 1 eine Regression in den Code gekommen und wie man an meinem Commit (erster Kommentar) sieht, war es eine Trivialität. Dieser Crash hat uns durch die ganze Beta 1 verfolgt und er hat entsprechend viele Duplicates. Aber alle Duplicate Markierungen sind von Entwicklern gesetzt und das muss eigentlich nicht sein. Das könnten die Nutzer übernehmen. In so einem Fall ist es wirklich einfach: der Backtrace ist immer gleich und DrKonqui hängt die möglichen Duplikate sogar an (einfach auf einen der Duplikate klicken).

Ein anderer Fall sind normale Bugs – auch hier kann uns jeder Nutzer eigentlich helfen. Wenn ein Bug aufgemacht wird, steht er zuerst auf "UNCONFIRMED". Hier könnte nun ein Nutzer eigentlich schauen ob das überhaupt stimmt. Ist die Beschreibung korrekt, lässt sich der Bug reproduzieren, etc. Also den Bug soweit aufbereiten, dass der Entwickler damit etwas anfangen kann. Typischer Fall eines Bugs: KWin is slow – please improve. Toll hilft nichts. Hier müsste nachgefragt werden, welche Hardware er benutzt, welche Anwendungen, ob Compositing aktiviert ist, etc. Für mich als Entwickler ist so eine allgemeine Beschreibung natürlich wertlos und in der Zeit die ich nachfrage, könnte ich Entwicklungsarbeit leisten.

Und selbst bei Crashes kann der Nutzer sehr einfach mithelfen. Viele Crashes werden ohne die Debug Pakete installiert zu haben gepostet. Da können wir dann gar nichts machen. Hier gibt es die Möglichkeit nachzufragen oder wenn ein Weg angegeben ist, wie man KWin crashen lassen kann, einfach reproduzieren und einen guten Crash anhängen.

Dennoch muss ich nachfragen um meine Bugliste sauber zu halten. KWin hat aktuell etwa 360 offene Bugs. Wenn ich die Liste durchgehe und manuell Duplicates suche dann bekomme ich idR in einer Stunde 10 Bugs weg. Nicht gerade viel. Viele Bugs haben einen Kommentar wie "Is this still an issue in KDE SC 4.3.3?" und danach ein halbes Jahr keine Antwort mehr. In so einem Fall kann der Bug zugemacht werden – scheint niemanden zu interessieren und war entweder nie ein Bug oder ist behoben. Auch das ist etwas was Nutzer übernehmen können.

Wenn ein Bug überprüft ist, dann kann er von "UNCONFIRMED" auf "NEW" geändert werden. Dies könnte von den Entwicklern nun genutzt werden um zuverlässig nach Bugs zu suchen. Die unnützen Bugs erscheinen gar nicht und der Entwickler kann sich einen Bug schnappen und ihn beheben ohne großen Verwaltungsaufwand. Ja das wäre die ideale Welt 🙂

Nun muss man natürlich nicht alleine als Nutzer plötzlich anfangen hier die Bugs zu durchforsten, sondern es gibt den KDE Bug Squad, der genau das macht. Regelmäßig veranstaltet die Gruppe Bug Days und aktuell gibt es auf forum.kde.org Bug Weeks. Der Bug Squad braucht übrigens immer Nachwuchs da viele Bug Jäger plötzlich abtrifften in die Entwicklung. So wurde die Überarbeitung von DrKonqui von einem Bug Squad Mitglied durchgeführt – Dario hatte einfach gesehen was nötig ist. Das Team beißt nicht und hilft immer weiter und Entwickler sind wirklich dankbar für die Arbeit. Also nichts wie los nach #kde-bugs.

Ach und natürlich braucht nicht nur KDE Nutzer, die bei Bugs helfen, sondern jedes Projekt.

=-=-=-=-=
Powered by Blogilo

Posted on

Vom Bug zum Fix

Angesichts der aktuellen Vorbereitung auf das Release der KDE Software Compilation in Version 4.4 hab ich gedacht ich beschreibe mal die Schritte, die ich gehen muss um einen gemeldeten Bug in KWin zu beheben. Denke das könnte ganz interessant sein, vor allem wenn man nicht so vertraut mit der Entwicklung ist 😉

Am Anfang steht der Bugreport. Im IRC channel #kwin gibt es einen kleinen bot, der neue Bug reports meldet. Da ich auch ein highlight auf das Wort "kwin" habe und dieses zufälligerweise in jeder Bug Meldung enthalten ist, erhalte ich eine schöne Benachrichtigung. Im Channel ist dann auch gleich die URL zum draufklicken enthalten. Wenn ich nicht am Rechner sitze, dann bekomme ich neue Bugs trotzdem mit: alle Bugzilla Mails werden auch an die kwin Mailingliste gesendet und zusätzlich hab ich in Akregator einen RSS feeds für neue Bugs (eigentlich überflüssig).

Ein Bug fällt in eine von drei Kategorien:

  • Wishlist
  • Bug
  • Crash

Wishlist ist ein Wunsch und so etwas wird idR erst einmal ignoriert. Gerade in der Zeit, in der man sich auf das Beheben von Bugs konzentriert, dürfen neue Wünsche eh nicht implementiert werden. Viele der Wünsche sind auch einfach nun ja Traumkonzert und lassen sich zwischen schwer bis gar nicht umsetzen.

Ein Bug ist ein Fehlvehalten der Anwendung. Im Falle von KWin beziehen sich die Meisten auf irgendwelche Probleme mit den Desktop Effekten. Viele der Meldungen sind sehr ungenau und nur unter bestimmten Fällen zu reproduzieren. Für einen Bug gilt eigentlich, dass er nicht besonders priorisiert ist. Außer es ist wirklich ein gravierender Bug.

Crash ist nun eine Sonderform eines Bugs: die Anwendung hat einen Nullpointer dereferenziert und ist abgestürzt. Bei KWin nicht so schlimm, da es sich automatisch neustartet, aber trotzdem unangenehm. Zum Glück sind mittlerweile die Anzahl der Crashes zurückgegangen, so dass im Normalfall keiner auftritt.

Bei allen drei Arten gilt, dass wir zuerst überprüfen müssen, ob der Bug schon existiert. In etwa 40 % der Fälle ist das so. Bei Crashreports ist das am Einfachsten: DrKonqui findet die automatisch und hängt die Nummer des Duplikats gleich dran. Leider reporten die User häufig trotzdem. In so einem Fall ist der Bug schnell weg: Nummer rein, und abschicken. Ansonsten wird die Suchmaschine im Hirn eingeschaltet und überlegt, ob man so einen Crash nicht schon mal gelesen hatte und wenn ja dann wird geschickt über die Suche von Bugzilla den passenden gefunden.

Natürlich ist es hilfreich den Bug reproduzieren zu können. Leider ist das nicht immer möglich, weil ganz bestimmte Bedingungen vorliegen müssen. Hatte aktuell so einen Fall, dass es nur crashed, wenn man Present Windows als Alt+Tab Effekt verwendet, während er aktiviert ist die Anzahl der Fenster auf 0 geht und man dann im richtigen Augenblick mit der Maus klickt. In dem Fall war dann zum Glück der Quellcode eindeutig und konnte sehr leicht auch ohne Reproduzierung behoben werden 😉

Die Crash Reports enthalten einen automatisch generierten Stacktrace, der Aufschluss darüber gibt an welcher Stelle im Code der Crash auftrat. Dabei werden die Code Zeilen sogar genannt und manchmal sogar die Werte übergebener Variablen. Für die Datenschutzfanatiker: nein daraus lassen sich keine privaten Daten rückverfolgen. Im Falle von KWin ist das maximal, dass man erfährt auf welchen Desktop der User gerade wechselte. Komplizierte Daten werden als Zeiger auf eine Datenstruktur übergeben – aus der Adresse kann man nichts rauslesen außer, dass sie vllt. 0 war. Ist der Bug gegen KDE SC 4.3 reportet worden so stimmen sehr häufig die Zeilennummern nicht mehr. Hier ist es dann hilfreich, wenn man den Crash selbst reproduzieren kann, weil man dann die passenden Zeilennummern erhält.

Mit der Zeilennummer bewaffnet, geht es dann in die Entwicklungsumgebung und man schaut sich den Quellcode an. In den meisten Fällen macht es schlicht und ergreifend "Aha" und der Crash ist offensichtlich. Nun die berechtigte Frage: Warum trat er dann auf? Nehmen wir das Beispiel von oben mit Present Windows: es wurde nicht daran gedacht, dass es vorkommen kann, dass man mit der Maus klickt, wenn kein Fenster da ist. Der Code ist ja gedacht ein Fenster auszuwählen. Ja eine falsche Annahme. Über den Stacktrace und den übergebenen Werten ist dann erkennbar welcher Zeiger auf 0 zeigt und man kann den Code anpassen, so dass dieser Fall entweder nicht mehr auftritt oder abgefangen wird.

Der nächste Schritt ist das neubauen von KWin (zum Glück direkt aus der IDE) und testen ob der Crash behoben ist. Wenn dem so ist, dann kann der veränderte Code in das Quellcodeverwaltungssystem eingespielt werden. KDE verwendet eigentlich SVN, was aber für mich eher unpraktisch ist, deswegen nutze ich selbst git und habe einen über git-svn verwalteten Checkout von kwin. Zuerst überprüfe ich die veränderten Code Zeilen mittels git diff – das zeigt mir in der Konsole an, was sich genau verändert hat. Eine wichtige Überprüfung um nicht irgendwelchen Müll durch das Testen (debug Ausgaben u.ä.) ausversehen einzuspielen. Auch eine gute Überprüfung ob der Coding Style eingehalten wurde. Der nächste Schritt ist die Änderung mittels git add und/oder git commit (-a) als lokalen Commit einzuspielen. Hierbei gibt man eine aussagekräftige Commit Message ein und trägt mittels BUG: NUMMER den Bug ein, welcher dadurch behoben wird. Nun muss der Code mittels git svn dcommit in das KDE SVN übertragen werden. Dabei wird dank dem BUG Schlüsselwort der zugehörige Bugreport automatisch geschlossen und ein Kommentar eingefügt.

Die Änderung wurde nun aber nur in trunk eingespielt – dem Hauptentwicklungszweig und das was in mehr als einem halben Jahr mal KDE SC 4.5 werden soll. Natürlich möchte ich den Bug auch in 4.4 behoben haben und dazu muss der Patch in den branch zurückportiert werden. Würde ich nicht git verwenden, wäre das richtig einfach, denn es gibt ein Skript dafür. Würde KDE git verwenden wäre es noch einfacher. Für mich bedeutet es manuelle Arbeit. Also mittels git show den letzten Commit in eine temporäre Datei speichern und in mein Verzeichnis wechseln, in dem der 4.4 Code rumliegt. Hier kann ich mit patch -i die Änderungen lokal einspielen. Bei 4.4 geht das noch ohne irgendwelches meckern, da es im Prinzip noch der identische Code ist. Nun müsste ich eigentlich die Änderung einspielen, hab aber mein Konsolen SVN Wissen dank git verlernt und nutze nun Dolphins SVN Integration. Dolphin öffnen, an die passende Stelle navigieren, über das Kontextmenü noch mal den Diff anzeigen lassen (lieber einmal zu viel kontrolliert, als einmal zu wenig) und die Datei committen. Als Commit Message wird die gleiche Meldung wie zuvor in git verwendet, jedoch mit dem Zusatz "Backport rev SVN-Nummer" und CCBUG anstatt BUG. Dadurch wird einfach nur eine Meldung an den Bug angehängt. Und da wir ja fleißig sind, machen wir das ganze für 4.3 auch noch mal sofern der Code passt.

So wie lange dauert so etwas? Beispiel von gestern abend: Um 20:54 Uhr hat mir ein User im IRC einen Crash gemeldet, er klang komisch und ich hab sofort ausprobiert und ihn reproduzieren können. Kdevelop war bereits mit der passenden Datei geöffnet (ist eigentlich immer offen) und ich konnte direkt an die Quellcodezeile springen. Um 21:06 konnte ich dem User melden, dass der Crash in trunk und branch behoben ist. Für den Backport in einen Branch brauche ich etwa 2 min – insgesamt alse 4 (IRC Log von CIA Bot). Zum Reproduzieren, Crashen und Testen, dass es wirklich behoben ist also gerade mal vier bis fünf Minuten. Ja der war wirklich einfach 😉 Heute saß ich an einem, bei dem ich nach etwa einer Stunde erst mal aufgehört habe, weil ich ihn nicht beheben konnte. Wird aber definitiv in 4.4 (notfalls über Würgaround) behoben sein.

=-=-=-=-=
Powered by Blogilo

Posted on

Freude mit MTAs

Manche wissen ja, dass ich mich im Rahmen meiner Thesis mit Emails und Spambekämpfung beschäftige. Seit Silvester ist das ganze bei mir im produktiven Einsatz zur Evaluierung und einige sind da auch schon nichtsahnend reinmaschiert 😉

Nun heute bin ich auf ein unerwartetes Problem gestoßen. Kurz zum Hintergrund: meine Implementierung antwortet automatisiert auf einkommende Mails unter bestimmten Voraussetzungen. Daher wird auch auf Spam Mails geantwortet und wie man das erwarten würde, wird diese Mail nie zugestellt und ein Mailserver wird mir das mitteilen. Da das ganze ja erwartet ist, ist die Implementierung darauf vorbereitet und behandelt diese Delivery Status Notifications (DSN) gesondert um zu verhindern, dass noch mal darauf eine Mail rausgesendet wird.

Mit dem RFC 3464 aus dem Jahre 2003 und seinem Vorgänger RFC 1894 aus dem Jahre 1996 gibt es dazu auch eine Standard. Eine DSN ist eine MIME Message mit dem Content-Type "multipart/report", der mehrere Bereiche enthält. Darunter die eigentliche Benachrichtigung ("Notification") und idR zwei Anhänge: den technischen "Delivery report" und die optionale ursprüngliche Nachricht. Für all diese Bereiche sind sinnvolle standardisierte MIME Types vergeben.

Auf meinem Server und lokal auf meinem Laptop läuft jeweils ein Postfix. Beim Implementieren hat das auch alles schön immer funktioniert – die Mail an foo@bar.baz kann nicht zugestellt werden und löst eine DSN nach RFC 3464 aus. Diese wird gut verarbeitet – selbst die optionale ursprüngliche Mail wird berücksichtigt. Auch die erste Woche in dem produktiven Einsatz zeigte keine Probleme. Der Standard ist ja schon recht alt und man kann ja davon ausgehen, dass alle Mail Transfer Agents (MTA) diesen umsetzen.

Tja, dass es MTAs gibt, die diesen RFC nicht implementieren, damit hatte ich nicht gerechnet. Aber es gibt ihn: Exim – der Standard MTA unter Debian. Der Feature Request es zu implementieren stammt aus dem Jahr 1999 und wurde in Bugzilla importiert – dürfte also noch älter sein. Ich frage mich ja jetzt wirklich warum eine Distribution einen MTA standardmäßig installiert, der dies nicht unterstützt. Die Bounces, die Exim rausschickt, sind keine MIME Messages und nur schwer automatisiert zu erkennen. Das einzige Indiz ist ein X-Failed-Recipients Header, die ursprüngliche Mail ist in den Message Body kopiert. Diese Mail wird von meiner Implementierung natürlich (noch) nicht erkannt und löst daher eine schöne Mail-Loop aus: automatisierte Mail raus, Notification rein, autmatisierte Mail raus usw. usw. Nach der dritten Mail hab ich bemerkt dass da was nicht stimmt und manuell unterbrochen.

Ach wie einfach wäre die Internet Welt, wenn sich doch mal alle an die Standards halten würden 🙁 Nun kann ich überlegen ob ich akzeptiere, dass bounces von Exim Probleme bereiten oder versuchen die Mails zu parsen. Auf letzteres würde ich gerne verzichten, weil es mir etwas zu unsicher ist, mich auf einen einzigen Header zu verlassen. Außerdem ist es wichtig, die ursprüngliche Mail zu extrahieren, da es die einzige verlässliche Information ist, ob die Mail von der Implementierung versendet wurde. Da man so freundlich ist die Mail in den Body zu hängen, gibt es natürlich keinen Anhaltspunkt wo sie beginnt und endet. Gäbe es prinzipiell aber laut $SUCHMASCHINE ist die Nachricht lokalisiert.

Ach so was macht Freude.

=-=-=-=-=
Powered by Blogilo

Posted on

Wechsel auf KDE SC 4.4

Einige werden es ja wissen, dass ich aktuell an meiner Masterthesis arbeite und dafür Akonadi aus der KDE Plattform in Version 4.4 einsetze. Es ist für meine Aufgabenstellung die perfekte Lösung. Nun nutze ich viele der Neuerungen in KDE SC 4.4 – nicht nur von Akonadi, sondern auch die neu Lösung des Systemabschnitts (Status Notifiers).

Nun hatte ich das Problem, dass ich das ganze schlecht testen konnte. Da die Status Notifier in KDE SC 4.3 nur experimentell waren und die API sich geändert hat, konnte meine 4.4 Anwendung nicht mit dem 4.3 Workspace „sprechen“ und die Funktionalität war nicht vorhanden. Meine Lösung für das Problem ist eigentlich ein zweiter X Server in dem eine reine 4.4 Sitzung läuft. Unglücklicherweise meint mein System aktuell sich aufzuhängen, wenn ich zwischen X Sessions wechsel. So auch heute als ich wieder testen wollte.

Da ich mittlerweile soweit bin, dass ich über den Einsatz im Produktivsystem nachdenke (d.h. ich vertraue meiner Implementierung so weit, dass ich sie auf meine E-Mails loslassen werde und keine Angst mehr vor Datenverlust habe) brauche ich eine 4.4 Sitzung. Also nach dem freeze bedingten Neustart hat es mir gereicht und anstatt in die 4.3 Sitzung hab ich zum ersten Mal mein Produktivsystem in das selbstkompilierte 4.4 gestartet.

Bisher hatte ich 4.4 immer nur zum Testen eingesetzt und das ist ja nicht wirklich vergleichbar. Nun sehe ich also zum ersten Mal im produktiven Einsatz die Früchte der Arbeit des letzten halben Jahres. Und ich bin wirklich begeistert. Das System fühlt sich bedeutend flüssiger an, die leichten Animationen fallen nicht störend auf, sondern machen das System angenehmer. Auch meine eigenen Implementierungen machen sich sehr gut: Alt+Tab ist eine tolle Verbesserung im Vergleich zu vorher und auch Aurorae gefällt mir gerade sehr gut – mittlerweile gibt es ja einige nette Themes. Von den anfänglichen Performance Problemen merke ich auch nichts mehr. Generell ist das Vergrößern der Fenster bedeutend angenehmer geworden.

Insgesamt fühlt sich 4.4 schon sehr rund an. Die Veränderungen sind größtenteils gering aber sehr nützlich. Hier sei bespielhaft die Verbesserungen von KRunner erwähnt: das Interface erscheint nun von KWin animiert an der oberen Bildschirmkante, die Einstellungen sind direkt in das Interface integriert und es gibt bedeutend mehr und sinnvolle Runner (auch einen von mir 😉 ).

Mit der jetzt von mir eingesetzten Version, die in etwa der Beta 2 entspricht, bin ich sehr zuversichtlich, dass 4.4 ein tolles und rundes Release wird. Wenn man mal überlegt wo die Community vor zwei Jahren stand… Nun haben wir die Säulen mit Nepomuk und Akonadi endlich integriert und der KDE Plasma Desktop ist einfach nur umwerfend. Ich war ja schon von 4.0 begeistert (vom technischen Standpunkt aus gesehen), aber dass sich das Produkt so hervorragend entwickelt, hätte ich dann doch nicht für möglich gehalten. Wer jetzt noch KDE 3.5 will, ist selber Schuld 😉

=-=-=-=-=
Powered by Blogilo

Posted on

About click through interfaces

I just read about Colibri and that motivated me to write a blog post I wanted to write for a long time. First of all I think it’s an improvement that the Ayatana notifications are now packaged and not patched into the system as in Karmic – one of the reasons why I am using Debian, now 😉 (I still think that notifications are a central part of the workspace and that a downstream should respect it’s upstream’s decision on that point.)

But that’s not the point of this post. I want to talk about click through. Aurélien advertises the Colibri notifications as click through, that you can interact with the window underneath. I think that is the failure by design of the Ayatana notifications. The fact that it’s missing actions in the notifications is just a consequence of it.

So what’s the problem with the click through? It requires compositing. A click through is only useful if the window you click through is translucent. But we do not always have compositing. There are systems where it still doesn’t work – even new ones. There are users who don’t want to use it and there are situations when kwin just turns it off due to bad performance.

Consider the situation that you are a user of a non composited environment and the notifications are shown on the upper right as in Aurélien’s screenshot. A notification appears and you click on it so that it goes away, because you do not know that they are queued. The window underneath the notification will be closed in the worst case if the click hit the close button. That’s probably not what Joe User expects. So when the environment is non-composited a click-through is a no go. The same is true if the notification is opaque or hardly translucent. But based on the description they fade away, so that is not a problem.

A solution to the non-composited environment is to make the notifications not click through when compositing is turned off. But that has drawbacks as well. Consider the situation that an experienced user knows about the click through and suspends compositing (something I do quite often). Now a notification appears and he wants to interact with the window underneath as he knows the geometry. The click is eaten by the notification although he expects that it goes through. So in that case we have a behavioral change which is in my opinion as bad as the not expected click through.

So we see as soon as compositing is turned off it breaks. So the fault in the Ayatana specification in my opinion is that functionality depends on visual representation. I’m pretty sure such a mistake would not have happened in Plasma as there are devs who can’t use compositing: "Erm you want to do that? I don’t have compositing that wouldn’t work for me." In kwin as well we ensure that compositing only adds additional features without breaking anything if compositing is turned off that is all compositing features are optional effects.

And just to make sure: this is of course no critic to Aurélien’s work. AFAIK he joined Canonical after the spec was designed and he just implemented the KDE part. I also appreciate that Ayatana is now using KDE’s status notifier spec instead of inventing yet another solution. So most of my critics on Ayatana’s approach which drove me away from Kubuntu are not valid any more (except the point mentioned in this post).

=-=-=-=-=
Powered by Blogilo

Posted on

Der Schäfer verliert seine Schafe

Die aktuelle Diskussion in der GNOME Community, ob GNOME aus GNU aussteigen soll, finde ich interessant und möchte hier meine Gedanken dazu äußern. In diesem Post wird die FSF und RMS kritisiert werden. Diese Kritik betrifft aber nicht den europäischen Ableger FSFE.

Zuerst einmal die Frage: „Was würde sich durch den Austritt ändern?“ Eigentlich nichts. GNOME als GPL lizensierte Software bleibt natürlich freie Software. Auch dürfte weder die GNOME noch die GNU Community dadurch Schaden nehmen. Beide sind groß genug um sich alleine tragen zu können und GNOME scheint sowieso nicht sehr in GNU integriert zu sein. Das einzige was passieren könnte, ist dass es schlechte Presse gibt. Hier kann man nur hoffen, dass die Communities es schaffen einen Rosenkrieg zu vermeiden.

Persönlich bin ich von der Entwicklung nicht überrascht – auch nicht, dass auf die versuchte Einmischung von Stallman mit der Diskussion über den Austritt aus GNU diskutiert wird. Für mich ist das nun die Zuspitzung einer sich seit langem abzeichnenden Entwicklung. Man denke nur an Stallmans Mono-Bashing oder die Rede auf dem Desktop Summit (die nun wohl noch in den Köpfen derjenigen rumschwirrt, die am Ende entscheiden). Stallman versucht sich in die Belange der GNOME Community einzumischen, ja sogar Forderungen zu stellen und diese mit der GNU Zugehörigkeit zu begründen. Dass dann in der Community der Gedanke aufkommen könnte die ungewollte Einmischung los zu werden, ist nachvollziehbar.

Über die Frage, ob proprietäre Anwendungen auf planet GNOME erwähnt werden dürfen, lässt sich natürlich diskutieren. Persönlich stören mich z.B. die vielen Mono Posting auch – besonders wenn es um irgendwelche Anwendungen auf proprietären Systemen geht. Aber betrachtet man sich die Zielsetzung des Planets, so sind diese Beiträge klar erlaubt. Gerade die Posts zu VMWare (der Stein des Anstoßes) halte ich sogar für recht wichtig, da es zeigt, dass bei VMWare Leute aus der Community arbeiten, Leute, die die Firma von innen heraus öffnen können. Verbietet man ihnen über ihre Arbeit zu bloggen, zerstört man am Ende vielleicht den kleinen Pfad, um VMWare zur Open Source Community zu führen.

Nun hatte ich ja im Juli das Glück eine Rede von RMS zu hören und seine Argumentation zu sehen. Für ihn gibt es schwarz und weiß, gut und böse. Freie Software gut, nicht freie (einschließlich OpenSource, d.h. z.B. BSD) böse. Gerade beim Beispiel Mono konnte man das recht gut sehen. Die Möglichkeit, dass sich Microsoft der OpenSource Welt hin öffnet, wird nicht gesehen. Microsoft ist böse, daher darf man nichts verwenden was von Microsoft kommt (sinngemäßes Zitat). Für die meisten Open Source Entwickler ist diese Argumentation natürlich nicht haltbar. Vor 20 Jahren konnte man freie Software mit dem Argument der Freiheit vermarkten. RMS hatte damals seine Jünger und eine Rede der Art hat perfekt gepasst. Heute sieht das anders aus. Freie Software muss nicht mehr die Freiheit hervorheben um sich gegen die Wettbewerber durchzusetzen, sondern kann nun auch die bessere Qualität als Argument liefern. Ich habe für mich selbst anlässlich der aktuellen Diskussion reflektiert, ob ich freie Software schreibe, weil sie frei ist oder weil es das beste Mittel zum Ziel ist. Letzteres ist der Fall. Ich möchte gute Software schreiben, die von vielen Menschen benutzt wird. Dass sie frei ist, ist toll, aber es ist nicht die Motivation die mich antreibt. Heißt auch, dass ich zum Beispiel kein Problem damit hätte an das LGPL lizensierte Qt Code beizusteuern oder an BSD lizensierte Projekte.

RMS hat seine Schafe verloren. War er früher der Hüter einer kleinen Gemeinde, die alle mit ihm übereinstimmen, so ist heute die Gemeinde viel größer. Sie läuft immer noch in die gleiche Richtung, aber braucht eigentlich keinen Schäfer mehr, der auf sie aufpasst und sie auf dem rechten Pfad führt. Versucht der Schäfer als Heiliger der Kirche von Emacs durch den Free Software Song seine Schafe zu sammeln, so wenden sie sich nur noch beschämt ab. Der Schäfer scheint aber noch nicht gemerkt zu haben, dass seine Herde gewachsen ist und ihn nicht mehr als Schäfer braucht und sich nicht mehr von ihm zurechtweisen lassen will. Natürlich ist es wichtig, dass es den Schäfer gibt, der auch mal auf Gefahren wie die Monoschlucht hinweist, aber er muss es so machen, dass seine neuen Schafe ihn verstehen. (viele der heutigen Entwickler lebten noch nicht einmal als das GNU Projekt gegründet wurde)

Die Verdienste von RMS sind natürlich wichtig. Aber in die heutige Zeit passt seine schwarz-weiß Argumentation nicht mehr. Die Entwickler können und wollen so eine Zielsetzung nicht akzeptieren, da sie tagtäglich zum Beispiel auch mit Open Source ihr Geld verdienen. Dass RMS und somit auch die FSF nicht mehr die Entwickler vertritt, merkt man an so vielen Kleinigkeite wie dem GNU/Linux Streit, Mono oder jetzt dem Planet. Ich hoffe, dass die FSF sich langsam aber sicher in gemäßigtere Wasser begiebt, so dass sich nicht die Entwickler von ihr abwenden und das wichtige Ziel des freien Software Gedanken auf der Strecke liegen bleibt. Ich denke die FSFE ist da ein gutes Vorbild.

=-=-=-=-=
Powered by Blogilo

Posted on

Fensterdekoration hinter transparenten Fenstern

Gestern kurz vor dem harten Feature Freeze für KDE SC 4.4 hat KWin noch ein tolles neues Feature erhalten: die Fensterdekoration kann hinter transparenten Fenstern gezeichnet werden. Seht selbst:

Aktuell wird dies in Aurorae, der einzigen transparenten Deko, unterstützt, aber noch von keiner Anwendung. Da dies aber als Erweiterung des Standards vorgeschlagen ist, dürfte es in Zukunft Anwendungen geben, die dies nutzen. So hab ich mal gelesen, dass Mozilla für Firefox ein solches Feature nutzen möchte. Dies ist nun die Lösung auf der X11 Plattform.

=-=-=-=-=
Powered by Blogilo

Posted on

Window decoration behind translucent windows

Yesterday evening just before the hard freeze a nice feature was added to KWin: window decoration painted behind translucent windows. Have a look:

Currently it’s supported by Aurorae, our only translucent decoration, and I think there are no applications yet which use the feature. But as it is proposed as an addition to EWMH I’m sure there will be in future. Somewhere I read that Mozilla Firefox wants to use translucent backgrounds. So that is your solution for the X11 platform.

Well this feature illustrates that we need a blur effect 😉

=-=-=-=-=
Powered by Blogilo

Posted on

Working on KWin Shaders

This weekend I worked on some KWin OpenGL Shaders. That is I wanted to bring back the blur effect. It seems like many users want to have the effect and well with translucent window decorations a nice blur is kind of needed (yes we get compared to Windows 7 and that blur is really well done). The first results look very promising: it’s fast and doesn’t render artifacts to the screen. But I decided to not rush it into 4.4 as there are still some minor glitches around the decoration shadows which render the nice Oxygen glow useless. As well the blurring is not yet as nice as one produced by Krita. I will merge the branch as soon as trunk is open again and so we will have a blur effect in 4.5 again 🙂

But blurring is not the only OpenGL shader I started to work on this weekend: I started to implement a shader to replace the complete fixed functionality rendering of KWin. Our current rendering uses lots of OpenGL 1 commands as we also want to support older hardware. We have some OpenGL 2 shaders like the blur which replace parts of the fixed functionality.

In OpenGL 3 the fixed functionality is deprecated, in OpenGL ES 2.0 it’s even completely removed and replaced by the programmable pipeline. So getting the rendering completely into a shader is a prerequisite for using the new awesome stuff of OpenGL 3 like geometry shaders as well for porting KWin to OpenGL ES.

So why porting to OpenGL ES? Well I would like to see KWin running on Hardware like the N900 🙂 I think that KWin although developed for the desktop would be a nice window manager for small devices. We have some outstanding effects and a great decoration API as well as a nice SVG decoration engine when you don’t want to write your own decoration. And of course we see that some projects use Clutter based window managers for their small screen systems and it would be nice to provide an alternative, a window manager which is rock solid and has been used with compositing enabled by default for now almost a year – in some distributions already since KDE 4.1. And last but not least optimizing for small devices is useful for desktop systems as well.

So after spending some hours hacking the basic window rendering is implemented in a shader and if the shader is bound no deprecated OpenGL functions are used. Not only the basic rendering is supported, but some effects like present windows, desktop grid or even cover switch (as long as not using multiple screens) work as well. Other effects like cube, all shader effects or important benchmarking tools like fps are completely broken 😉 (Nevertheless my completely unprofessional benchmark called “top” looks very promising – kwin is not shown any more when idling or just doing a few repaints).

I don’t know when I will have something that could be shared as my development time is currently very limited and I only work on KWin at weekends. As well for the OpenGL ES part it could be a problem that I don’t have any hardware 😉 For OpenGL 3 it’s no problem as the drivers I use support it. I hope to have it in a state to push to trunk when it gets unfrozen.

=-=-=-=-=
Powered by Blogilo