BlueTile – ein moderner Tiling Manager mit flacher Lernkurve

Individuelles Projekt Abstract: Tiling (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 -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 – Basis fur¨ BlueTile 8

5 Entwicklungsumgebung 11

6 Konfiguration 13

7 Erstes Starten 14

8 Hilfesystem 14

9 Funktionalit¨aten 16 9.1 -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 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. 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. vertreten. 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¨ 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 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 2009) 8http://awesome.naquadah.org/ (17. August 2009) 9http://www.nongnu.org/stumpwm/ (17. August 2009) 10http://awesome.naquadah.org/ (17. August 2009)

6 Abbildung 3: Awesome mit Masterfenster auf der linken Seite

Wie im Abschnitt 1 ausgefuhrt,¨ halte ich diese Ans¨atze fur¨ eine Quelle von großen Einstiegshurden¨ und sehe daher das Potential fur¨ einen neuen TWM, der in Bezug auf diese Punkte andere Wege geht. BlueTile ist der Versuch eines solchem Tiling Window Managers.

3 Zielgruppe

Um klare Designentscheidungen bei der Entwicklung von BlueTile treffen zu k¨onnen, habe ich grob eine Zielgruppe festgelegt: Meine Annahme ist, dass die typische Benutzerin von BlueTile jemand ist, die einen Tiling Window Manager ausprobieren m¨ochte, um herauszufinden, ob ein TWM fur¨ ihre Arbeitsweise von Nutzen sein kann. Sie m¨ochte dafur¨ jedoch nicht viel Zeit und Aufwand investieren, sondern schnell mit dem Ausprobieren beginnen. Die Benutzerin ist relativ sicher im Umgang mit Computern und verwendet aktiv virtuelle Desktops oder ist sich zumindest deren Existenz bewusst. Ich gehe davon aus, dass die Benutzerin eine Linux-Distribution nutzt und zur Zeit GNOME und dessen Windowmanager verwendet. Grunds¨atzlich funktioniert BlueTile auch in Kombination mit KDE oder ganz unabh¨angig von einer Desktopumgeb- ung. Eine Desktopumgebung anzunehmen, hat jedoch den Vorteil, dass auf viele

7 unterstutzende¨ Komponenten zuruckgegriffen¨ werden kann. Die wichtigste davon ist die Taskleiste, welche die offenen Fenster auffuhrt¨ und Zugriff auf sie bietet. In Ab- bildung 4 ist zu sehen, welche Komponenten alleine durch die Desktopumgebung GNOME bereitgestellt werden, da hier vorubergehend¨ Metacity deaktiviert wur- de. Die konkrete Kombination GNOME & Metacity anzunehmen, erm¨oglicht eine wesentlich bessere Integration, wie in Abschnitt 6 noch deutlich wird.

Abbildung 4: GNOME ohne Metacity

4 XMonad – Basis fur¨ BlueTile

Fur¨ die Entwicklung von BlueTile stellten sich mehrere M¨oglichkeiten. Zum Einen h¨atte ich einen komplett neuen Windowmanager von Grund auf schreiben k¨onnen. Da mein Fokus aber auf der einfachen Benutzbarkeit von bestehender Funktionalit¨at lag und nicht auf der Entwicklung von komplett neuer Funktionalit¨at, lag es nahe, bei diesem Vorhaben auf einer bestehenden Software aufzubauen. Es gab nun die M¨oglichkeiten, entweder einen klassischen Windowmanager um TWM-Funktionalit¨at zu erweitern oder einen TWM so zu ver¨andern, dass er einem klassischen Windowmanager ¨ahnlicher ist, um vorhandene Kenntnisse der Benutze- rin ausnutzen zu k¨onnen.

8 Da mein Ziel mit BlueTile darin besteht, das Tiling Window Paradigma leichter zug¨anglich zu machen, war es fur¨ mich wichtig, so viel Funktionalit¨at wie m¨oglich aus diesem Bereich beizubehalten. Um diese Vorgabe leichter einhalten zu k¨onnen, habe ich mich daher entschieden, meine Implementierung auf einem bestehenden TWM zu basieren. Da ich pers¨onlich ein Nutzer des TWMs XMonad [SS07] bin und mit diesem Windowmanager aus Anwendersicht sehr vertraut bin, war dies meine erste Wahl als Implementationsgrundlage. Erste Untersuchungen, ob XMonad auch aus Ent- wicklersicht eine gute Wahl w¨are, haben schnell gezeigt, dass eine Reihe von Fakten fur¨ XMonad sprechen: XMonad ist in Haskell geschrieben, einer Sprache, die dafur¨ bekannt ist, sehr kompakten Code zu produzieren. Im Vergleich zu anderen Windowmanagern hat XMonad daher auch eine sehr ubersichtliche¨ Codebase. Das Projekt ist in einen sehr kompakt gehaltenen Kern und eine Reihe von Zusatzmodulen aufgeteilt. Dadurch fiel es mir leicht, mir – trotz der noch etwas ungewohnten Sprache – eine Ubersicht¨ uber¨ die Architektur des Kerns zu erarbeiten. Zudem hat das XMonad-Team sehr strikte Regeln festgesetzt, was die Doku- mentation des Codes angeht. Das Resultat ist, dass sowohl der Kern als auch alle Zusatzmodule außerordentlich gut dokumentiert sind und damit die Einarbeitung wesentlich erleichtern. Eine Besonderheit von XMonad, uber¨ die die Meinungen weit auseinander gehen, besteht darin, dass es nicht nur in Haskell geschrieben ist, sondern auch komplett in Haskell konfiguriert wird. Dazu muss man verstehen, dass XMonad weniger ein tats¨achlicher Windowmanager ist, als mehr ein Baukastensystem fur¨ einen indivi- duell zusammengestellten Windowmanager. Bei der Erstellung der Konfiguration schreibt die Anwenderin im Prinzip das Hauptprogramm dieses Windowmanagers, in dem sie die gewunschten¨ Module kombiniert (siehe Abbildung 5). Dies erm¨oglicht eine extreme Flexibilit¨at bei der Konfiguration, da beliebiger Haskell-Code integriert werden kann. Auf der anderen Seite ist es ein Beispiel fur¨ eine große Einstiegshurde.¨ Selbst wenn man auch ohne Haskell-Kenntnisse bis zu einem gewissen Grad eine bestehende Konfiguration anpassen kann, k¨onnen doch die unvertrauten Fehlermeldungen des Haskell-Compilers sehr frustrierend fur¨ ei- ne Einsteigerin sein. Zudem braucht man nun nur fur¨ die Konfiguration des Win- dowmanagers einen Haskell-Compiler – aus Sicht einer Anwenderin eine zus¨atzliche Installation von recht umfangreicher Software. Wie in Abschnitt 6 genauer ausgefuhrt,¨ habe ich daher diese Art der Konfiguration fur¨ BlueTile nicht ubernommen.¨ Ich habe jedoch das zu Grunde liegende Baukas- tensystem genutzt, um die Standardkonfiguration von BlueTile damit zu erstellen.

9 1 import XMonad 2 import XMonad. Hooks . DynamicLog 3 import XMonad. Hooks . ManageDocks 4 import XMonad. Util .Run(spawnPipe) 5 import XMonad. Util .EZConfig(additionalKeys) 6 import System .IO 7 8 myManageHook = composeAll 9 [ className =? ”Gimp” −−> doFloat 10 , className =? ”Vncviewer” −−> doFloat 11 ] 12 13 main = do 14 xmproc <− spawnPipe 15 ”/path/to/xmobarbinary /path/to/.xmobarrc” 16 xmonad $ defaultConfig 17 −− make sure to include myManageHook 18 −− definition from above 19 { manageHook = manageDocks <+> myManageHook 20 <+> manageHook defaultConfig 21 , layoutHook=avoidStruts $ 22 layoutHookdefaultConfig 23 , logHook = dynamicLogWithPP $ xmobarPP 24 { ppOutput = hPutStrLn xmproc 25 ,ppTitle=xmobarColor”green” 26 ”” . shorten 50 27 } 28 −− Rebind Mod to the Windows key 29 , modMask = mod4Mask 30 } ‘additionalKeys ‘ 31 [ ( ( mod4Mask . | . shiftMask, xK z ) , 32 spawn ” xscreensaver −command −lock ” ) 33 , ( ( controlMask , xK Print ) , 34 spawn”sleep0.2;scrot −s ” ) 35 , ( ( 0 , xK Print) ,spawn ”scrot”) 36 ]

Abbildung 5: Beispiel einer XMonad-Konfiguration (Quelle: XMonad Wiki)

10 5 Entwicklungsumgebung

