TabBox NG

I’m currently working on the TabBox “Next Generation”. For those who do not know, what the TabBox is: it is the list view shown when using Alt+Tab and can display the windows or desktops (in static or most recently used order). It is also possible to replace the list view by a KWin effect.

This new implementation is the second part of my rework for alt+tab. The first is already implemented and available as a window runner so KRunner also lists your open windows and you can even interact with them, like closing, minimizing, etc.

In KDE 4.3 the classical TabBox already received a nice facelifting and looks integrated into the Workspace. So why working on a new implementation? Well to answer that I will present a list of the new features:

  • If the list doesn’t fit on the screen items are not cut off, but the view scrolls
  • Mouse wheel scrolls the list
  • User can choose if the items are laid out vertical, horizontal or tabular
  • Navigating with left/right/up/down keys – useful for tabular layout and for present windows
  • Model for clients and for desktops; adding new switching modes just requires to write a model and the delegate. (That could become useful when we integrate Plasma activities – more after Tokamak)
  • Static and most recently used desktop switching is just a different sort mode in the model
  • Optional Integration of highlight windows effect
  • Outline can be turned off
  • Disabling the view does not break the behaviour
  • And last but not least: Completely configurable item layout. That is the user can choose between some predefined layouts like an informative, a compact, small icons only, big icons only, text only and can define custom layouts. In combination with the view layout configuration you can build a TabBox which looks like the MacOS or the Windows XP without any problems.

So I can talk a lot but there is no better thing than a video, showing the new features:

Download ogg video

There are some things I still have to do:

  • Config interface for the item layouts
  • Layouts for desktop items
  • A second optional view for showing just the selected item – needed for icon only mode to show the text of selected item (that is the MacOS style 😉 )
  • Adding a secondary TabBox with own shortcuts and own settings, so that you can have a TabBox for e.g. only clients on current desktop and another one for clients on all desktops

I hope to get it into a state for review when Tokamak starts as I will go by train and have lots of time for working on it.

And if you never understood why your focus policy destroyed your alt+tab behaviour: have a look at this screenshot.

Von TabBox

Writing your MdB

Ich hatte mich nach der Abstimmung zu Zensursulas Sperrplänen im Bundestag an den MdB meines Wahlkreises von der schwarzen Pest gewendet, um zu erfahren warum er dem Gesetz zugestimmt hat. Ich denke ich muss hier niemandem erklären, dass das Gesetz verfassungswiedrig ist, völlig am Ziel vorbei geht und nur dafür da ist eine Zensurinfastruktur aufzubauen. Ich bin auch der Meinung, dass ein Abgeordneter die Interessen der Bürger in seinem Wahlkreis vertreten muss, dafür gibt es ja die Direktmandate. Nun hat er mit der Zustimmung zu diesem Gesetz meine Interessen nicht wirklich vertreten, da ich gegen Zensur bin. Ich denke es steht mir als potentieller Wähler kurz vor einer Wahl also zu, nachzufragen warum er dem Gesetz zugestimmt hat. Nun wollte ich einfach mal meinen Brief an den MdB und seine Antwort veröffentlichen. Ja ich weiß, dass man darüber streiten kann, ob man private Korrespondenz im Internet veröffentlichen sollte. Im Falle eines Abgeordneten denke ich ist es in Ordnung.

Sehr geehrter Herr Weiß,
wie ich der Seite abgeordnetenwatch entnehmen kann, haben Sie dem umstrittenen Gesetz zu Internet Sperren zugestimmt. Sie haben bereits in einer früheren Antwort auf dieser Seite vom 28.05. eine Stellungsnahme zu dem Thema abgegeben. Dabei haben Sie darauf hingewiesen, dass die Verbreitung von Kinderpornographie soweit es irgend geht, beschränkt werden müsse und es keinen grausamen Markt dafür geben dürfe. Diesem stimme ich natürlich zu, jedoch wird dieses Gesetz die Ziele nicht erreichen, sondern birgt eher die Gefahr, dass, falls die Liste der gesperrten Seiten verö?entlicht wird, die Pädophilen ein komplettes Bild der verfügbaren, gesperrten, jedoch nicht gelöschten Seiten erhalten. Aktuell be?ndet sich zum Beispiel die italienische Sperrliste auf der Webseite von WikiLeaks. Dies ist also keine abstrakte, sondern eine reale Gefahr.

Seit Ihrer Antwort sind über die Medien und verschiedenen Verbänden viele Fehler an dem Vorhaben aufgedeckt worden. Insbesondere haben sich uber 130.000 besorgte Bürger in einer Petition gegen dieses Gesetz ausgesprochen. Der Tenor war überwiegend, dass die Technik nicht ausreichend ist – als Informatiker kann ich dem nur zustimmen – und es besser ist zu löschen als zu sperren. Es wurde bereits von verschiedenen Verbänden gezeigt, dass der Inhalt sehr schnell von Servern entfernt werden kann – auch im Ausland. Eine Sperre ist dann nicht nötig. Das Gesetz birgt hohe Risiken, da es eine Zensurinfastruktur scha?t, welche Begehrlichkeiten in anderen Bereichen wecken kann. Aus Ihrer Partei kamen so schon Forderungen zur Ausdehnung auf sogenannte Killerspiele im Internet sowie zur Bekämpfung von Urheberrechtsverletzungen.

Ich möchte daher wissen, warum Sie trotz aller begründeter Kritik für ein Gesetz gestimmt haben, welches das BKA in die Rolle einer Zensurbehörde versetzt. Die deutsche Bevölkerung hat lange für das Grundgesetz leiden und kämpfen müssen und es stimmt mich sehr traurig, dass Grundrechte, die seit 60 Jahren gelten, von der Großen Koalition faktisch außer Kraft gesetzt wurden.

Falls Sie sich weiter zu dem Thema informieren möchten, empfehle ich Ihnen die Webseite des Arbeitskreises gegen Internet-Sperren und Zensur. Desweiteren bin ich auch gerne bereit als Bürger mit Erstwohnsitz in Ihrem Wahlkreis in Ihre Sprechstunde zu kommen, um Ihnen die Fehler an dem Gesetz – insbesondere wie leicht es ist die Sperre zu umgehen – aufzuzeigen und zu erklären. Ich würde mich freuen, wenn Sie sich in Ihrer Partei und Fraktion noch dafür einsetzen würden, dass dieses Gesetz nicht umgesetzt wird.

