BlueTile { ein moderner Tiling Window Manager mit flacher Lernkurve Individuelles Projekt Abstract: Tiling Window Manager (TWMs) ordnen Fenster so an, dass sie sich nicht uberlappen¨ und die gesamte Bildschirmfl¨ache genutzt wird. Unter bestehenden TWMs sind jedoch zwei Einstiegshurden¨ ver- breitet: Die Notwendigkeit, viel Konfiguration vorzunehmen, und die ausschließliche Bedienung durch Tastaturkurzel.¨ Diese Arbeit beschreibt das Design und die Implementierung von BlueTile, einem Windowmana- ger, der versucht, das TWM-Paradigma leichter erschließbar zu machen, indem auf Konventionen aus klassischen, meist Maus-basierten Window- managern zuruckgegriffen¨ wird und der ohne Konfiguration verwendbar ist. Betreuerin: Dr. Elke Wilkeit Zweitgutachter: Martin Hilscher Vorgelegt von: Jan Vornberger Campus-Appartments 1-306 Artillerieweg 27 26129 Oldenburg [email protected] Inhaltsverzeichnis 1 Motivation hinter BlueTile 3 2 Ubersicht¨ von Tiling Window Managern 4 3 Zielgruppe 7 4 XMonad { Basis fur¨ BlueTile 8 5 Entwicklungsumgebung 11 6 Konfiguration 13 7 Erstes Starten 14 8 Hilfesystem 14 9 Funktionalit¨aten 16 9.1 SWM-Modus . 17 9.2 Fensterdekoration . 22 9.3 Fenster verschieben . 23 9.4 Fenstergr¨oße ¨andern . 25 9.5 Minimieren . 26 9.6 Maximieren . 30 9.7 Dock-Applikation . 32 10 Installation von BlueTile 35 11 Fazit 36 2 1 Motivation hinter BlueTile In diesem einleitenden Abschnitt m¨ochte ich kurz den Begriff des Tiling Window Managers (TWM) umreißen und ausfuhren,¨ welche Motivation hinter der Erstellung von BlueTile steht und welche Ziele im Einzelnen von mir angestrebt wurden. Klassische Windowmanager (als Stacking Window Manager bezeichnet) gehen recht unbedarft bei der Positionierung von Fenstern vor, was das geschickte Aus- nutzen von vorhandener Bildschirmfl¨ache angeht. Fenster uberlappen¨ sich und die Benutzerin ist viel damit besch¨aftigt, Applikationen von Interesse in den Vorder- grund zu holen und neu anzuordnen. Tiling Window Manager verfolgen stattdessen den Ansatz, dass sich Fenster in der Regel nicht uberlappen¨ und die gesamte Bildschirmfl¨ache unter ihnen aufgeteilt wird. Verschiedene Ans¨atze wurden entwickelt, wie diese Aufteilung erfolgen kann und die Benutzerin kann sie jeweils den Gegebenheiten anpassen. Wie im Abschnitt 2 noch ausgefuhrt¨ wird, existiert eine Vielzahl von TWMs, welche auf teilweise ganz verschiedene Arten und Weisen an die Umsetzung des Tiling Window Paradigmas herangehen. Es herrscht somit kein Mangel an TWMs. Warum also die Entscheidung, einen weiteren TWM zu schreiben? Was meiner Beobachtung nach viele TWMs gemein haben, sind zwei große Ein- stiegshurden:¨ Zum Einen sind sie in der Regel bewusst minimal gehalten. Es wird oft mehr eine Art Baukastensystem angeboten und man geht davon aus, dass die Benutzerin sich eine gewunschte¨ Konfiguration selbst zusammenstellt. XMonad ist dafur¨ ein Extrembeispiel (siehe auch Abschnitt 4) { beim Starten mit der Standard- konfiguration bekommt die Benutzerin nichts als einen leeren Bildschirm zu sehen. Die zweite Einstiegshurde¨ besteht darin, dass die meisten TWMs darauf ausgelegt sind, mit einer Vielzahl an Tastenkurzeln¨ bedient zu werden. Da sich das Tiling Win- dow Paradigma im Vergleich zum Stacking Window Paradigma wesentlich besser fur¨ ein Tastatur-basiertes Arbeiten eignet, stellt dies naturlich¨ auch einen wesentlichen Vorteil von TWMs dar. Es fuhrt¨ aber auch dazu, dass die Bedienung erst m¨oglich wird, nachdem eine erhebliche Einarbeitungszeit geleistet worden ist. Insbesondere fur¨ eine Benutzerin, die nur einmal in die Welt von TWMs hinein- schauen m¨ochte, ergibt sich somit ein erheblicher Zeitaufwand. Zum Einen muss sie eine Konfiguration zusammenstellen { zus¨atzlich erschwert dadurch, dass sie schließ- lich zu diesem Zeitpunkt noch gar nicht weiß, worauf es bei einer Konfiguration fur¨ TWMs ankommt { und zum Anderen so viele Tastenkurzel¨ gut genug lernen, um absch¨atzen zu k¨onnen, ob TWMs fur¨ ihren Arbeitsstil nutzlich¨ sein k¨onnen. Diese Einstiegshurde¨ m¨ochte BlueTile abbauen und daraus ergeben sich die fol- genden drei Ziele: • BlueTile m¨ochte ohne Konfiguration { 'out of the box' { verwendbar sein. 3 Die Standardkonfiguration von BlueTile soll derart gestaltet sein, dass sie fur¨ die meisten Situationen v¨ollig ausreichend ist und { zumindest zu Beginn { in der Regel keine Anpassung erfordert. Der Abschnitt 6 fuhrt¨ weitere Gedanken zu diesem Punkt aus. • BlueTile soll mit wenig Aufwand zu bedienen sein. Dies bedeutet, Funktionalit¨at auf leicht erschließbare Art und Weise verfugbar¨ zu machen und Konventionen, die die Benutzerin aus klassischen, meist Maus- basierten, Windowmanagern gew¨ohnt ist, auf das TWM-Paradigma anzupas- sen. Die Designentscheidungen, die aus dieser Grundlage resultieren, wirken sich auf alle Funktionen von BlueTile aus (siehe Abschnitt 9). • BlueTile bietet Tastenkurzel¨ fur¨ s¨amtliche Funktionalit¨at. Da { wie bereits erw¨ahnt { Tastenkurzel¨ ein wichtiger Bestandteil vieler TWMs sind, m¨ochte BlueTile diese Tradition weiterfuhren¨ und dafur¨ sorgen, dass fur¨ fortgeschrittene Benutzer und Benutzerinnen s¨amtliche Funktionalit¨at weiter- hin auch durch Tastenkurzel¨ aufrufbar ist. 2 Ubersicht¨ von Tiling Window Managern Abbildung 1: TwoUp Tiling Window Manager sind haupts¨achlich in freien Betriebsystemen wie z.B. Linux vertreten. Microsoft Windows und Mac OS bieten keine einfache M¨oglichkeit, die Komponente, die die Verwaltung von Fenstern ausfuhrt,¨ durch Alternativen zu 4 ersetzen. Dementsprechend kann Software, die solche Funktionalit¨at unter diesen Betriebsystemen bereitstellen m¨ochte, nur eine aufgesetzte Umsetzung bieten. Diese beschr¨ankt sich meistens darauf, Fenster nur auf Anfrage der Benutzerin gekachelt anzuordnen, dann diese Anordnung jedoch nicht weiter aufrecht zu erhalten. Das Offnen¨ neuer Fenster oder das Verschieben und Andern¨ der Gr¨oße von Fenstern fuhrt¨ dann wieder zu Uberlappung,¨ bis die Benutzerin erneut Kommandos zum Kacheln der Fenster ausfuhrt.¨ Beispiele fur¨ solche Software sind WinSplit Revolution1 fur¨ Microsoft Windows und TwoUp2 fur¨ Mac OS (siehe Abbildung 1). Unter Linux hingegen ist es kein Problem, verschiedene Windowmanager zu nut- zen und eine komplette Integration zu erzielen. Daher ist es keine Uberraschung,¨ dass fur¨ Linux und andere freie Betriebsysteme die Auswahl an TWMs besonders umfangreich ist. Es lag daher nahe, sich bei der Entwicklung eines neuen TWMs auf Linux zu konzentrieren und auf einer bestehenden Software aus diesem Bereich aufzubauen. Tiling Window Manager unter Linux lassen sich grob in zwei Kategorien unter- teilen: Statische und dynamische TWMs. Die statischen TWMs arbeiten nach dem Konzept, dass die Benutzerin eine Aufteilung des Bildschirms in verschiedene Teil- bereiche manuell vornimmt und diese unabh¨angig von tats¨achlich offenen Fenstern bestehen bleiben. Ein neues Fenster wird dann einem der bestehenden Teilberei- che zugeordnet und nimmt die entsprechende Gr¨oße an. In TWMs dieser Art wird also nicht zwangsl¨aufig die gesamte Bildschirmfl¨ache genutzt, da Teilbereiche auch unbelegt bleiben k¨onnen (siehe Abbildung 2). Vertreter dieser Kategorie sind bei- spielsweise Ion3, Ratpoison4 und StumpWM5. Demgegenuber¨ passen dynamische TWMs das Layout der aktuellen Anzahl of- fener Fenster an. Ein manuelles Einteilen der Bildschirmfl¨ache ist nicht n¨otig, das Offnen¨ eines neuen Fensters fuhrt¨ automatisch zu einer Neuanordnung aller Fenster. Wie diese Anordnung erfolgt, entscheidet der aktuell aktive Layout-Algorithmus. Die Benutzerin kann jedoch die automatisch erzeugte Anordnung nachtr¨aglich an- passen oder komplett zu einem anderen Layout-Algorithmus wechseln. Wenn der Windowmanager virtuelle Desktops unterstutzt¨ { wie es unter Linux die Regel ist { kann der Layout-Algorithmus in vielen F¨allen fur¨ jeden virtuellen Desktop separat festgelegt werden. Um die automatische Anordnung von Fenstern zu erleichtern, gibt es in vielen dynamischen TWMs das Konzept des Master-Fensters. Dieses Fenster gilt als das Hauptfenster und der aktive Layout-Algorithmus w¨ahlt die Anordnung so, dass dieses Fenster die meiste Fl¨ache zugewiesen bekommt (siehe Abbildung 3). 1http://www.winsplit-revolution.com/ (16. August 2009) 2http://www.irradiatedsoftware.com/twoup/ (Quelle des Screenshots, 16. August 2009) 3http://modeemi.fi/~tuomov/ion/ (16. August 2009) 4http://www.nongnu.org/ratpoison/ (16. August 2009) 5http://www.nongnu.org/stumpwm/ (16. August 2009) 5 Abbildung 2: StumpWM mit ungenutztem Bereich Die TWMs wmii6, XMonad7 und awesome8 sind Beispiele fur¨ dynamische TWMs. Was alle der genannten Beispiele fur¨ TWMs gemein haben, ist ein grunds¨atzliches Bestreben nach Minimalit¨at und Konfiguration durch die Benutzerin. So beschreibt z.B. die Webseite von StumpWM ein Ziel des Windowmanagers mit den Worten: Stumpwm attempts to be customizable yet visually minimal. There are " no window decorations, no icons, and no buttons. It does have various hooks to attach your personal customizations, and variables to tweak.\9 Awesome geht so weit, sich als ein Framework zur Erstellung eines pers¨onlichen Windowmanagers zu beschreiben, anstatt einer fertig verwendbaren Software: \[. ] awesome has been designed as a framework window manager. It's extremely fast, small, dynamic and heavily extensible using the Lua pro- gramming language. [. ] We provide an easily usable and very-well do- cumented API to configure and define the behaviour of your window manager.\10 6http://wmii.suckless.org/ (17. August 2009) 7http://xmonad.org/ (17. August