Wie viele andere Haskell-Projekte auch, verwendet XMonad fur¨ die Versionskon- trolle die Software Darcs11. Da ich auf XMonad aufbaue, lag es nahe, dass ich auch nutzen wurde.¨ Insbesondere unter dem Aspekt, dass ich vielleicht zukunftige¨ Entwicklungen oder Fehlerbehebungen im XMonad-Projekt auch in BlueTile uber-¨ nehmen wollen wurde¨ und umgekehrt sicherlich auch einige meiner Erweiterungen fur¨ das XMonad-Projekt nutzlich¨ sein k¨onnen, war es sinnvoll, Darcs beizubehalten. Ich hatte bisher fur¨ meine Projekte im Wesentlichen nur Subversion im Einsatz und daruber¨ hinaus nur ein wenig Erfahrung mit Git12 und Mercurial13 durch kurzes Ausprobieren gesammelt. Fur¨ den tats¨achlichen Einsatz in einem Projekt war Darcs daher meine erste Erfahrung mit einer dezentralen Versionskontrollsoftware. Mit Hilfe des Darcs-Handbuchs [Rou09] konnte ich mich recht schnell in Dar- cs einarbeiten, allerdings hat es etwas l¨anger gedauert, bis ich einen Arbeitsfluss finden konnte, der die M¨oglichkeiten von Darcs sinnvoll ausnutzt. Darcs hat keine zeitliche Abfolge von Patches. Ein Repository besteht aus einer Sammlung von Pat- ches, von denen einige komplett unabh¨angig sein k¨onnen und andere voneinander abh¨angen, weil beispielsweise die entsprechenden Anderungen¨ aufeinander aufbau- en. Dies erm¨oglicht ein beliebiges Zusammenstellen von ausgew¨ahlten Patches, so lange alle Abh¨angigkeiten erfullt¨ sind. Ich habe es daher schließlich so gemacht, dass ich fur¨ jede neue Funktionalit¨at, die ich implementieren wollte, eine komplette Kopie des Repositorys erstellt habe und dort die Funktionalit¨at entwickelt und committet habe. Wenn alles funktio- niert hat, habe ich dann die entsprechenden Patches wieder in das Hauptrepository heruberkopiert.¨ Auf diese Weise war es leicht m¨oglich, an verschiedenen Aspekten parallel zu arbeiten und Fehlentwicklungen zu verwerfen, ohne dass sie anderen Code beeintr¨achtigt h¨atten. Auch das Verfolgen und Integrieren von Entwicklungen im XMonad-Projekt war dadurch sehr problemlos, da naturlich¨ einfach die entsprechenden Patches hinzu- gefugt¨ werden konnten. Fur¨ die eigentliche Softwareentwicklung in Haskell habe ich den Texteditor VIM14 eingesetzt. Zum Einen weil ich mit diesem Editor sehr vertraut bin und damit sehr effizient Text bzw. Code bearbeiten kann. Zum Anderen aber auch deswegen, weil die Unterstutzung¨ fur¨ Haskell in Entwicklungsumgebungen wie Eclipse15 noch in den Anf¨angen steckt. Dagegen sind entsprechende Unterstutzungen¨ in m¨achtigen Tex- teditoren wie oder in der Regel schneller verfugbar.¨ In der Tat gibt es

11http://darcs.net/ (5. August 2009) 12http://git-scm.com/ (5. August 2009) 13http://www.selenic.com/mercurial/ (5. August 2009) 14http://www.vim.org/ (5. August 2009) 15http://www.eclipse.org/ (5. August 2009)

11 fur¨ VIM einen eigenen Haskell-Modus16, der sich bei der Entwicklung als hilfreiche Unterstutzung¨ herausgestellt hat. Er erm¨oglicht Dinge wie das automatische Com- pilieren der aktuellen Datei mit Anzeige von Compilerfehlern und Sprung an die entsprechende Stelle, dem Anzeigen von Typ-Informationen und anderen Angaben zu Bezeichnern im Code und dem Aufruf von Dokumentation zu Funktionen und Bibliotheken. Dokumentation wird fur¨ Haskell-Projekte in der Regel mit Haddock17 erstellt, welches ubersichtliche¨ HTML-Seiten generiert und meiner Erfahrung nach bei der Haskellprogrammierung eine exzellente und unverzichtbare Unterstutzung¨ darstellt. Die Programmiersprache Haskell kann mit ihrem kompromisslosen Ansatz und der rein funktionalen Natur teilweise eine sehr frustrierende Sprache sein. Meine Erfah- rung war aber, dass diese eingeforderte Disziplin oft zu besseren L¨osungen gefuhrt¨ hat, die auch auf lange Sicht besser und mit weniger ungewollten Wechselwirkungen mit dem restlichen System zusammengespielt haben. Durch das rigorose Typsystem und die funktionale Natur der Sprache werden ganze Arten von Fehlerquellen ver- hindert, was in der Regel zu sehr stabilem Code fuhrt.¨ Dies zeigte sich auch darin, dass BlueTile zu jedem Zeitpunkt der Entwicklung komplett und ohne Absturze¨ verwendbar war. Haskell erm¨oglichte es daruber¨ hinaus, sehr kompakten Code zu schreiben, was es leichter macht, die Ubersicht¨ zu behalten. Auch Umstrukturierun- gen von Code sind dadurch weniger aufwendig. Nachteilig wirkt sich aus, dass Haskell keine sehr verbreitete Sprache ist. Dies zeigt sich in Angebot und Qualit¨at von Hilfsbibliotheken. So lange man keine allzu exo- tischen Anforderungen hat, ist die aktuelle Situation sicher ausreichend. Ich hatte jedoch Probleme bei der Verwendung der Bibliothek Gtk2Hs, da ich anscheinend zu den Ersten geh¨orte, die mit dieser Bibliothek eine Dock-Applikation schreiben woll- ten (siehe Abschnitt 9.7). Dafur¨ ben¨otigte GTK-Funktionen wurden n¨amlich noch nicht durch die Bibliothek zur Verfugung¨ gestellt und ich musste unter Verwen- dung von -Code und dem Foreign Function Interface von Haskell18 direkt auf die entsprechenden Funktionen zugreifen. Dies w¨are sicher in einer st¨arker verbreiteten Sprache mit ausgereifteren Bibliotheken nicht n¨otig gewesen. Haskell hat eine sehr steile Lernkurve und das Lesen von bestehendem Haskell- Code kann – je nach Programmierstil der jeweiligen Autorin – teilweise extrem schwierig sein. Trotzdem kann ich aus meiner Erfahrung sagen, dass sich die Lernin- vestition lohnt, da ich die Programmierung in Haskell als sehr angenehm erfunden habe und sehr viel Vertrauen in die Qualit¨at der Ergebnisse gewinnen konnte.

16http://projects.haskell.org/haskellmode-vim/ (5. August 2009) 17http://www.haskell.org/haddock/ (5. August 2009) 18http://www.cse.unsw.edu.au/~chak/haskell/ffi/ (6. August 2009)

12 6 Konfiguration

Ein erkl¨artes Ziel von BlueTile ist die Verwendbarkeit ’out of the box’, also ohne dass es n¨otig ist, die Konfiguration anzupassen. Wie bereits erw¨ahnt, stellt die Kon- figuration eine erhebliche Einstiegshurde¨ dar, da die Benutzerin naturlich¨ noch nicht mit den verschiedenen M¨oglichkeiten vertraut ist. Im Fall von XMonad verwenden wahrscheinlich die wenigsten Benutzer und Benutzerinnen die minimale Standard- konfiguration, jedoch gibt es keine empfohlene Konfiguration, sondern nur eine riesi- ge Sammlung von M¨oglichkeiten auf der Webseite von XMonad. In dieser Sammlung die typischen von den exotischen Konfigurationen zu unterscheiden, erfordert einige Erfahrung mit XMonad und TWMs im Allgemeinen. In der Hoffnung, diese Arbeit – zumindest anfangs – der Benutzerin abnehmen zu k¨onnen, habe ich eine Zusammenstellung von XMonad-Modulen vorgenommen, die verbreitete Zus¨atze und Funktionalit¨at enth¨alt. Zudem habe ich die Gelegenheit genutzt, von der Alt-Taste zur Windows-Taste fur¨ alle Tastenkurzel¨ zu wechseln. Dieser Modifier key“ ist in XMonad frei konfigurierbar und fast alle Tastenkurzel¨ ” beinhalten diese Taste. Sie ist fur¨ maximale Kompatibilit¨at mit verschiedenen Tasta- turen standardm¨aßig mit der Alt-Taste belegt. Dies ist jedoch keine sehr praktikable Wahl, da viele andere Applikationen mit Tastenkurzeln¨ arbeiten, die Alt beinhalten. Daher ¨andern sehr viele Benutzer und Benutzerinnen von XMonad den Modifier ” key“ auf die Windows-Taste. Mir scheint es sinnvoller zu sein, diese Taste gleich zum Standard zu machen und Kompatibilit¨atsprobleme mit einigen exotischen Tas- taturlayouts zu riskieren. Einige wenige von mir hinzugefugten¨ Tastenkurzel¨ beinhalten nicht die Windows- Taste. Grunds¨atzlich halte ich es fur¨ sinnvoll, sich auf m¨oglichst wenig Modifier ” keys“ zu beschr¨anken, um die bereits angesprochenen Konflikte mit anderen Appli- kationen zu minimieren. Fur¨ einige Tastenkurzel¨ habe ich jedoch eine Ausnahme ge- macht, da es sich hierbei um Metacity-Tastenkurzel¨ fur¨ h¨aufig verwendete Aktionen wie dem Wechsel des virtuellen Desktops handelt. Da BlueTile als Metacity-Ersatz konzipiert ist, scheint es mir nutzlich,¨ einige vertraute Tastenkurzel¨ zu ubernehmen.¨ In vielen TWMs – so auch in XMonad – ist es Standard, die Option Fokus folgt ” Maus“ aktiviert zu haben. Dies hat den Effekt, dass ein Fenster bereits den Fokus erh¨alt, sobald sich die Maus nur daruber¨ hinwegbewegt. Es ist also nicht n¨otig das Fenster extra anzuklicken. Umgekehrt ist diese Option in traditionellen WMs in der Regel nicht aktiviert und da ich annehme, dass die Benutzerin mit traditionellen WMs vertraut ist, habe ich die Option auch in BlueTile deaktiviert. Auch wenn eine gute Standardkonfiguration fur¨ viele Benutzer und Benutzerinnen ausreichend sein kann, wird es immer die Notwendigkeit geben, die Konfiguration anpassen zu k¨onnen. Wie in Abschnitt 4 schon erw¨ahnt, habe ich XMonads Strate- gie der Konfiguration in Haskell selbst nicht ubernommen.¨ Zwar ist es ein m¨achtiges System, bringt jedoch fur¨ BlueTiles Zielgruppe zuviel Komplexit¨at und zus¨atzli-

13 che Schwierigkeiten mit sich. Daher sollte es fur¨ zukunftige¨ Versionen von BlueTile ein wichtiges Ziel sein, eine einfachere Konfigurationsm¨oglichkeit anzubieten. Im Rahmen des Individuellen Projekts konnte ich die Implementation eines solchen Konfigurationssystems nicht mehr leisten.

7 Erstes Starten