Der Brief ist auf den 23. Juni datiert. Tja leider habe ich bisher noch keine Antwort erhalten.

Ich bin davon wirklich enttäuscht. Es ist nicht das erste Mal, dass ich mich an einen Abgeordneten gewendet habe. Zum Beispiel hatte ich auch nach der Abstimmung zum Hackerparagraphen mich an meine Abgeordneten gewendet. Vom Abgeordneten der Grünen hatte ich eine ausführliche Antwort erhalten. Von Peter Weiß auch damals nichts.

Nun könnte man natürlich sagen, dass ein MdB viel zu tun hat und er hunderte solcher Briefe erhalten hat. Im Falle meines Heimatwahlkreises kann man das ausschließen. Es ist eine sehr ländliche Region nördlich von Freiburg. Wenig Industrie, keine Hochschulen, größte Wirtschaftszweige sind die Landwirtschaft und Tourismus. Klassische Hochburg der schwarzen Pest und der Grünen (ja klingt paradox, aber in Südbaden ist sowas möglich). Dass Peter Weiß mehr als einen Brief zu dem Thema erhalten hat, halte ich für mehr als unwahrscheinlich.

Lieber Herr Weiß, ich denke doch Ihnen ist klar, dass Sie meine mögliche Stimme verloren haben. Mit Ihrem Verhalten haben Sie meinen Entschluss die Zweitstimme den Piraten zu geben nur noch verstärkt. Bei der Erststimme habe ich ja leider in dem Wahlkreis nur die Wahl zwischen Pest oder Cholera. Dass Sie sie nicht bekommen, dürfte Ihnen wohl klar sein. Naja eigentlich war das schon immer klar, seit Sie uns, als ich in der Oberstufe war, in der Schule besuchten. Wir hatten damals den Vergleich zu Gernot Erler, der uns auch besuchte. Seitdem weiß ich was ein Hinterbänkler ist. (Und nebenbei auch immer wieder gut zu erinnern, dass es auch intelligente Politker gibt, die etwas von Ihrem Fach verstehen, wenn die Politikverdrossenheit wieder zu groß wird).

Hoffen wir einfach, dass die Piraten 3 % + x (wobei x gerne größer 2 Prozent sein kann) erreichen. Damit endlich die Interessen der nicht-Internetausdrucker ernstgenommen werden.

Ist Kubuntu eine schlechte KDE Distribution?

Disclaimer: dieser Post stellt meine persönliche Meinung dar. Es ist meine persönlich Interpretation. Einige der genannten Punkte sind persönliche Einschätzungen und Vermutungen für die ich keine Belege habe. Dieser Post steht nicht in Verbindung mit irgendeinem Projekt für das ich ehrenamtlich arbeite und für Kubuntu bin ich nur ein Anwender.

Immer wieder lese ich, dass Kubuntu eine schlechte KDE Distribution sei, Canonical zu wenig für KDE macht, GNOME in Ubuntu viel besser integriert ist, etc. etc. Ich frage mich immer wieder woher diese Meinung kommt. Vorweg: ich halte sie für Quatsch.

Zuerst einmal frage ich mich: was macht eine Distribution zu einer schlechten? Für mich wäre es wenn die Distribution viel patcht und diese nicht nach Upstream durchgibt, oder sehr viele neue Features aus dem Entwicklungszweig importiert, etc. Da ich durch ein selbstgebautes KDE den direkten Vergleich habe, kann ich einfach mal sagen: Kubuntu patcht wenig. Ich kenne Distributionen, die bedeutend mehr patchen.

Nun möchte ich ein paar mögliche Thesen aufgreifen.
1. These: Canonical macht zu wenig für KDE
Dazu zitiere ich jetzt einfach mal Mark Shuttelworth:

(12:25:17 PM) jcastro: jcastro: QUESTION: Do you think Kubuntu is a blue headed step child that every seems to think it is? If not, can you put the rumours to rest, with possibly a song or a lovely poem letting everyone know just how much you really love us over in the Kubuntu community?
(12:25:31 PM) sabdfl: oh dea
(12:25:32 PM) sabdfl: r
(12:25:53 PM) sabdfl: this question makes me rather sad, because i don’t know what else i could do
(12:26:09 PM) sabdfl: i worked out the other day that i personally spend more than $2m a year supporting Kubuntu and KDE
(12:26:20 PM) sabdfl: and yet those communities think it’s cool to act unloved
(12:26:40 PM) sabdfl: i think the Kubuntu community’s work is amazing, and they should be proud of it
(12:27:07 PM) sabdfl: there’s no need to make out like it’s against the forces of corporate indifference
(12:27:19 PM) sabdfl: when in fact I and many others bend a long way to make it possible
(12:27:25 PM) sabdfl: that’s about enough on the subject

Wir sehen hier auch ein ganz wichtiges Wort: Community. Kubuntu ist eine Community Distribution – im Gegensatz zu Ubuntu. Wenn sich jemand über den “schlechten” Zustand von Kubuntu beschwert, könnte man auch ganz provokativ zurückfragen: Und was hast du gemacht um es zu verbessern?

Aber um das ganze noch ein bißchen weiter zu verfolgen, werfen wir mal einen Blick zurück. Kubuntu existiert seit 5.04, KDE 3.5 seit November 2005. Warum erwähne ich diese zwei Zeitpunkte? Mit KDE 3.5 hat sich die Entwicklercommunity KDE 4 zugewandt. Das Projekt stand für den Anwender im Prinzip still. Das Release von KDE 4.0 erfolgte Januar 2008, die erste wirklich nutzbare Version mit 4.2 im Januar 2009. Das sind mehr als drei Jahre.