BlueTile versucht, leicht bedienbar zu sein und dieses Ziel sollte bereits beim Starten der Software sichtbar sein. Ein typisches Szenario k¨onnte sein, dass die Benutzerin ihren aktuellen Windowmanager verwendet und nun BlueTile ausprobieren m¨ochte (siehe Abschnitt 3). Dazu sollte es nicht n¨otig sein, die aktuelle Sitzung zu beenden und sich neu einzuloggen oder irgendwelche Konfigurationsdateien zu editieren. Viele Windowmanager (z.B. XFWM4, und Metacity) besitzen die M¨oglich- keit, einen bestehenden Windowmanager im laufenden Betrieb zu ersetzen. Teilweise muss dies explizit durch eine Option wie --replace“ angefordert werden. XMonad ” besaß solch eine Funktionalit¨at noch nicht, daher habe ich sie entsprechend den Angaben im Manual [Nye93] und meinen Anforderungen implementiert. Ich habe mich dafur¨ entschieden, diese Funktionalit¨at grunds¨atzlich aktiv zu ha- ben und es nicht n¨otig zu machen, sie explizit von der Benutzerin (z.B. via -- ” replace“) zu aktivieren. Die Gefahr eines versehentlichen Ersetzens des aktuellen Windowmanagers scheint mir eher gering. Auf der anderen Seite erm¨oglicht diese Entscheidung das Starten von BlueTile ohne jegliche Parameter, also insbesondere auch durch ein Icon oder einen Menueintrag,¨ wie er eventuell nach einer Installation durch einen Paketmanager vorhanden w¨are.

8 Hilfesystem

BlueTile versucht Funktionalit¨at auf leicht erschließbare Art und Weise zur Verfugung¨ zu stellen und dies bedeutet oft den Einsatz der Maus, da viele Benutzer und Be- nutzerinnen einen solchen Ansatz aus anderen Windowmanagern gew¨ohnt sind. Ein wesentlicher Vorteil von Tiling Window Managern besteht aber darin, dass sich die- ses Paradigma im Vergleich zu Stacking Window Managern wesentlich besser fur¨ ein Tastatur-basiertes Arbeiten eignet. Viele Arbeitsabl¨aufe lassen sich durch Tas- tenkurzel¨ sehr effizient ausfuhren¨ [LNPS05, S. 140]. Es w¨are daher wunschenswert,¨ die Benutzerin an solche Tastenkurzel¨ heranzufuhren.¨ Es stellt sich somit die Frage, auf welche Weise dies am besten erzielt werden kann. Grunds¨atzlich stellt sich in diesem Zusammenhang das Problem des Paradox ” of the Active User“ [CR87]. Dieser Begriff beschreibt den Effekt, dass eine Benutzerin dazu tendiert – nachdem sie eine Variante einer Operation auszufuhren¨ gelernt hat

14 – diesen Weg beizubehalten, auch wenn sie weiß, dass es vermutlich effizientere M¨oglichkeiten gibt, die gleiche Operation auszufuhren¨ [KA08, S. 239]. Ein Windowmanager, der zum Einstieg leicht erschließbare Bedienungsm¨oglichkei- ten bietet und sp¨ater Tastaturkurzel¨ vermitteln m¨ochte, ist mit dieser Schwierigkeit konfrontiert. Im Folgenden sollen einige M¨oglichkeiten zur L¨osung diskutiert werden. Eine begleitende Dokumentation kann und sollte vorhandene Tastenkurzel¨ auffuhren¨ und detailliert beschreiben. Allerdings wird diese von vielen Benutzern und Benut- zerinnen nicht gelesen [CR87, S. 2]. Viele Anwendungen gehen daher andere, zus¨atz- liche Wege, um die Benutzerin zu informieren. Ein verbreiteter Ansatz ist das An- zeigen eines Tipp des Tages“ beim Starten der Anwendung. In anderen Situationen ” werden Informationen, die fur¨ den aktuellen Kontext relevant sind, kurzzeitig einge- blendet. Ein Beispiel dafur¨ stellt das YouTube19-Applet dar, welches beim Wechseln in den Vollbildmodus einige Zeit einblendet, auf welche Weise der Modus wieder verlassen werden kann. Der Einsatz eines Tipp des Tages“ scheint fur¨ einen Windowmanager zu auf- ” dringlich zu sein: Der vorherige, klassische Windowmanager der Benutzerin ließ sich vermutlich ohne Dokumentation bedienen. Daher wird die Benutzerin sicherlich we- nig Verst¨andnis dafur¨ haben, dass BlueTile sie bei jedem Starten belehren m¨ochte. Eine kurzzeitige Einblendung hat den Nachteil, dass sie zwangsl¨aufig die Auf- merksamkeit auf sich zieht. Sie ist somit schwer zu ignorieren, selbst wenn die ein- zige Reaktion darin besteht, zu erkennen, dass die Meldung im Moment nicht von Interesse ist. Ein weiteres, sehr bekanntes Beispiel fur¨ kontext-bezogene Hilfe, stellt die Buro-¨ ” klammer“ dar, ein Assistent, welcher Bestandteil einiger Versionen von Microsoft Word war. Sie ist gleichzeitig ein Beispiel dafur,¨ welche Problematik solche Hilfe- systeme mit sich bringen, denn die Buroklammer¨ wurde von vielen Benutzern und Benutzerinnen als st¨orend empfunden: In der Studie [Swa03] wurde die Buroklam-¨ mer bei Befragungen als annoying“, always [. . . ] in the way“ und patronizing“ ” ” ” beschrieben. Zudem merkte eine Studienteilnehmerin an: I don’t want it to think ” you need help. . . I want to ask for it“ [Swa03, S. 26f]. Es stellt sich somit die Frage, ob Benutzer und Benutzerinnen grunds¨atzlich nicht ungefragt belehrt werden m¨ochten oder ob diese konkrete Implementation eines Hil- fesystems einfach nur ungeschickt und zu aufdringlich war. Auf der Suche nach einem Mittelweg zwischen unbeachteter Dokumentation und aufdringlicher Buroklammer,¨ scheint mir die beste Option darin zu bestehen, ein schmales Fenster ausschließlich fur¨ Meldungen vom Hilfesystem zu reservieren. Kurz- zeitige Einblendungen wurden¨ zwar dauerhaft weniger Bildschirmfl¨ache in Anspruch nehmen, sie sind aber – wie bereits erw¨ahnt – von der Benutzerin schwer zu ignorie- ren. Ein speziell dafur¨ vorgesehener Bereich – vergleichbar mit der Statuszeile eines

19http://www.youtube.com (5. August 2009)

15 Browsers – kann leichter von der Benutzerin ignoriert werden, wenn sie im Moment keine zus¨atzlichen Informationen erhalten m¨ochte. Wenn die Benutzerin Aktionen mit der Maus ausfuhrt,¨ k¨onnte diese Hilfesystemstatuszeile dann dafur¨ genutzt wer- den, um die entsprechenden Tastenkurzel¨ einzublenden. Dies hat gleichzeitig den Vorteil, dass es eine sehr kontext-bezogene Hilfestellung darstellt. Ein umfassendes Hilfesystem in dieser Form konnte im Rahmen des Individuel- len Projekts leider nicht mehr implementiert werden und muss zukunftigen¨ Ver- sionen von BlueTile vorbehalten bleiben. Implementieren konnte ich allerdings ein minimales Hilfesystem, welches sich darauf beschr¨ankt, eine einzelne Schnellstart- ” Anleitung“ beim allerersten Starten der Software einzublenden (siehe Abbildung 6). Sie vermittelt die Kernfunktionalit¨at von BlueTile, indem sie die Benutzerin anlei- tet, einige Fenster zu ¨offnen und erkl¨art, wie diese gekachelt werden k¨onnen. Zudem wird auf weitere Dokumentation verwiesen. Die Benutzerin kann dann dafur¨ sorgen, dass diese Anleitung zukunftig¨ nicht mehr eingeblendet wird.

Abbildung 6: Schnellstart-Anleitung“ ”

9 Funktionalit¨aten

Bevor ich die wesentlichen Funktionen von BlueTile im Detail diskutiere, m¨ochte ich an diese Stelle kurz die grunds¨atzlichen Designuberlegungen¨ darlegen. Diese

16 folgen den zwei Leits¨atzen Bekanntes wiederverwenden“ und Neues erschließbar ” ” machen“. Wo immer es m¨oglich ist, Bekanntes wiederzuverwenden“, m¨ochte ich diese Gele- ” genheit nutzen, um auf Erfahrungen der Benutzerin mit traditionellen WMs zuruck-¨ zugreifen. Dies kann uberall¨ dort erfolgen, wo sich die Funktionalit¨at von traditionel- len WMs und BlueTile gleicht oder zumindest ¨ahnelt. Der Vorgang des Verschiebens von Fenstern ist ein Kandidat dafur¨ (siehe Abschnitt 9.3). Auch wenn in einer geka- chelten Ansicht das Verschieben von Fenstern eingeschr¨ankt ist, kann die Funktion trotzdem in bekannter Weise aufgerufen werden – in diesem Fall uber¨ die Titelleiste eines Fensters, welche per Drag & Drop an eine andere Position gezogen wird. Anders sieht es bei Funktionen aus, die nur in TWMs zu finden sind. Hier gilt es Neues erschließbar zu machen“ und diese Funktionen in einer Form zu pr¨asentie- ” ren, die es im Idealfall m¨oglich macht, die neue Funktionalit¨at intuitiv zu nutzen, ohne weitere Dokumentation zu ben¨otigen. In diese Kategorie f¨allt beispielsweise das Wechseln zwischen verschieden Layout-Algorithmen (siehe Abschnitt 9.7). Bei der Diskussion der Funktionen habe ich diejenigen Funktionen vorgezogen, die besonders umfangreich sind und viele Wechselwirkungen mit anderen Funktio- nen haben. Auf diese Weise kann ich mich in sp¨ateren Abschnitten leichter darauf beziehen und es wird klar, wie die Funktionen zusammenspielen. Dies gilt inbeson- dere fur¨ den SWM-Modus, mit dem ich daher meine Diskussion beginne.

9.1 SWM-Modus Ein wesentlicher Bestandteil von XMonad – und damit auch von BlueTile – ist das Konzept verschiedener Layout-Algorithmen. Diese erm¨oglichen es, zwischen ver- schiedenen Arten zu wechseln, wie die vorhanden Fenster angeordnet werden. Dieser Mechanismus ist so flexibel, dass er theoretisch auch das klassische Paradig- ma von frei positionierten, sich uberlappenden¨ Fenstern nachstellen kann. Ich habe diese M¨oglichkeit genutzt, um einen solchen Layout-Algorithmus – im folgenden als SWM-Modus bezeichnet – zu implementieren20 (siehe Abbildung 7). Dadurch kann der Einstieg in die Welt von TWMs schrittweise gestaltet werden. Beim Starten von BlueTile kann der Benutzerin zuerst der vertraute SWM-Modus pr¨asentiert werden und sie wird dann dazu angeleitet, zu anderen Layout-Algorithmen zu wechseln, die dann tats¨achlich eine gekachelte Ansicht zeigen. Dies erfolgt unter Nutzung des Hil- fesystems, wie in Abschnitt 8 diskutiert. Der SWM-Modus bleibt jederzeit verfugbar¨ und die Benutzerin kann zu ihm zuruckwechseln,¨ wenn sie beispielsweise einen be- stimmten Arbeitsablauf lieber in einer gewohnten Umgebung durchfuhren¨ m¨ochte.

20Man k¨onnte argumentieren, dass BlueTile damit kein TWM mehr ist, sondern eher einen Hybrid- WM darstellt. Da ich aber die TWM-Funktionalit¨at von BlueTile als den wesentlichen Aspekt betrachte, bezeichne ich ihn weiterhin als solchen.

17 Da der SWM-Modus nur einen speziellen Layout-Algorithmus darstellt, bleiben al- le Funktionen, die vom Layout-Algorithmus unabh¨angig sind, in einer einheitlichen Form erhalten. Dies gilt beispielsweise fur¨ das Minimieren und Maximieren von Fenstern (siehe Abschnitt 9.5 bzw. 9.6).

Abbildung 7: SWM-Modus

An dieser Stelle sollte erw¨ahnt werden, dass XMonad bereits eine ¨ahnliche Funk- tionalit¨at enth¨alt, die jedoch auf andere Weise umgesetzt wurde. Die Erfahrung hat gezeigt, dass einige Applikationen – insbesondere solche mit vielen kleinen Fens- tern und Dialogen – eher schlecht mit TWMs zusammenspielen. Es gibt daher auch in XMonad eine Art SWM-Modus, der sogenannte Floating Layer“. Er ist jedoch ” nicht als separater Layout-Algorithmus implementiert, sondern liegt stattdessen als zus¨atzliche Schicht uber¨ dem aktuell aktiven Layout-Algorithmus. Ein Fenster kann nun aus der unterliegenden Schicht in den Floating Layer verschoben werden und dort beliebig positioniert und in der Gr¨oße ver¨andert werden. Fur¨ den darunter lie- genden Layout-Algorithmus existiert das Fenster nun nicht mehr und die restlichen Fenster werden entsprechend neu angeordnet. Dies stellt – meiner Ansicht nach – bereits das gr¨oßte Problem mit diesem Ansatz dar. Da der darunter liegende Layout-Algorithmus, auf Grund der Kachelung der Fenster, s¨amtlichen verfugbaren¨ Platz ausnutzt, uberdecken¨ die Fenster im Floa- ting Layer zwangsl¨aufig irgendwelche Fenster in der unteren Schicht. Da der Ein-

18 satz des Floating Layers daher meistens nur sinnvoll ist, wenn die unterliegende Schicht keine Fenster enth¨alt, scheint es mir sinnvoller, diesen gleich als eigenen Layout-Algorithmus umzusetzen. Zudem erfolgt das Positionieren und Ver¨andern der Gr¨oße von Fenstern im Floating Layer von XMonad durch eine sehr ungewohnte Kombination von Tastenkurzeln¨ und Mauskommandos. In einem eigenen Layout- Algorithmus, lassen sich diese Aspekte leichter an gewohnte Konventionen anpassen. Verloren geht bei diesem Ansatz nur die M¨oglichkeit, schwebende Fenster und ge- kachelte Fenster gleichzeitig sichtbar zu haben. Dies stellt – meiner Ansicht nach – keine große Einschr¨ankung dar, mit der wichtigen Ausnahme von kurzlebigen Fens- tern wie z.B. Dialogboxen, die nur kurz die Benutzerin auf etwas hinweisen oder eine Abfrage enthalten und dann sofort geschlossen werden. Hier ist es weder sinnvoll, diese Dialogbox in die gekachelte Ansicht einzufugen,¨ noch fur¨ so kurze Zeit in den SWM-Modus zu wechseln. Daher ist der Floating Layer in BlueTile nicht komplett verbannt, sondern er wird ausschließlich fur¨ solche Dialogboxen verwendet21 und es existiert keine direkte M¨oglichkeit, andere Fenster dahin zu verschieben.

Interaktion SWM-Modus/TWM-Modus Des Weiteren bleibt die Frage zu beantworten, inwiefern sich der SWM-Modus und die restlichen Layout-Algorithmen – der TWM-Modus – gegenseitig beeinflussen. Hierbei w¨are es zum Beispiel denkbar, dass eine Neupositionierung von Fenstern im TWM-Modus auch einen Effekt im SWM-Modus nach sich zieht, sobald man in diesen zuruckgewechselt¨ hat. Ich habe mich jedoch aus mehreren Grunden¨ gegen eine solche Interaktion ent- schieden. Zum Einen beeinflussen die verschiedenen Layout-Algorithmen des TWM- Modus sich im Großen und Ganzen auch nicht gegenseitig. Dementsprechend ist es nur konsequent, wenn der SWM-Modus – bei dem es sich ja auch nur um einen weite- ren Layout-Algorithmus handelt – auch nicht von den anderen Layout-Algorithmen beeinflusst wird. Zum Anderen wurde¨ sich eine etwaige Interaktion vermutlich fur¨ die Benutzerin als recht undurchsichtig darstellen. Denn eine beliebige Anordnung einer gekachelten Ansicht l¨asst sich naturlich¨ 1-zu-1 in den SWM-Modus ubertra-¨ gen, aber umgekehrt besitzt der SWM-Modus so wenig Einschr¨ankungen, dass eine Ubertragung¨ des aktuellen Zustands in eine gekachelte Ansicht in der Regel nicht oh- ne Weiteres durchzufuhren¨ ist. Der Versuch einer solchen Ubertragung¨ wurde¨ daher vermutlich nur eine Quelle fur¨ Verwirrung der Benutzerin darstellen. Es scheint mir daher besser, wenn die Fensteranordnung des SWM-Modus kom- plett unabh¨angig vom Rest ist. Dazu ist es sinnvoll, fur¨ s¨amtliche Fenster vorzuhal- ten, welche Position und Gr¨oße sie im SWM-Modus zuletzt hatten. Dadurch l¨asst

21Dialogboxen tragen spezielle Auszeichnungen, die es dem Windowmanager erm¨oglichen sie als solche zu erkennen und – falls n¨otig – speziell zu behandeln.

19 sich jederzeit die entsprechende Fensteranordnung wiederherstellen. Beim Offnen¨ ei- nes neuen Fensters, kundigt¨ dieses dem Windowmanager an, welche Position und Gr¨oße es bevorzugt. Diese Informationen k¨onnen direkt gespeichert werden, selbst wenn das Fenster im TWM-Modus ge¨offnet und unmittelbar gekachelt wird. Die In- formationen kommen erst zum Einsatz, wenn sp¨ater in den SWM-Modus gewechselt wird. Diese Funktionalit¨at erm¨oglicht ein nutzliches¨ Anwendungsszenario: Die Benut- zerin befindet sich im TWM-Modus und ¨offnet eine Applikation mit vielen kleinen Fenstern und Dialogen. Der aktuell aktive Layout-Algorithmus kachelt s¨amtliche Fenster, aber die Benutzerin entscheidet, dass es fur¨ diese Applikation nicht sehr sinnvoll ist. Sie kann nun in den SWM-Modus wechseln und die Applikation wird so angeordnet, wie sie auch in einem klassischen Windowmanager erscheinen wurde.¨ Die Information uber¨ Fensterposition und -gr¨oße im SWM-Modus stets vorzuhal- ten ist außerdem nutzlich,¨ wenn ein Fenster auf einen anderen virtuellen Desktop verschoben wird. Eventuell befindet sich der Zieldesktop im TWM-Modus und da- durch wird das verschobene Fenster sofort gekachelt. Wird sp¨ater auf diesem virtu- ellen Desktop in den SWM-Modus gewechselt, muss weiterhin bekannt sein, wie das Fenster nun positioniert werden soll.

Berucksichtigung¨ von Dual-Head-Systemen XMonad – und damit auch BlueTile – besitzt eine sehr gute, wenn auch ungew¨ohn- liche Unterstutzung¨ fur¨ Dual-Head-Systeme – sprich die gleichzeitige Nutzung von zwei Bildschirmen. Typischerweise betrachten Windowmanager zus¨atzliche Bild- schirme einfach als eine Vergr¨oßerung der Desktopfl¨ache. Wenn die Benutzerin dann auf einen anderen virtuellen Desktop wechselt, zeigen beide Bildschirme den neu- en virtuellen Desktop. XMonad setzt stattdessen das Konzept um, dass eine Reihe von virtuellen Desktops existiert und jeder Bildschirm unabh¨angig vom anderen stets einen virtuellen Desktop komplett anzeigt. In einem Dual-Head-Setup k¨onnen dementsprechend stets zwei der virtuellen Desktops fur¨ die aktuelle Anzeige aus- gew¨ahlt werden und s¨amtliche Kombinationen sind m¨oglich. Aus diesem ungew¨ohnlichen Konzept ergeben sich Konsequenzen fur¨ den SWM- Modus. Fenster befinden sich stets auf genau einem virtuellen Desktop22. Ein virtu- eller Desktop kann jedoch zu verschiedenen Zeiten auf verschiedenen Bildschirmen sichtbar sein. Das System muss also berucksichtigen,¨ dass Fensterpositionen nicht absolut zur gesamten Desktopfl¨ache gelten, sondern relativ zum zugeh¨origen Bild- schirm. Hinzu kommt, dass die Benutzerin bei einem Dual-Head-Setup die M¨oglichkeit hat, ein Fenster per Drag & Drop von einem Bildschirm auf den anderen zu ziehen