Canonical war natürlich klar, dass KDE “eine Auszeit nimmt”. Für neue Versionen reichte es im Prinzip die aktuellste KDE Version zu paketieren. Neues kam von KDE kaum dazu. Neue Technologien wurden alle in KDE 4 eingebaut, KDE 3 hatte ja Stillstand erreicht. Wie hätte Canonical Neuerungen aus Ubuntu einbauen sollen? Hätten sie wirklich als junges Unternehmen, das keinen Gewinn abwirft, Geld verbrennen sollen, indem sie in KDE 3.5 investieren? Ja ich spreche bewusst von verbrennen, da die meisten Sachen gleichzeitig für KDE 4 entwickelt wurden.

These 2: Canonical/Kubuntu gibt nichts an KDE zurück
Nun das ist eine These, die wirklich absoluter Quatsch ist. Canonical/Kubuntu hat vielleicht nicht die Manpower um viele KDE Anwendungen zu schreiben, aber es fließt ständig etwas von Kubuntu zu KDE zurück. Ich möchte mal ein paar Beispiele nennen. Kubuntus SystemSettings sind heute der Standard in KDE, Kubuntus Katapult war ein Vorläufer des heutigen KRunners, Kubuntu hat die Druckerkonfiguration nach KDE portiert und in KDE integriert, Kubuntu Entwickler geben regelmäßig Bugreports an Upstream weiter.

Ach und ich möchte einfach mal erwähnen, dass der KDE 4 Port für OpenOffice.org von Kubuntu Entwicklern durchgeführt wurde und auch in anderen Distributionen nun zur Verfügung steht.

These 3: Kubuntu integriert nicht ausgereift Bestandteile
Nun an dieser These ist was dran. Kubuntu hat Dolphin recht früh integriert oder auch das Networkmanager Plasmoid. Schauen wir mal das Beispiel Dolphin an: Dolphin ist ein einfacher Dateimanager, dessen Zielgruppe ziemlich denkungsgleich mit der Zielgruppe der Kubuntu User ist. Kubuntu hat die Devise, das beste verfügbare Werkzeug für eine Aufgabe zu verwenden. Dolphin war in dem KDE 3 Port das beste verfügbare Werkzeug für einfache Dateiarbeiten. Konqueror ist ein Poweruser Werkzeug, welches viele Anwender überfordert. KDE selbst hat die Problematik ja auch erkannt, Kubuntu hatte es schneller umgesetzt.

Schauen wir auf den Networkmanager: nun das war wirklich katastrophal. Aber wie konnte es dazu kommen? In KDE 4.2 gab es noch keinen Networkmanager, jedoch wurde an einem gearbeitet und soweit ich weiß gab es die Aussage, dass dieses bis zur Releasewelle im Frühjahr in einem brauchbaren Zustand ist. Das war es am Ende jedoch nicht. Nun hätte man umdisponieren können? Ja man hätte weiterhin den KDE 3 networkmanager verwenden können. In Verbindung mit dem neuen Networkmanager aber auch ziemlich unbrauchbar oder man hätte den GNOME networkmanager verwenden können. Das wäre sicherlich die beste Option gewesen. Aber hätte man ihn mitsamt den Abhängigkeiten auf die LiveCD bekommen? Ich weiß es nicht.

These 4: Kubuntu hat $feature_von_Ubuntu nicht
Nun hier wieder der Verweis auf das schon oben erwähnte KDE 3/4 Problem. Hätte Kubuntu wirklich alle neuen Features implementieren sollen, obwohl gleichzeit in KDE an einer Lösung gearbeitet wird? Bestes Beispiel: Desktop Effekte. Compiz wird in Ubuntu seit 7.10 standardmäßig verwendet. KDE hatte zu diesem Zeitpunkt bereits Effekte in der Entwicklerversion integriert. Hätte man wirklich den Anwendern standardmäßig Compiz geben sollen? Man bedenke: KWin gilt als Fenstermanager mit bedeutend mehr Funktionen und besserer Stabilität.

Und hier möchte ich auch erwähnen, dass sich etwas grundlegend geändert hat. Neuerungen sollen nun auch gleichzeitig in Kubuntu integriert werden. Canonical hat viel Zeit und Geld in die Benachrichtigungen investiert und diese Neuerungen sind nun auch Bestandteil von KDE. Wie kommt’s? Nun KDE ist nun mit KDE 4 wieder aktiv in der Entwicklung. Neuerungen können einfach weitergegeben werden.

These 5: Kubuntu ist langsamer als andere Distributionen
Dies ist eine These, die ich immer mal wieder höre. Wenn man dann genauer hinschaut, wird meistens Arch mit KDEmod als hochgelobtes Land gepriesen. Arch ist eine Rolling Release Distribution und kann daher vom Releasemodell nicht mit Kubuntu verglichen werden. Meistens ist es einfach der Vergleich von Äpfeln mit Birnen.

Aber es gibt meiner Meinung nach eine einfache Erklärung für die immer wiederkehrende Behauptung, dass Arch mit KDEmod so viel schneller sei: KDEmod verwendet standardmäßig das Qt Graphicssystem “Raster” anstatt “Native”. Ja das ist schneller. Aber ob es eine gute Idee ist, darauf standarmäßig zu setzen, darf jeder für sich selbst entscheiden. Raster gibt es seit Qt 4.5, welches etwa zwei Monate vor Kubuntu 9.04 veröffentlicht wurde. Hätte man wirklich standardmäßig alle Anwendungen damit betreiben sollen? Bringt es überhaupt Vorteile bei allen Anwendungen? Ist es nicht sinnvoller die Entwickler der Anwendungen entscheiden zu lassen, die viel besser einschätzen können, ob man nativ braucht oder raster überhaupt Vorteile bringt? Meine Meinung dazu steht: lieber stabil und etwas langsamer als verfrüht auf ein neues Pferd zu setzen. Wer sich daran stört, ist bei einer bleeding edge oder rolling release Distribution besser aufgehoben

These 6: Kubuntus Übersetzungen sind katastrophal
Nun dazu gibt es nicht viel zu sagen: es stimmt. Jedoch ist größtenteils die Kubuntu Community unschuldig. Das größte Problem scheint wohl in Rosetta zu liegen. Ich gebe Kubuntu noch einmal eine Chance es mit 9.10 richtig hinzubekommen. Ach und wer jetzt gleich in den Kommentaren sich auslassen will, dass die Übersetzung in den 4.3 Paketen so katastrophal ist, bedenke bitte, dass 4.3 in Jaunty nicht unterstützt ist.