22Die M¨oglichkeit ein Fenster auf allen virtuellen Desktops sichtbar zu machen, existiert zur Zeit in XMonad nicht.

20 und damit von einem virtuellen Desktop auf einen anderen. Da auf dem Zieldesktop unter Umst¨anden ein anderer Layout-Algorithmus aktiv ist, kann dies dazu fuhren,¨ dass ein gekacheltes Fenster in den SWM-Modus ubergeht¨ oder umgekehrt. Aus Sicht der Benutzerin unterscheiden sich diese verschiedenen F¨alle nicht groß, aber das System muss alle Kombinationen korrekt behandeln. Daruberhinaus¨ ist es m¨oglich, dass die beiden Bildschirme mit unterschiedlichen Aufl¨osungen arbeiten. Wenn nun ein virtueller Desktop vom Bildschirm mit der gr¨oßeren Aufl¨osung zu dem mit der kleineren wechselt, k¨onnen die Fenster nicht mehr komplett dargestellt werden. Im TWM-Modus l¨ost der aktive Layout-Algorithmus dieses Problem, in dem die Fenster entsprechend der ver¨anderten Aufl¨osung neu angeordnet werden. Um einen ¨ahnlichen Effekt im SWM-Modus zu erzielen, habe ich auch hier eine automatische Gr¨oßen¨anderung implementiert. Beim Wechsel von einer Aufl¨osung zu einer anderen, werden s¨amtliche Fenster in ihrer Gr¨oße und Position proportional zur Ver¨anderung angepasst (siehe Abbildungen 8 und 9).

Abbildung 8: Der linke Monitor zeigt den virtuellen Desktop 5, der rechte den vir- tuellen Desktop 3

Abbildung 9: Die Position der zwei virtuellen Desktops wurde getauscht – die Fens- ter passen sich entsprechend an

21 9.2 Fensterdekoration Als Fensterdekoration wird der schmale Rahmen um ein Fenster und seine Titelleiste bezeichnet. Diese findet sich in vielen klassischen WMs. Sie erm¨oglicht es, eine Reihe von Funktionen fur¨ das entsprechende Fenster mit der Maus zu aktivieren. Dazu z¨ahlt das Andern¨ der Gr¨oße des Fensters, das Verschieben des Fensters, sowie weitere Funktionen, die uber¨ Symbole am linken und rechten Rand der Titelleiste aufrufbar sind. Dazu geh¨oren in der Regel das Minimieren, Maximieren und Schließen des Fensters, sowie der Aufruf eines Fenstermenus,¨ welches s¨amtliche – auch weniger genutze – Funktionen fur¨ das Fenster enth¨alt (siehe Abbildung 10 fur¨ ein Beispiel).

Abbildung 10: Fensterdekoration und -Menu¨ in Metacity

Viele TWMs bieten nur eine sehr minimale oder uberhaupt¨ keine Fensterdekora- tion an. Da der Fokus auf der Nutzung durch die Tastatur liegt, ist die Fensterdeko- ration uberfl¨ ussig¨ und der gewonnen Platz – wenn auch minimal – kann besser fur¨ die eigentlichen Fensterinhalte genutzt werden. Diese Uberlegung¨ trifft nicht auf BlueTile zu, daher habe ich dieses bekannte Bedienelement wieder eingefuhrt.¨ Genau wie in klassischen WMs, erm¨oglicht es den Zugriff auf die bereits angesprochene Funktionalit¨at (siehe Abbildung 11). Das Symbol X zum Schließen eines Fensters erkl¨art sich von selbst. Die Details des Minimierens (Symbol ) und Maximierens (Symbol []) werden in den Abschnitten 9.5 und 9.6 genauer ausgefuhrt.¨ Uber¨ das Symbol (M) l¨asst sich das Fenstermenu¨ auf- rufen (siehe Abbildung 12). Um Entwicklungszeit zu sparen, habe ich hierfur¨ ein bereits bestehendes Modul von XMonad genutzt, welches eine Reihe von Optio- nen in Form einer Raute anzeigt. Anstatt ein konventionelles Menu¨ von Grund auf

22 Abbildung 11: Fensterdekoration in BlueTile zu entwickeln, habe ich auf diesem Code aufgebaut. Um zu signalisieren, dass das Menu¨ zum Fenster geh¨ort, zentriere ich die Raute grob in der Mitte des Fensters. Neben den bereits angesprochenen Funktionen bietet das Menu¨ die M¨oglichkeit, das Fenster auf einen anderen virtuellen Desktop zu verschieben.

Abbildung 12: Fenstermenu¨

9.3 Fenster verschieben Offensichtlich geh¨ort zum t¨aglichen Arbeiten mit Windowmanagern auch das Ver- schieben von Fenstern an eine neue Position. Aus klassischen Windowmanagern ist man gew¨ohnt, dass dies typischerweise mit Hilfe der Maus und der Fensterdekorati- on erfolgt – genauer gesagt uber¨ die Titelleiste eines Fensters, die per Drag & Drop an eine neue Position gezogen wird. Fur¨ den SWM-Modus von BlueTile kann diese Herangehensweise unver¨andert ubernommen¨ werden. Aber auch im TWM-Modus gibt es das Konzept des Verschiebens von Fenstern, auch wenn die Verschiebung hier st¨arker eingeschr¨ankt ist. Da die Position der Fens-

23 ter durch den Layout-Algorithmus bestimmt werden und somit keine beliebigen Fensterpositionen m¨oglich sind. Das Verschieben eines Fensters beschr¨ankt sich hier auf das Einnehmen der Position eines anderen Fensters, des Zielfensters. Trotzdem kann der gleiche Mechanismus auch hier genutzt werden: Die Benutzerin nutzt die Titelleiste, um ein Fenster per Drag & Drop zu ziehen. Sie zieht das Fenster dann auf ein anderes Fenster und w¨ahlt damit aus, welche Position das ursprungliche¨ Fenster nun einnehmen soll. Um ein visuelles Feedback zu geben, habe ich es so umgesetzt, dass w¨ahrend des Vorgangs das Fenster dem Mauszeiger folgt (siehe Abbildung 13). Wird kein gultiges¨ Ziel ausgew¨ahlt, springt das Fenster zuruck¨ an seine ursprungliche¨ Position – im anderen Fall nimmt es die Position des ausgew¨ahlten Ziels an (siehe Abbildung 14).

Abbildung 13: Fenster wird per Drag & Drop verschoben

Abbildung 14: Fenster tauscht mit dem ausgew¨ahlten Ziel die Position

24 Es stellt sich nun noch die Frage, wohin das Zielfenster verschoben wird. Da es eine feste Reihenfolge der Fenster gibt, k¨onnte das verschobene Fenster einfach an der ausgew¨ahlten Position eingefugt¨ werden und die nachfolgenden Fenster wurden¨ eine Position nach hinten wandern. Eine weitere M¨oglichkeit besteht darin, dass das Zielfenster die alte Position des verschobenen Fensters einnimmt und somit die bei- den Fenster einfach die Positionen tauschen. Ich habe mich fur¨ letztere M¨oglichkeit entschieden, da es mir sehr naheliegend erscheint und m¨oglichst wenig – potentiell verwirrende - zus¨atzliche Bewegung auf dem Bildschirm erzeugt.

9.4 Fenstergr¨oße ¨andern Ahnlich¨ grundlegend wie das Verschieben von Fenstern ist das Ver¨andern der Gr¨oße von Fenstern. In klassischen Windowmanagern erfolgt auch dies uber¨ die Fensterde- koration. Diese beinhaltet einen Rahmen um das Fenster herum, der genutzt werden kann, um das Fenster mit der Maus in die gewunschte¨ Gr¨oße zu bringen. Erneut kann dieser Ansatz fur¨ den SWM-Modus von BlueTile ubernommen¨ werden. Im TWM-Modus sieht die Situation etwas anders aus. Fenster uberlappen¨ sich nicht und die gesamte Bildschirmfl¨ache wird genutzt. Daher werden durch ein Ver- gr¨oßern oder Verkleinern eines Fensters, zwangsl¨aufig auch andere Fenster in ihrer Gr¨oße beeinflusst. Zudem sind nicht alle Arten der Gr¨oßen¨anderung in diesem Mo- dus uberhaupt¨ sinnvoll. Beispielsweise k¨onnte die Situation gegeben sein, dass ein Fenster durch einen Layout-Algorithmus bundig¨ mit dem linken Rand plaziert wird. Wurde¨ man dieses Fenster nun von der linken Seite aus verkleinern, wurde¨ es stets automatisch neu an den linken Rand herangeschoben werden. Im Endeffekt w¨are das Ergebnis also das selbe, wie wenn man das Fenster von der rechten Seite aus verkleinert h¨atte. Daher ist es im TWM-Modus sinnvoller statt mit der Gr¨oßen¨anderung einzelner Fenster, mit dem Konzept der Ver¨anderung der Trennlinien zwischen den Fenstern zu arbeiten. Dadurch wird automatisch deutlich, dass das Verschieben einer Trennlinie zwischen zwei Fenstern offensichtlich die Gr¨oße beider Fenster beeinflusst. Diesem Konzept folgend, habe ich die gekachelten Layouts von BlueTile um die M¨oglichkeit erweitert, die Trennlinien mit der Maus zu verschieben. Um diese M¨oglichkeit zu signalisieren, ver¨andert sich der Mauszeiger beim Uberfahren¨ der Trennlinien (siehe Abbildung 15). Die Tastaturbedienung der Gr¨oßen¨anderung im TWM-Modus konnte ich un- ver¨andert von XMonad ubernehmen.¨ Hierbei werden die Trennlinien uber¨ Tasta- turkommandos um einen festen Wert nach links oder rechts bzw. oben oder un- ten verschoben. Das aktuell fokusierte Fenster entscheidet dabei, welche Trennlinie ver¨andert wird. Je nach Tastaturkommando beziehen sich die Anderungen¨ auf die Trennlinie rechts vom Fenster oder diejenige unterhalb des Fensters. Auf Grund der vielen Freiheitsgrade ist fur¨ den SWM-Modus zur Zeit keine M¨oglichkeit vorgesehen,