Zusammenfassend denke ich, stimmen die Anschuldigungen gegenüber Kubuntu und Canonical einfach nicht. Natürlich könnte einiges besser sein, aber das ist doch überall so. Der größte Knackpunkt sind meiner Meinung nach die Übersetzungen und ich hoffe einfach, dass Canonical da aus den Fehlern lernt.

Get Hot New Stuff in Aurorae

Dank Frank Karlitschek gibt es nun eine eigene Kategorie für Aurorae Themes auf kde-look.org. Er hat auch einen Get Hot New Stuff (GHNS) Provider hinzugefügt und ich hab diesen bereits implementiert und eine neue Aurorae Version veröffentlicht. Über GHNS kann man direkt aus dem Konfigurationsdialog neue Themes herunterladen. Hier der obligatorische Screenshot:

Von Aurorae

Es gibt mittlerweile schon einige Aurorae Themes und das ist einfach großartig. An dieser Stelle möchte ich einfach allen mal danken, die ein Theme erstellt haben. Einige Themes sehen richtig umwerfend aus und passen wunderbar zu einem Plasma Theme. Genau das wollte ich mit der Engine erreichen. Ein Beispiel für diese tolle Umsetzung ist das Gaia 09 Theme. Es ist schön zu sehen, wie viele Anwender die Theme Engine herunterladen und Designs erstellen, obwohl es mit der 4.3 Abhängigkeit nicht gerade einfach war (nun dieses Problem sollte seit gestern behoben sein).

Get Hot New Stuff support in Aurorae

Thanks to Frank Karlitschek there is a category for Aurorae themes on kde-look.org. He also added a GHNS provider and of course I already implemented it and updated the Aurorae version. Here the obligatory screenshot:

Von Aurorae

There are many themes already available for Aurorae and that’s awesome. I just want to say thanks to everybody who designed a theme. Some are really great looking and working nicely together with a Plasma theme. That’s exactly what I wanted to achieve. Have a look for example at the Gaia 09 theme. It’s really great to see so many users picking up the theme engine although it was quite difficult to use as it has a 4.3 requirement (well that problem is solved since yesterday).

Google Chrome OS: ein Angriff auf FLOSS

Google hat ja bekanntlich ein neues Netbook Betriebssystem angekündigt. Ich sehe dieses als größte Gefahr für FLOSS der letzten Jahre und ich hoffe und wünsche mir, dass es kein Erfolg wird. Der einzigen anderen Firma, der ich bisher nicht Erfolg gewünscht habe ist der Riese aus Redmond. Ich habe jetzt so sehr Angst vor Chrome, dass ich selbst mit dem Teufel, in Form von MS, paktieren würde, um dieses neue Betriebssystem zu bekämpfen.

Nun woher kommt diese Abneigung gegen Chrome OS? Laut der Ankündigung ist es doch Open Source. Also alles in Ordnung, warum sollte Open Source ein Angriff auf Open Source sein?

Nun allein die Ankündigung, dass es Open Source ist, ist ja schon der erste Punkt. Von Lizenz wurde noch nichts gesagt. Warum nicht freie Software? Ich gehe hier mal vom schlimmsten aus und denke es wird eine recht unhandliche Lizenz.

So schauen wir uns doch mal ein paar Schmankerl aus der Ankündigung an:

The user interface is minimal to stay out of your way, and most of the user experience takes place on the web.

D.h. Chrome OS wird nicht mehr sein als ein Browser. Alle Anwendungen laufen im Web. Nun ist es ja toll, dass Chrome OS komplett Open Source ist. Aber die Anwendungen, die man nutzt laufen auf Servern, nicht auf dem Gerät. Kann man da noch von Open Source sprechen? Wer hat schon den Code von GMail gesehen?

Wer Chrome OS benutzt, wird nicht nur seine Daten an Google geben, sondern auch die Berechnungen auslagern. Das Gerät wird ohne Internetzugang so gut wie unbenutzbar sein. Google ist schon eine Datenkrake, aber man muss sich bewusst machen, welche Daten sie mit Chrome OS in der Hand haben. Sie werden alles wissen. Sie werden wissen wie genau der Workflow aussieht, sie werden einen kontrollieren. 1984 – here we come. Ich hätte nie gedacht, dass der Angriff auf die Privatspähre in dieser Form nicht vom Staat ausgeht. Ganz klar: Stasi 2.0 ist Kindergarten dagegen.

Nun denn, der Leser mag sich denken: hey ich benutze doch die Webanwendungen gar nicht. Ich installiere einfach meine übliche Software und gut ist. Ist ja Linux – Chrome OS ist nichts mehr als eine weitere Distri. Tja leider nicht:

The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel.

Das entscheidende ist hierbei “a new windowing system” – es wird nicht X11 eingesetzt. Ach ja nicht weiter schlimm, X11 ist alt und verursacht viele Probleme. Ich plage mich tagtäglich damit rum. Aber es bedeutet viel mehr. All unsere freien Anwendungen verwenden X11. Keine GNOME/KDE/$DE Anwendung wird auf Chrome OS lauffähig sein. GTK+ und Qt müssten zuerst portiert werden. Window Manager wie KWin/Compiz/Mutter sind eng an die X11 Plattform angepasst und sind kaum portable. Diese sind nicht geschrieben worden mit dem Gedanken an andere Plattformen. Das heißt eine andere Benutzeroberfläche wäre nicht startbar, selbst wenn es jemand schaffen würde die Toolkits zu portieren.

Nun kommen wir dabei gleich zum nächsten Problem. Google spricht von einer simplen Architektur und nennt das Betriebssystem “lightweight”. Für mich bedeutet das, dass das windowing system so designt ist, dass es nur eine Anwendung ausführen kann: Chrome. Und wenn wir uns das Design vom Webbrowser Chrome anschauen, so stellen wir fest: hey das ist ja schon ein windowing system. Es hat eine Architektur, die pro Tab einen eigenen Prozess hat. Möchte man dies gut unter X11 erstellen, läuft es darauf hinaus, dass es ein eigenes Windowing System wird – vermute ich zumindest. Chrome scheint für mich bereits das komplette Windowing system zu integrieren.

Es gibt noch etwas was mir Angst macht: die Tatsache, dass die Ankündigung für Chrome OS während GCDS erfolgte. Google war Sponsor, wusste also, dass der Summit stattfindet. Für mich ist es kein Zufall. Für mich ist es ein Zeichen Googles, dass sie KDE und GNOME als überflüssig ansehen: “Lasst die mal diskutieren – hier das ist die Zukunft”. Ein sehr beängstigendes Zeichen.

Fassen wir zusammen: Chrome OS wird es unmöglich machen für existierende freie Software auf der Plattform zu laufen. Zusätzlich wird die komplette Berechnung auf die Server in Mountain View verlagert. Der Quellcode der Präsentationsschicht wird zwar freigegeben – ist aber recht wertlos. Es ist nur die Präsentationsschicht.

Ach und da ist noch ein anderes Problemchen: hat Chrome OS Erfolg, nimmt es unseren Marktanteil weg. Windows und Mac OS werden davon nicht wirklich beeinträchtigt werden. Für uns ist es aber eine Gefahr.

Hat Chrome OS keinen Erfolg, so steht FLOSS ziemlich schlecht da. Wir werden verspottet werden und es wird heißen, dass man mit freier Software und Linux doch keinen Erfolg haben kann. Dass das Produkt, was Google ausliefert, nichts mit dem existierenden FLOSS Stack zu tun hat, ist dann irrelevant. Egal wie, wir sind die Verlierer.

Chrome ist für mich eine riesige Gefahr und wir müssen gemeinsam den Leuten klar machen, was es bedeutet, wenn dieses “Betriebssystem” Erfolg hat. Niemand sollte es benutzen. Die Leute, die sich nicht so gut auskennen, werden den Angriff auf FLOSS nicht verstehen, wir müssen sie mit den Gefahren für sie aufklären. Chrome OS bedeutet die Verlagerung sämtlicher Daten und sämtlicher Berechnungen auf die Server von Google. Man hat keine Privatsphäre mehr. Google weiß alles. Sie wissen wie lange man auf youporn war, wie oft und was man zuvor und danach gemacht hat. Leute macht euch klar: mit Chrome gibt es keine Privatsphäre mehr. Das Verfassungsgericht hat uns letztes Jahr ein tolles neues Grundrecht gegeben. Seid stolz in einem Land zu leben, in dem die Vertraulichkeit informationstechnischer Systeme und die informationelle Selbstbestimmung grundrechtlich geschütz ist. Zerstört es nicht, indem ihr alles an Google gibt. Geben wir freiwillig unseren Schutz auf, schützt uns auch das Verfassungsgericht nicht mehr, wenn die Politik wieder begehrlich ist.

Gran Canaria Desktop Summit – persönliche Zusammenfassung

Die letzte Woche war ich auf dem Gran Canaria Desktop Summit, der erstmalig gemeinsamen Konferenz von GNOME und KDE. Ich muss sagen es hat sich gelohnt und hoffe, dass in Zukunft öfter aKademy und Guadec zusammen stattfinden werden.

Ich war am Freitag in Las Palmas angekommen. Das Wetter war bei weitem nicht so schlimm, wie ich befürchtet hatte – es war richtig angenehm. Der starke Seewind und die Bewölkung machten die Hitze durchaus erträglich. Trotzdem: die Sonne ist gefährlich – das sagt mir zumindest mein Rücken 😉

Am Freitag Abend war das erste Social Event gesponsort von Canonical. Es war somit die erste Möglichkeit die GNOME Leute kennen zu lernen. Wenn man sich so umgeschaut hat, sah man aber, dass die KDE Leute mit den KDE Leuten sprachen, die GNOME Leute mit den GNOME Leuten. War ja irgendwie zu erwarten – man kennt sich halt 😉 Dennoch gab es wohl auch einige Gespräche über die Grenzen hinweg und ich hab ein ausführliches Gespräch mit einem GNOME Shell Entwickler gehabt und Ideen ausgetauscht.

Am Samstag morgen begann die Konferenz – trotz Party am Vorabend gut besucht. Das Konfernzgebäude war einfach gigantisch. Die Mitarbeiter wurden aber wohl nicht richtig darauf vorbereitet, dass eine freie Software Konfernz nicht wie eine normale Konfernz ist. Bei Lightning Talks jeweils neues Wasser und ein Namensschild zum Rednerpult zu bringen ist irgendwie overkill 😉

Die Konferenz wurde von einigen Vertretern von Gran Canaria/Spanien eröffnet. Leider hab ich keine Ahnung was sie uns sagen wollten, da sie auf Spanisch gesprochen hatten. Am Besten war ein Redner der anfing mit “mein Englisch ist nicht wirklich gut, daher halte ich meine Rede auf Spanisch”. Bei schlechtem Englisch hätte ich ja was verstanden, bei Spanisch leider nicht.

Nach der Eröffnung folgten die drei Keynotes. Ich war ja besonders an der Stallman Keynote interessiert. Da er ja zuvor schon auf Mono rumgehackt hatte, hatte ich erwartet, dass er auf die Problematik eingeht. Und ich wurde in dem Punkt nicht enttäuscht: seine ganze Rede ging eingentlich um die Mono Problematik. Die Rede war sehr gut aufgebaut: er begann mit einem Rückblick auf die Qt Problematik und wie es zu GNOME führte. Dass damals die freie Software bedroht war, weil der einzige freie Desktop auf eine unfreie Komponente aufbaute. Er erwähnte auch, dass dieses Problem heute gelöst ist. Mit diesem Rückblick motivierte er die Mono Diskussion: da Microsoft Patente auf C# hat, stellt das Entwickeln in dieser Sprache seiner Meinung nach eine Gefahr dar. Es sei schwer zu sagen an welchem Punkt es gefährlich wird, einzelne Anwendungen sind ok, aber komplett darauf aufzubauen nicht. So könnte man sagen, dass Tomboy ok ist, weil man es problemlos durch Gnote ersetzen kann. Also falls MS jemals auf die Idee kommt die Patente einzusetzen, wäre nichts verloren. Wie sich am Anschluss seiner Diskussion zeigt, kennt er sich jedoch mit der Problematik nicht wirklich aus. Er weiß nicht welche Teile patentiert sind, er weiß nicht in wie weit MS versprochen hat, keine Patente einzusetzen und seine Argumentation dreht sich um den Punkt “MS ist böse, MS hat gesagt sie wollen freie Software zerstören, also dürfen wir keine MS Technologie verwenden”. Auch wenn ich persönlich die gleiche Argumentation für mich folge und daher C# nicht verwenden würde, klingt seine Argumentation in meinen Ohren als FUD. Besonders die Empfehlung Lisp anstatt C# als Sprache zu verwenden, ist nun ja irgendwie weltfremd.