25 Abbildung 15: Mauszeiger uber¨ einer Trennlinie die Fenster alleine durch die Tastatur in ihrer Gr¨oße zu ver¨andern.

9.5 Minimieren Von klassischen Windowmanagern ist man gew¨ohnt, Fenster minimieren zu k¨onnen, die gerade nicht von Interesse sind. Wie viele TWMs bietet XMonad eine derartige M¨oglichkeit nicht direkt. Allerdings halte ich eine Minimierungsfunktion in einem TWM fur¨ noch wichtiger als in einem SWM. In einem SWM k¨onnen Fenster, die aktuell nicht von Interesse sind, zur Not im Hintergrund bleiben und durch andere Fenster verdeckt werden. Da sich aber in TWMs Fenster in der Regel nicht uberlappen,¨ nehmen hier solche Fenster zwangsl¨aufig Bildschirmfl¨ache ein. Dies ist also eine potentiell frustrierende Erfahrung fur¨ eine neue Benutzerin, daher wurde¨ eine vertraute Minimierungsfunk- tion eine große Einstiegshilfe darstellen. Die einzige Funktionalit¨at XMonads, die ein Stuck¨ in diese Richtung geht, sind Layout-Algorithmen, die manche Fenster uberhaupt¨ nicht darstellen. So bietet XMo- nad einen Layout namens TwoPane“, bei dem jeweils nur zwei Fenster sichtbar ” sind: Auf der linken Seite das Master-Fenster und auf der rechten Seite das n¨achs-

26 te Fenster in der Reihe oder das Fenster, welches den Fokus hat. Dadurch ist das Master-Fenster stets sichtbar und welches von den restlichen Fenstern aktuell sicht- bar sein soll, wird durch den Fokus bestimmt. Diese M¨oglichkeit scheint mir jedoch relativ ungewohnt zu bedienen zu sein und sie bedeutet insbesondere, dass der Layout-Algorithmus ge¨andert werden muss, nur um einige Fenster zu minimieren. Dies ist schwer vermittelbar an eine Benutzerin, die an klassische Windowmanager gew¨ohnt ist. Eine weitere M¨oglichkeit besteht darin, Fenster, die aktuell nicht von Interesse sind, auf einen anderen virtuellen Desktop zu verschieben. Dies stellt aber mehr eine Art Trick, eine Notl¨osung fur¨ eine fehlende Minimierungsfunktion dar. Sich allein auf diese M¨oglichkeit zu verlassen, wurde¨ bedeuten, vorauszusetzen, dass die Benutzerin mit virtuellen Desktops vertraut ist und sich dieses Tricks bewusst ist. Insbesondere die zweite Annahme wird vermutlich in vielen F¨allen nicht zutreffen. Ich habe mich daher entschlossen, eine Minimierungsfunktion – vergleichbar da- zu, wie sie sich in klassischen Windowmanagern findet – zu implementieren. Diese soll es erm¨oglichen, beliebige Fenster – unabh¨angig vom Layout-Algorithmus – zu minimieren und sp¨ater wiederherstellen zu k¨onnen. Sobald ein Fenster minimiert wird, ist es nur noch auf der sichtbar. Der aktuelle Layout betrachtet es als nicht-existent und ordnet die verbleibenden Fenster entsprechend neu an. Dadurch, dass die Funktionalit¨at in vertrauter Weise gestaltet wird, k¨onnen Benutzer und Benutzerinnen erneut Kenntnisse aus klassischen Windowmanagern nutzen (siehe Abbildungen 16 und 17). Beim Design der Funktionalit¨at waren mehrere Aspekte zu beachten:

• Wie erfolgt die Bedienung durch die Maus?

• Wie verh¨alt sich der Fokus in Bezug auf minimierte Fenster?

• Wie verh¨alt sich der Fokus beim Minimieren und Wiederherstellen von Fens- tern?

• Wo wird das wiederhergestellte Fenster positioniert?

• Wie erfolgt die Bedienung durch die Tastatur?

Die Bedienung durch die Maus ließ sich leicht nach dem Vorbild klassischer Win- dowmanager modellieren. Uber¨ einen Button in der Fensterdekoration l¨asst sich ein Fenster minimieren und findet sich dann nur noch auf der Taskleiste. Da GNOME als angenommen wird (siehe Abschnitt 3), ist eine solche vorhan- den. Das Wiederherstellen eines Fensters erfolgt durch Anklicken auf der Taskleiste. Ein weiterer Aspekt ist die Interaktion zwischen dem Fokus und minimierten Fens- tern. Wenn der Fokus uber¨ die Tastatur gewechselt wird, existiert eine bestimmte

27 Abbildung 16: Rotes Fenster soll minimiert werden

Abbildung 17: Rotes Fenster wurde minimiert

28 Reihenfolge, in der Fenster den Fokus bekommen. Es stellt sich nun die Frage, ob mi- nimierte Fenster weiterhin in dieser Reihenfolge auftauchen und dann beispielsweise wiederhergestellt werden, sobald sie den Fokus bekommen, oder ob sie komplett aus dieser Reihenfolge herausgenommen werden sollen. Nach Feedback durch einige Benutzer und Benutzerinnen und nach eigener Uber-¨ legung habe ich mich dafur¨ entschlossen, die minimierten Fenster komplett aus der Fokus-Reihenfolge herauszunehmen. Dies folgt der Idee, dass minimierte Fenster zur Zeit nicht von Interesse sind und erst wieder explizit durch Anklicken aus diesem Status befreit werden mussen.¨ Zudem bleibt die Fokus-Reihenfolge damit leichter zu uberblicken.¨ Beim Erreichen des letzten Fensters der Reihe, springt der Fokus wie- der an den Anfang. Dies ist wesentlich intuitiver, als wenn vorher noch minimierte Fenster durchlaufen wurden¨ und der Fokuswechsel hier sogar andere Aktionen – ein Wiederherstellen von Fenstern – ausl¨osen wurde.¨ In Bezug auf den Fokus bleibt dann noch die Frage zu beantworten, wie sich ein Minimieren und Wiederherstellen von Fenstern auf den Fokus auswirkt. Hier orientiere ich mich daran, was passiert, wenn ein Fenster geschlossen wird. In diesem Fall wandert der Fokus weiter zum n¨achsten Fenster in der Fokus-Reihenfolge. Dies habe ich ubernommen¨ fur¨ das Minimieren von Fenstern. Das Wiederherstellen eines Fensters druckt¨ aus, dass die Benutzerin sich damit besch¨aftigen m¨ochte. Es ist also sinnvoll, dem wiederhergestellen Fenster den Fokus zu geben. Bei der Positionierung von wiederhergestellen Fenstern er¨offnen sich im Wesent- lichen zwei M¨oglichkeiten: Das Fenster k¨onnte als Master-Fenster gesetzt werden, da die Benutzerin sich offensichtlich damit besch¨aftigen will. Alternativ k¨onnte man das Fenster wieder dort einreihen, wo es sich vorher befunden hat. Ich habe mich fur¨ letztere Option entschieden, da dadurch ein Minimieren und sofortiges Wiederher- stellen erneut zur Ausgangsanordnung fuhrt¨ und die Fensterpositionen nicht unn¨otig durcheinander bringt. Da die Bedienung durch die Tastatur fur¨ fortgeschrittene Benutzer und Benut- zerinnen ein wesentliches Feature darstellt, sollte die Minimierungsfunktion auch uber¨ Tastenkurzel¨ benutzbar sein. Das Minimieren des fokusierten Fensters l¨asst sich leicht auf eine Tastenkombination legen. Schwieriger sieht es mit dem Wieder- herstellen von Fenstern aus. Hier stellt sich die Frage, wie ausgew¨ahlt wird, welches Fenster wiederhergestellt werden soll. Schließlich k¨onnen potentiell mehrere Fenster gleichzeitig minimiert sein. Die Option, diese Auswahl durch Wechsel des Fokus zu treffen, wurde bereits diskutiert und verworfen. Es w¨are m¨oglich, eine alternative Fokus-Reihenfolge nur fur¨ minimierte Fenster einzufuhren.¨ Dies scheint mir jedoch verh¨altnism¨aßig aufwendig und potentiell verwirrend zu sein. Ich habe mich daher entschlossen, eine einfache L¨osung zu w¨ahlen und dafur¨ eine Einschr¨ankung in Kauf zu nehmen: Das Wiederherstellen wird nun uber¨ ein einzelnes Tastenkurzel¨ ausgel¨ost. Wiederhergestellt wird dabei das zuletzt minimierte Fenster.