Ich persönlich habe vor der Rede ja auch eine Meinung zu Stallman gehabt und die ist nicht wirklich positiv. Er hat tolles für freie Software geleistet, aber irgendwie glaube ich nicht, dass er heute noch die richtige Person dafür ist. Und leider wurde meine in diesen Punkten ablehnende Haltung bestätigt. Nach seinem Mono Bashing verwandelte er sich in “St. IGNUcius of the Church of Emacs”. Eine meiner Meinung nach sehr peinliche Vorstellung und ich habe mit niemandem gesprochen der dieses gut geheißen hat. Es gab zwar viel Gelächter und Applaus aber irgendwie glaube ich mitlerweile die Leute haben ihn eher ausgelacht als das gutgeheißen. Für mich war dieser Teil der Rede ein “nein ich will nichts mit soetwas zu tun haben”. Da sage ich dann doch lieber ich bin ein Open Source Programmierer und kein Freie Software Programmierer. Ich kann mir nicht vorstellen, dass Microsoft ihn Ernst nimmt, wenn er als “Heiliger” mit Heiligenschein auftritt. Für eine Keynote bei solch einem Ereignis eine sehr schwache Nummer und ich war nicht der einzige, der sich daran störte.

Nach den Keynotes folgten die ersten Talks – zuerst einige Lightning Talks mit zum Teil grandiosen Projekten. Am nächsten Tag begannen die eigentlichen Vorträge, jeweils vier gleichzeitig – ich muss noch einige Videos anschauen. Es wird an doch bedeutend mehr Stellen zusammengearbeitet als ich dachte.

Nachmittags begann dann die eigentliche aKademy mit einer sehr guten Keynote von Glyn Moody. Ein schöner Rückblick wie Freie Software die Welt bereits veränderte. Die folgenden anderthalb Tage war ich also damit beschäftigt mir Talks anzuhören 😉

Am Dienstag war mein freier Tag, da ich nicht im e.V. und somit nicht zur Hauptversammlung gehen konnte. Die Zeit ein bißchen am Strand verbracht und ein bißchen für 4.4 gehackt.

Mittwoch wurde die Konferenz in die außerhalb Las Palmas gelegene Universität verlegt. Obwohl sie erst 20 Jahre alt ist ohne Klimaanlage – recht überraschend. Zumindest war hier das Internet – im Gegensatz zum Konferenzgebäude – top. An jedem Platz Ethernetkabel und Steckdose. Perfekt für Akademy. Die erste BOF session betraf die Umstellung auf git. Der Raum war komplett voll und überhaupt nicht wie ein BOF sein sollte. Es gibt einiges zu tun und es haben sich einige Freiwillige gefunden. Grober Zeitplan bis zum 4.4 Freeze – also wohl noch dieses Jahr 🙂

Am Donnerstag war das wichtige Plasma/KWin Treffen und es wird einiges tolles kommen – ich verrate jetzt mal noch nichts. Wir haben tolle und ehrgeizige Ideen, die wir aber erst noch weiter ausarbeiten müssen.

Am Mittag war der Tourist Trip. Tja Tourist Trip auf Gran Canaria bedeutet wohl nur, man geht an den Strand. Dass wir dazu mit dem Bus zum Süden der Insel fahren mussten, verstehe ich nicht wirklich – schönen Strand gab es auch in Las Palmas. Am Abend ging es für mich dann zum Flughafen, da ich einen Nachtflug hatte (wie konnte ich nur so blöd sein – ich weiß doch dass ich im Flugzeug nicht schlafen kann).

Insgesamt war es eine richtig tolle Woche und ich freue mich schon auf die aKademy nächstes Jahr. Die Community ist einfach richtig toll und es macht super Spaß in ihr zu arbeiten. Auch mit den GNOME Leuten war es eine sehr angenehme Erfahrung – aber man sieht doch Unterschiede. Mir kam es eigentlich die ganze Woche so vor, als ob mehr KDE Leute anwesend waren. Vermutlich ein rein subjektives Wahrnemen, da wir alle beim Social Event das Kubuntu T-Shirt angezogen haben und bei den Vorträgen unsere Laptops benutzten und man daher überall nur KDE sah.

How to write a KWin effect

This blog post has been in my drafts folder for weeks and I just thought it’s time to publish it – ready for Akademy 🙂 And if somebody is really interested we could have a BOF session at Akademy. I think Plasma devs want us to write a slide effect to replace their custom popup animation. That would be a perfect example to get your hands dirty.

I wrote a new Kwin effect and thought this is the ideal effect for writing a small howto. It is an effect which helps resizing windows by colouring the changed geometry. I was told that resizing is not optimal in KWin, that is if the window content is shown while resizing it is slow and if the window content is not shown it is ugly. This effect should fill the gap. Unfortunately the current code will only work with the slow show window content while resizing (the API has to be changed). Nevertheless I decided to show the code in this tutorial.

Von KWin

The effect has been committed to trunk. So you can have a look at it and if you’re running trunk you can even try it. The effect which we will write has the name “Resize”. It will support both backends: XRender and OpenGL. Each effect has an own directory in kwin/effects so we create a new directory resize. There we create the following files:

  • CMakeLists.txt
  • resize.h
  • resize.cpp
  • resize.desktop

We have to include this directory into the build, so we edit the CMakeLists.txt in the effects directory. We just add the following line to the section marked as “Common effects”:

include( resize/CMakeLists.txt )