29 Somit l¨asst sich – nur mit der Tastatur – nicht direkt ausw¨ahlen, welches Fenster wiederhergestellt werden soll. Zur Not mussen¨ mehrere Fenster wiederhergestellt und dann einige wieder minimiert werden. Um leichter durch alle minimierten Fenster wechseln zu k¨onnen, w¨are eine Variante denkbar, bei der das mehrmalige Bet¨atigen des Tastenkurzels¨ dazu fuhrt,¨ dass zum einen das n¨achste minimierte Fenster wie- derhergestellt wird, jedoch gleichzeitig das zuvor wiederhergestellte Fenster zuruck¨ in den minimierten Zustand wechselt. Auf diese Weise k¨onnte man gezielt nach ei- nem bestimmten minimierten Fenster suchen. Bei dieser Variante bleibt jedoch die Frage offen, wie man ein Fenster dauerhaft wiederherstellt, wenn man nicht mehr m¨ochte, dass es zuruck¨ in diesen Kreislauf f¨allt. Naturlich¨ w¨are ein weiteres, zus¨atz- liches Tastenkurzel¨ denkbar, aber eine solche L¨osung scheint wenig transparent fur¨ die Benutzerin zu sein. Ich habe daher die ursprungliche¨ Variante implementiert und in Kauf genommen, dass – bei Tastatur-Benutzung – unter Umst¨anden Fenster vorubergehend¨ wiederhergestellt und direkt wieder minimiert werden mussen.¨ Der Vorteil dieser L¨osung ist, dass nur ein Tastenkurzel¨ ben¨otigt wird.

9.6 Maximieren Neben dem Minimieren, ist das Maximieren eine Funktion, die aus klassischen Win- dowmanagern bekannt ist. Auch sie wird dort in der Regel uber¨ einen Button in der Fensterdekoration aufgerufen. Diese Vorkenntnisse lassen sich nutzen, um auch in BlueTile eine vergleichbare Funktionalit¨at auf ¨ahnliche Weise zur Verfugung¨ zu stellen. Grunds¨atzlich ist es in einer gekachelten Ansicht schwierig, einem einzelnen Fens- ter besonders viel Fl¨ache zu geben. Denn dies fuhrt¨ zwangsl¨aufig dazu, dass alle anderen Fenster auf kleinsten Raum zusammengeschoben werden und nicht mehr benutzbar sind. Eine extra Funktion zum Maximieren ist somit sinnvoll. Eine M¨oglichkeit, zu maximieren besteht bereits darin, zum Layout-Algorithmus Vollbild“ zu wechseln. Hier werden alle Fenster maximiert und sichtbar ist immer ” nur das, welches den Fokus hat. Um vorubergehend¨ ein Fenster zu maximieren, k¨onn- te man also das entsprechende Fenster fokusieren, dann zum Layout-Algorithmus Vollbild“ wechseln und sp¨ater wieder zuruck¨ zum vorher verwendeten Layout- ” Algorithmus wechseln. Diese M¨oglichkeit setzt jedoch voraus, dass die Benutzerin bereits relativ vertraut mit den verschiedenen Layout-Algorithmen ist und mit der M¨oglichkeit, schnell zwischen ihnen zu wechseln. Inbesondere am Anfang ist dies vermutlich nicht der Fall. Ein weiterer Nachteil des Vollbild-Layout-Algorithmus besteht darin, dass hier die Gefahr besteht, die Orientierung zu verlieren. Da nur ein Fenster sichtbar ist, kann leicht Verwirrung daruber¨ entstehen, wie die restlichen Fenster wiederherge- stellt werden k¨onnen, bevor die Benutzerin mit der genauen Semantik dieses Layout- Algorithmus vertraut ist.

30 Ich habe mich daher entschieden, die Funktionalit¨at des Maximierens unabh¨angig vom Layout-Algorithmus zur Verfugung¨ zu stellen und derart umzusetzen, dass Ver- wirrung m¨oglichst vermieden wird. Dies fuhrt¨ zu mehreren Designentscheidungen: In jedem Layout kann ein belie- biges Fenster maximiert werden – dies erfolgt entweder uber¨ einen Button in der Fensterdekoration oder uber¨ ein Tastenkurzel.¨ Dieses Fenster wird dann aus dem bestehen Layout herausgel¨ost und vergr¨oßert dargestellt. Um der Benutzerin Ori- entierung zu bieten, wird das Fenster jedoch nicht zu 100 % maximiert, sondern es wird ein kleiner Rand beibehalten, durch den erkennbar ist, wo sich die restlichen Fenster befinden (siehe Abbildung 18).

Abbildung 18: Maximiertes Fenster im Vordergrund

Um die Interaktion mit diesen anderen Fenstern weiterhin zu erm¨oglichen, wird das maximierte Fenster ganz in den Hintergrund verschoben, sobald der Fokus zu einem der anderen Fenster wechselt. Das maximierte Fenster ist jetzt nur durch die Lucke¨ sichtbar, an der es sich vorher – in nicht-maximierter Form – befunden hat (siehe Abbildung 19). Auf diese Weise l¨asst sich relativ leicht zwischen dem maximierten Fenster und den restlichen Fenstern wechseln. Zus¨atzlich habe ich noch die Limitierung eingefuhrt,¨ dass nur ein Fenster zur glei- chen Zeit maximiert werden kann. Dies soll ebenfalls die Orientierung erleichtern. Da mehrere maximierte Fenster sich sowieso uberdecken¨ wurden,¨ geht hier auch kei-

31 Abbildung 19: Maximiertes Fenster im Hintergrund ne wichtige Funktionalit¨at verloren. Wird ein anderes Fenster maximiert, so gleitet das aktuell maximierte Fenster zuruck¨ an seine ursprungliche¨ Position und das neue Fenster wird maximiert. Auf diese Weise bleibt es stehts m¨oglich, Fenstern durch Anklicken den Fokus zu geben, da sie sich niemals komplett uberdecken.¨

9.7 Dock-Applikation Bei der Dock-Applikation handelt es sich um eine schmale Funktionsleiste am linken Rand des Bildschirms (siehe Abbildung 20). Sie resultiert aus dem Wunsch, einen Ort zu haben, wo Funktionen untergebracht werden k¨onnen, die nur in TWMs zu finden sind. Funktionen also, die erschließbar“ gemacht werden mussen,¨ da sie der ” Benutzerin nicht von klassischen WMs her bekannt sind. Das zentrale Feature in dieser Kategorie ist der Wechsel zwischen verschiedenen Layout-Algorithmen. Insbesondere unter dem Aspekt betrachtet, dass BlueTile im klassischen SWM-Modus startet (siehe Abschnitt 9.1) und damit der Wechsel zu einem anderen Layout-Algorithmus Voraussetzung ist, um uberhaupt¨ Fenster zu kacheln.

32 Abbildung 20: Dock-Applikation

Hot Corners“ ” Meine erste Uberlegung¨ war, diese Funktionalit¨at uber¨ das Konzept der Hot Cor- ” ners“ verfugbar¨ zu machen. Hierbei ist die Idee, dass eine Funktion dadurch aktiviert wird, dass die Maus in eine der Bildschirmecken bewegt wird. Auf diese Weise ließen sich vier Funktionen – eine in jeder Bildschirmecke – unterbringen, die nur mit der Maus erreichbar w¨aren. Da BlueTile vier verschiedene Layout-Algorithmen anbietet, wurde¨ sich eine entsprechende Belegung der vier Ecken anbieten. Es ergeben sich jedoch eine Reihe von Problemen mit diesem Ansatz: Zum Einen l¨asst er sich nicht ohne Weiteres auf ein Dual-Head-Setup ubertragen.¨ In einem solchen Setup gibt es weiterhin nur vier nutzbare Ecken – die ¨außeren Ecken der gesamten Bildschirmfl¨ache – denn nur diese sind mit der Maus gezielt ansteuerbar. Layout-Algorithmen sind jedoch fur¨ jeden virtuellen Desktop – und damit fur¨ je- den Bildschirm – separat einstellbar. Von den vier nutzbaren Ecken bleiben somit nur zwei fur¨ jeden Bildschirm ubrig.¨ Um damit noch alle vier Layout-Algorithmen verfugbar¨ zu machen, w¨are es zwar denkbar, die Belegungen n¨achster Layout- ” Algorithmus“ und vorheriger Layout-Algorithmus“ zu w¨ahlen, aber dies scheint ” mir weniger intuitiv als eine direkte Belegung zu sein. Ein weiteres Problem stellt die Tatsache dar, dass die Belegung der Ecken nicht unmittelbar sichtbar ist. Es w¨are also n¨otig, die Benutzerin darauf hinzuweisen, dass

33 mit Hilfe der Ecken der Layout-Algorithmus gewechselt werden kann. Schließlich existiert bei Hot Corners“ immer das Problem, die Funktionen ver- ” sehentlich auszul¨osen. Dies kann auf Dauer sehr ¨argerlich sein. Abhilfe kann hier schaffen, zu erfordern, dass zus¨atzlich ein Modifier key“ – wie die Windows-Taste – ” gedruckt¨ sein muss, um die Funktion beim Bewegen der Maus in eine Ecke tats¨achlich zu aktivieren. Dies widerspricht jedoch dem Ziel der leichten Erschließbarkeit, da die Benutzerin nun eine kombinierte Tastatur- und Mausaktion ausfuhren¨ muss. Auf Grund dieser Problematiken, habe ich mich gegen den Einsatz von Hot ” Corners“ entschieden.

Funktionsleiste Stattdessen schien es gerechtfertigt, etwas Bildschirmfl¨ache zu investieren und die Funktionen mit Hilfe einer Funktionsleiste sichtbar zu machen. Die GNOME Desk- topumgebung, von der angenommen wird, dass sie von der Benutzerin genutzt wird (siehe Abschnitt 3), bringt standardm¨aßig bereits zwei Funktionsleisten am oberen und unteren Rand des Bildschirms mit. Diese k¨onnen von der Benutzerin um zus¨atz- liche Applets erweitert werden. Da sehr viel Fl¨ache auf diesen Leisten bereits genutzt wird und das Hinzufugen¨ neuer Applets manuell durch die Benutzerin erfolgen muss, schien dies keine gute Option fur¨ BlueTiles Funktionsleiste zu sein. Anstelle dieser L¨osung, habe ich mich daher entschlossen, eine eigene Funktions- leiste einzufuhren.¨ Sie nutzt einen der freien R¨ander – standardm¨aßig den linken – und ist damit vertikal ausgerichtet. Um nicht zuviel Bildschirmfl¨ache zu verbrauchen, ist sie m¨oglichst schmal ausgelegt und alle Funktionen sind nur knapp beschriftet oder durch Symbole angedeutet. Fur¨ das Wechseln des Layout-Algorithmus konnten dementsprechend Symbole gew¨ahlt werden, die den Effekt des jeweiligen Algorith- muses andeuten. Ein zus¨atzlicher Vorteil der Umsetzung mit Hilfe einer Funktionsleiste besteht darin, dass sie – uber¨ die Layout-Algorithmen hinaus – Raum fur¨ weitere Funktionen bietet. So kann auch der Wechsel zu anderen virtuellen Desktops an dieser Stelle untergebracht werden, sowie einige weitere Funktionen, die noch nicht anderweitig uber¨ die Maus zug¨anglich gemacht worden sind. Die Funktionsleiste bietet zudem die M¨oglichkeit, eines besseren Umgangs mit einem Dual-Head-Setup. Wie angesprochen, zeigt jeder Bildschirm einen eigenen virtuellen Desktop. Sowohl die Wahl des Layout-Algorithmus, als auch der Wechsel zu einem anderen virtuellen Desktop kann somit unabh¨angig fur¨ jeden Bildschirm erfolgen. Um dies zu erm¨oglichen, startet BlueTile im Fall eines Dual-Head-Setups fur¨ jeden Bildschirm eine eigene Funktionsleiste (siehe Abbildung 21). Die Funktionen der Leiste sind durch die Symbole und kurzen Beschriftungen nur angedeutet. Die genaue Funktionalit¨at kann aber von der Benutzerin durch Ausprobieren erschlossen werden und wird in Tooltips genauer beschrieben (siehe

34 Abbildung 21: Dual-Head-Setup mit zwei Funktionsleisten

Abbildung 22). Wie im Abschnitt 8 beschrieben, gehe ich trotzdem den zus¨atz- lichen Schritt, zumindest den Wechsel des Layout-Algorithmus in einer eigenen Schnellstart-Anleitung“ zu erl¨autern. Auf diese Weise sollte die Benutzerin keine ” Schwierigkeiten haben, diese zentrale Funktion der Leiste zu verwenden.

Abbildung 22: Tooltip

10 Installation von BlueTile

Ein Windowmanager, der sich das Ziel gesetzt hat, ’out of the box’ verwendbar zu sein, sollte auch einfach zu installieren sein. BlueTile steht unter der selben Lizenz wie XMonad – BSD323 – und ist damit freie Software. Dies erm¨oglicht es Linux- Distributionen die Software als Teil ihres Paketsystems anzubieten. Man kann hoffen,

23http://www.opensource.org/licenses/bsd-license.php (5. August 2009)

35 dass dies auf lange Sicht gesehen zu einem problemlosen Installationsvorgang fuhrt.¨ Vorerst kann man jedoch nicht von dieser M¨oglichkeit Gebrauch machen und die Installation wird sich fur¨ die ersten Benutzer und Benutzerinnen etwas aufwendiger gestalten. Allerdings bringt die Haskell-Community einige Werkzeuge mit, die diesen Schritt erleichtern k¨onnen. Dazu geh¨ort zum einen die Software Cabal24, die auch von XMonad genutzt wird. Sie erm¨oglicht es fur¨ ein Haskell-Projekt anzugeben, wie es ubersetzt¨ wird und welche Abh¨angigkeiten zu weiteren Haskell-Bibliotheken exis- tieren. Wenn auf dem Zielsystem installiert ist, kann ein solches ’cabalized’ Haskell-Projekt sehr einfach installiert werden, da Cabal automatisch alle n¨otigen Abh¨angigkeiten mitinstalliert. Fur¨ BlueTile habe ich eine solche Cabal-Datei er- stellt, wobei ich darauf geachtet habe, dass keine Konflikte mit XMonad entstehen. Da BlueTile auf XMonad aufbaut, muss speziell darauf geachtet werden, dass Blue- Tile und XMonad problemlos auf dem selben System installiert werden k¨onnen. Dies erm¨oglicht es auch XMonad-Benutzern und -Benutzerinnen BlueTile gefahrlos auszuprobieren. Eine weitere Unterstutzung¨ durch die Haskell-Community wird in Form einer Infrastruktur unter der Bezeichnung HackageDB25 zur Verfugung¨ gestellt. Hierbei handelt es sich um eine online verfugbare¨ Sammlung von Haskell-Projekten und -Bibliotheken, die mit Cabal-Dateien ausgestattet sind. Wenn ein Projekt und seine Abh¨angigkeiten uber¨ HackageDB verfugbar¨ sind, kann Cabal die Software automa- tisch von dort herunterladen und installieren. Ich plane, BlueTile in seinem aktuellen Stand uber¨ HackageDB verfugbar¨ zu machen. Naturlich¨ besteht weiterhin die M¨oglichkeit, HackageDB nicht zu nutzen und direkt von einem Archiv mit dem Quellcode zu installieren oder eine Kopie des Darcs-Repositorys herunterzuladen und damit Zugriff auf den neusten Stand des Quellcodes zu haben. Beide M¨oglichkeiten werde ich uber¨ eine Projektwebseite zur Verfugung¨ stellen, die außerdem kurze Anleitungen fur¨ die verschiedenen Installati- onswege enthalten wird.

11 Fazit

Diese Arbeit entstand aus der Beobachtung, dass unter bestehenden Tiling Window Managern zwei Einstiegshurden¨ stark verbreitet sind: Zum Einen die Konzentration auf Minimalit¨at und das Baukastensystem, welches es fur¨ die Benutzerin erforderlich macht, erheblichen Zeitaufwand in die Konfiguration zu stecken. Zum Anderen die ausschließliche Bedienung durch Tastenkurzel,¨ welche der Benutzerin einigen Lern- aufwand abverlangt, bevor die Software uberhaupt¨ genutzt werden kann.

24http://www.haskell.org/cabal/ (5. August 2009) 25http://hackage.haskell.org/packages/hackage.html (5. August 2009)

36 Das Ziel, diese Einstiegshurden¨ zu vermeiden, war Grundlage der Designuberle-¨ gungen fur¨ BlueTile. Dies fuhrte¨ zum Einen zu der Entscheidung, einen Hybridan- satz in BlueTile zu verfolgen: Mit dem SWM-Modus ist es m¨oglich, stets zu einer klassischen Verwaltung der Fenster zu wechseln und damit der Benutzerin einen ver- trauten Ausgangspunkt zu bieten. Fur¨ Funktionen wie Fenster verschieben, Fens- tergr¨oße ¨andern, Minimieren und Maximieren wurden M¨oglichkeiten ausgearbeitet und implementiert, diese benutzerfreundlich zur Verfugung¨ zu stellen und eine Dock- Applikation wurde entwickelt, um weitere, zus¨atzliche Funktionalit¨at erschließbar zu machen. Das Resultat ist eine Software, in der s¨amtliche Funktionalit¨at, die vorher nur durch Tastenkurzel¨ erreichbar war, in irgendeiner Art und Weise durch die Maus verwendbar ist – in einer Form, die sich so weit wie m¨oglich an bekannten Konven- tionen aus klassischen Windowmanagern anlehnt. Benutzerfreundlichkeit ist ein sehr subjektiver Begriff. Ob BlueTiles Ziel in einer Form umgesetzt werden konnte, die einen tats¨achlichen Mehrwert fur¨ die t¨agliche Arbeit mit einem Windowmanager bietet, kann daher nur am tats¨achlichen Ausmaß der Akzeptanz durch Nutzerinnen und Nutzer bewertet werden. BlueTile ist daher bewusst unter einer Open-Source-Lizenz entwickelt worden, um eine leichte Verbrei- tung zu erm¨oglichen. Daruber¨ hinaus ist das Entwicklungsprinzip von Open Source gut geeignet, um solche neuen Ans¨atze im Design von Windowmanagern auszupro- bieren. Denn sollte BlueTile sein Ziel nicht erreichen k¨onnen, kann es zumindest als weiterer Baustein in der Weiterentwicklung von Tiling Window Managern dienen.

37 Literatur

[CR87] Carroll, John M. and Mary Beth Rosson: Paradox of the active user. In Carroll, John M. (editor): Interfacing thought: cognitive as- pects of human-computer interaction, Cambridge, MA, USA, 1987. MIT Press.

[KA08] Krisler, Brian and Richard Alterman: Training towards mastery: overcoming the active user paradox. In NordiCHI ’08: Proceedings of the 5th Nordic conference on Human-computer interaction, pages 239–248, New York, NY, USA, 2008. ACM.

[LNPS05] Lane, David M., H. Albert Napier, S. Camille Peres, and Aniko´ Sandor´ : Hidden costs of graphical user interfaces: Failure to make the transition from menus and icon toolbars to keyboard shortcuts. Interna- tional Journal of Human-Computer Interaction, 18(2):133–144, 2005.

[Nye93] Nye, Adrian: Xlib programming manual (3rd ed.). O’Reilly & Asso- ciates, Inc., Sebastopol, CA, USA, 1993.

[Rou09] Roundy, David: Darcs user manual, Mai 2009. http://darcs.net/ manual/, Zugriff am 5. August 2009.

[SS07] Stewart, Don and Spencer Sjanssen: Xmonad. In Haskell ’07: Proceedings of the ACM SIGPLAN workshop on Haskell workshop, pages 119–119, New York, NY, USA, 2007. ACM.

[Swa03] Swartz, Luke: Why people hate the paperclip: Labels, appearance, be- havior, and social responses to agents. Stanford University, 2003.

38 Abschließende Erkl¨arung

Ich versichere hiermit, dass ich mein Individuelles Projekt BlueTile – ein moderner ” Tiling Window Manager mit flacher Lernkurve“ selbst¨andig und ohne fremde Hilfe angefertigt habe, und dass ich alle von anderen Autoren und Autorinnen w¨ortlich ubernommenen¨ Stellen wie auch die sich an die Gedankeng¨ange anderer Autoren und Autorinnen eng anlehnenden Ausfuhrungen¨ meiner Arbeit besonders gekennzeichnet und die Quellen zitiert habe.

Oldenburg, den 29. August 2009 Jan Vornberger

39