If it were an OpenGL only effect we would place this line in the section marked as “OpenGL-specific effects”.

So at this point we are finished with the preparation. So let’s start looking at the files. First the desktop file:

[Desktop Entry]
Name=Resize Window
Icon=preferences-system-windows-effect-resize
Comment=Effect to outline geometry while resizing a window

Type=Service
X-KDE-ServiceTypes=KWin/Effect
X-KDE-PluginInfo-Author=Martin Gräßlin
X-KDE-PluginInfo-Email=kde@martin-graesslin.com
X-KDE-PluginInfo-Name=kwin4_effect_resize
X-KDE-PluginInfo-Version=0.1.0
X-KDE-PluginInfo-Category=Window Management
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=false
X-KDE-Library=kwin4_effect_builtins
X-KDE-Ordering=60

Most of it is self explaining and just needed for the “All effects” tab in the compositing kcm. The most important value is the “X-KDE-PluginInfo-Name”. This is the name used to load the effect and has to start with “kwin4_effect_” followed by your custom effect name. This last part will be needed in the source code.

Each effect is a subclass of class Effect defined in kwineffects.h and implements some of the virtual methods provided by Effect. There are methods for almost everything the window manager does. So by implementing those methods you can react on change of desktop or on opened/closed windows. In this effect we are interested in resize events so we have to implement method “windowUserMovedResized( EffectWindow *w, bool first, bool last )”. This method is called whenever a user moves or resizes the given window. The two boolean values indicate if it is the first, last or an intermediate resize event.

But there are more methods we have to implement. The effect should paint the changed geometry while resizing. So we have to implement the methods required for custom painting. KWin’s painting pass consists of three stages:

  1. pre paint
  2. paint
  3. post paint

These stages are executed once for the complete screen and once for every window. All effects are chained and each effect calls the stage for the next effect. How this works we will see when looking at the implementation. You can find a good documentation in the comments of scene.cpp

Now it’s time to have a look at the header file:

#ifndef KWIN_RESIZE_H
#define KWIN_RESIZE_H

#include <kwineffects.h>

namespace KWin
{

class ResizeEffect
    : public Effect
    {
    public:
        ResizeEffect();
        ~ResizeEffect();
        virtual void prePaintScreen( ScreenPrePaintData& data, int time );
        virtual void paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData& data );
        virtual void windowUserMovedResized( EffectWindow *w, bool first, bool last );

    private:
        bool m_active;
        EffectWindow* m_resizeWindow;
        QRegion m_originalWindowRect;
    };

}

#endif

We see that there are three member variables. The boolean is used to indicate if there is a window being resized, that is if we have to do some painting. The EffectWindow is a pointer on the window being resized and the QRegion stores the windows’s geometry before the start of resizing.

So now we can have a look at the implementation. I will split the code in small parts and explain the code. So first let’s look at the includes:

#include "resize.h"

#ifdef KWIN_HAVE_OPENGL_COMPOSITING
#include <GL/gl.h>
#endif                                               
#ifdef KWIN_HAVE_XRENDER_COMPOSITING                 
#include <X11/Xlib.h>
#include <X11/extensions/Xrender.h>
#endif                                                                

#include <KColorScheme>

As our effect should support both XRender and OpenGL we have to include the headers for both. As it is possible that the effect is compiled on a system which does not support one of both we use ifdef. We can be sure that at least one of both is available or the effects wouldn’t be compiled at all. If you write an OpenGL only effect you do not have to bother about such things. Also if you only use KWin’s high level API you don’t need to include those headers. But we want to paint on the screen using OpenGL or XRender directly.

So let’s have a look at the next part:

namespace KWin
{                    

KWIN_EFFECT( resize, ResizeEffect )                                                                                                                                                            

ResizeEffect::ResizeEffect()
    : m_active( false )                                                                                                                                    
    , m_resizeWindow( 0 )                                                                                                                                         
    {                                                                                                                           
    reconfigure( ReconfigureAll );                             
    }                                                                                                                           

ResizeEffect::~ResizeEffect()
    {                                                                                         
    }

Here we see the use of a macro. This has to be included or your effect will not load (it took me ten minutes to notice I forgot to add this line). The first value is the second part of X-KDE-PluginInfo-Name – I told you we will need it again. The second value is the class name. Following is constructor and deconstructor.

So let’s look at the pre paint screen stage:

void ResizeEffect::prePaintScreen( ScreenPrePaintData& data, int time )
    {                                                                                                                           
    if( m_active )                                             
        {                                                                                                                       
        data.mask |= PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS;           
        }                                                                                                                       
    effects->prePaintScreen( data, time );                                                                                                                     
    }

Here we extend the mask to say that we paint the screen with transformed windows when the effect is active. That’s not completely true – we don’t transform a window. But this flag indicates that the complete screen will be repainted, so we eliminate the risk of artefacts. We could also track the parts which have to be repainted manually but this would probably be more work for the CPU than the complete repaint for the GPU. At this point we see the chaining for the first time. The effects->prePaintScreen( data, time ); will call the next effect in the chain. effects is a pointer on the EffectsHandler and a very useful helper.

So now we start looking at the heart of the effect:

void ResizeEffect::paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData& data )              
    {                                                                                                                           
    effects->paintWindow( w, mask, region, data );                                                   
    if( m_active && w == m_resizeWindow )                                                                                                                 
        {                                                                                                                       
        QRegion intersection = m_originalWindowRect.intersected( w->geometry() );                                                                                                                
        QRegion paintRegion = m_originalWindowRect.united( w->geometry() ).subtracted( intersection );                                                                                                                                                          
        float alpha = 0.8f;                                                                                                                                              
        QColor color = KColorScheme( QPalette::Normal, KColorScheme::Selection ).background().color();

We first continue the paint window effect chain – this will paint the window on the screen. Now we check if we are in resizing mode (m_active) and if the currently painted window is the window which is repainted. In that case we calculate the region which has to be painted. We just subtract the intersection of current geometry with saved geometry from the union of those two. The next two lines are for the color definition. We use the background color of a selection with 80 % opacity.

Now we have to do a little bit OpenGL. In most effects where you just transform windows you don’t have to write OpenGL at all. There is a nice high level API which allows you to translate, scale and rotate windows or the complete screen. Also transforming single quads can be completely done without knowing anything about OpenGL.

#ifdef KWIN_HAVE_OPENGL_COMPOSITING
        if( effects->compositingType() == OpenGLCompositing)                                  
            {                                                                                                                   
            glPushAttrib( GL_CURRENT_BIT | GL_ENABLE_BIT );                                                                                                                                    
            glEnable( GL_BLEND );                              
            glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA );                                                                                                                               
            glColor4f( color.red() / 255.0f, color.green() / 255.0f, color.blue() / 255.0f, alpha );                                                                                                                      
            glBegin( GL_QUADS );                               
            foreach( const QRect &r, paintRegion.rects() )                                                                                                  
                {                                                                                                               
                glVertex2i( r.x(), r.y() );                                                                                                                                                  
                glVertex2i( r.x() + r.width(), r.y() );           
                glVertex2i( r.x() + r.width(), r.y() + r.height() );                                
                glVertex2i( r.x(), r.y() + r.height() );          
                }                                                                                                               
            glEnd();                                                                        
            glPopAttrib();                                                                  
            }                                                                                                                   
#endif

We check if KWin uses OpenGL as a backend. We enable blending in the OpenGL state machine (needed to have translucent colors) and set the color for our rects. OpenGL clamps colors in the range [0,1] that’s why we can’t use the values from QColor directly. Last but not least we just paint one quads for each rect of our regin.

Now just the XRender part is missing. This part is taken from show paint effect – I don’t know anything about XRender 😉

#ifdef KWIN_HAVE_XRENDER_COMPOSITING
        if( effects->compositingType() == XRenderCompositing)                                 
            {                                                                                                                   
            XRenderColor col;                                                                      
            col.alpha = int( alpha * 0xffff );                                                                 
            col.red = int( alpha * 0xffff * color.red() / 255 );                       
            col.green = int( alpha * 0xffff * color.green() / 255 );                   
            col.blue= int( alpha * 0xffff * color.blue() / 255 );                      
            foreach( const QRect &r, paintRegion.rects() )                                                                                                  
                XRenderFillRectangle( display(), PictOpOver, effects->xrenderBufferPicture(),                                                                                                                          
                    &col, r.x(), r.y(), r.width(), r.height());
            }
#endif
        }
    }

This does the same as the OpenGL part just with XRender.

Last but not least we have to track the window resizing:

void ResizeEffect::windowUserMovedResized( EffectWindow* w, bool first, bool last )
    {
    if( first && last )
        {
        // not interested in maximized
        return;
        }
    if( first && w->isUserResize() && !w->isUserMove() )
        {
        m_active = true;
        m_resizeWindow = w;
        m_originalWindowRect = w->geometry();
        w->addRepaintFull();
        }
    if( m_active && w == m_resizeWindow && last )
        {
        m_active = false;
        m_resizeWindow = NULL;
        effects->addRepaintFull();
        }
    }

} // namespace

So and that’s all. When a resize event is started we activate the effect and trigger a repaint of the window (probably not needed, but doesn’t hurt). And when the resizing is finished we deactivate the effect and trigger another repaint of the complete screen just to make sure that there are no artefacts left.

The CMakeLists.txt could just be taken from any other effect and be adjusted. So here’s the example:

#######################################
# Effect

# Source files
set( kwin4_effect_builtins_sources ${kwin4_effect_builtins_sources}
    resize/resize.cpp
    )

# .desktop files
install( FILES
    resize/resize.desktop
    DESTINATION ${SERVICES_INSTALL_DIR}/kwin )

#######################################
# Config

Now you can compile and try your new effect.

Eine neue KWin Fensterdekoration Theme Engine

Dies ist eine Übersetzung des Englischen Posts A new KWin window decoration theme engine

Ich habe mit der Arbeit an einer neuen Theme Engine für Fensterdekorationen begonnen. Das Ziel ist Themes für Dekos so einfach zu machen wie Themes für Plasma. Also nutzt es Plasma Technologien, insbesondere FrameSvg 😉 Hier ist ein Screenshot des aktuellen Stand:

Von KWin

Der Hintergrund der Dekoration basiert auf Air’s transparenten Hintergrund und die Icons… nun man sieht, dass ich kein Künstler bin (und serenity auch nicht, der den Schließen Knopf erstellt hat). Es gibt bisher auch nur einen Minimieren und einen Schließen Knopf. Wie man sieht wird KWin’s neue ARGB Dekoratioen benutzt und das Theme zeichnet eigene Schatten. Die Engine unterstützt jedoch noch nicht wirklich undurchsichtige Dekorationen und das ist einer der noch ausstehenden Todos. Aber es wurde auch entwickelt mit Gedanken an ARGB Dekos 🙂

Aktuell fehlen noch zwei Dinge: ein Name und Beispielthemes. Wenn jemand Ideen für Namen hat, bitte einfach einen Kommentar hinterlassen. Und wer Interesse hat ein Theme zu erstellen, soll mich doch bitte einfach kontaktieren.

Ach ich habe noch keinen Code ins SVN eingespielt, aber die Engine wird bald in playground zu finden sein. Es gibt da noch ein paar Blocker (zum Beispiel der fehlende Name), welche zuerst behoben werden müssen, bevor ich den Code teile.

A new KWin window decoration theme engine

I started to work on a new theme engine for window decoration. The goal is to make deco themes as easy as Plasma themes. So it’s using Plasma technologies, that is FrameSvg 😉 Well here is a screenshot of current state:

Von KWin

The decoration background is based on Air’s translucent background and the icons… well you see I’m not an artist. And there is only a minimize and a close button. As you can see it uses KWin’s new ARGB decoration and the theme paints it’s own shadows. The engine does not yet really support opaque decorations that’s one of the left todos. But it’s thought with ARGB decos in mind 🙂

Currently two things are still missing: a name and example themes. So if you have ideas for names please leave a comment and if you are interested in creating a theme, please contact me.

Ah I have not yet committed any code into SVN, but you will soon find the engine in playground. There are some blockers (like the name) which have to be fixed before I want to share the code.