BlueTile ein moderner Tiling Window Manager mit flacher Lernkurve

Transkript

1 BlueTile ein moderner Tiling Window Manager mit flacher Lernkurve Individuelles Projekt Abstract: Tiling Window Manager (TWMs) ordnen Fenster so an, dass sie sich nicht überlappen und die gesamte Bildschirmfläche genutzt wird. Unter bestehenden TWMs sind jedoch zwei Einstiegshürden verbreitet: Die Notwendigkeit, viel Konfiguration vorzunehmen, und die ausschließliche Bedienung durch Tastaturkürzel. Diese Arbeit beschreibt das Design und die Implementierung von BlueTile, einem Windowmanager, der versucht, das TWM-Paradigma leichter erschließbar zu machen, indem auf Konventionen aus klassischen, meist Maus-basierten Windowmanagern zurückgegriffen wird und der ohne Konfiguration verwendbar ist. Betreuerin: Zweitgutachter: Vorgelegt von: Dr. Elke Wilkeit Martin Hilscher Jan Vornberger Campus-Appartments Artillerieweg Oldenburg

2 Inhaltsverzeichnis 1 Motivation hinter BlueTile 3 2 Übersicht von Tiling Window Managern 4 3 Zielgruppe 7 4 XMonad Basis für BlueTile 8 5 Entwicklungsumgebung 11 6 Konfiguration 13 7 Erstes Starten 14 8 Hilfesystem 14 9 Funktionalitäten SWM-Modus Fensterdekoration Fenster verschieben Fenstergröße ändern Minimieren Maximieren Dock-Applikation Installation von BlueTile Fazit 36 2

3 1 Motivation hinter BlueTile In diesem einleitenden Abschnitt möchte ich kurz den Begriff des Tiling Window Managers (TWM) umreißen und ausführen, 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 Ausnutzen von vorhandener Bildschirmfläche angeht. Fenster überlappen sich und die Benutzerin ist viel damit beschäftigt, Applikationen von Interesse in den Vordergrund zu holen und neu anzuordnen. Tiling Window Manager verfolgen stattdessen den Ansatz, dass sich Fenster in der Regel nicht überlappen und die gesamte Bildschirmfläche unter ihnen aufgeteilt wird. Verschiedene Ansätze wurden entwickelt, wie diese Aufteilung erfolgen kann und die Benutzerin kann sie jeweils den Gegebenheiten anpassen. Wie im Abschnitt 2 noch ausgeführt 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 Einstiegshürden: 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 gewünschte Konfiguration selbst zusammenstellt. XMonad ist dafür ein Extrembeispiel (siehe auch Abschnitt 4) beim Starten mit der Standardkonfiguration bekommt die Benutzerin nichts als einen leeren Bildschirm zu sehen. Die zweite Einstiegshürde besteht darin, dass die meisten TWMs darauf ausgelegt sind, mit einer Vielzahl an Tastenkürzeln bedient zu werden. Da sich das Tiling Window Paradigma im Vergleich zum Stacking Window Paradigma wesentlich besser für ein Tastatur-basiertes Arbeiten eignet, stellt dies natürlich auch einen wesentlichen Vorteil von TWMs dar. Es führt aber auch dazu, dass die Bedienung erst möglich wird, nachdem eine erhebliche Einarbeitungszeit geleistet worden ist. Insbesondere für eine Benutzerin, die nur einmal in die Welt von TWMs hineinschauen möchte, ergibt sich somit ein erheblicher Zeitaufwand. Zum Einen muss sie eine Konfiguration zusammenstellen zusätzlich erschwert dadurch, dass sie schließlich zu diesem Zeitpunkt noch gar nicht weiß, worauf es bei einer Konfiguration für TWMs ankommt und zum Anderen so viele Tastenkürzel gut genug lernen, um abschätzen zu können, ob TWMs für ihren Arbeitsstil nützlich sein können. Diese Einstiegshürde möchte BlueTile abbauen und daraus ergeben sich die folgenden drei Ziele: BlueTile möchte ohne Konfiguration out of the box verwendbar sein. 3

4 Die Standardkonfiguration von BlueTile soll derart gestaltet sein, dass sie für die meisten Situationen völlig ausreichend ist und zumindest zu Beginn in der Regel keine Anpassung erfordert. Der Abschnitt 6 führt weitere Gedanken zu diesem Punkt aus. BlueTile soll mit wenig Aufwand zu bedienen sein. Dies bedeutet, Funktionalität auf leicht erschließbare Art und Weise verfügbar zu machen und Konventionen, die die Benutzerin aus klassischen, meist Mausbasierten, Windowmanagern gewöhnt ist, auf das TWM-Paradigma anzupassen. Die Designentscheidungen, die aus dieser Grundlage resultieren, wirken sich auf alle Funktionen von BlueTile aus (siehe Abschnitt 9). BlueTile bietet Tastenkürzel für sämtliche Funktionalität. Da wie bereits erwähnt Tastenkürzel ein wichtiger Bestandteil vieler TWMs sind, möchte BlueTile diese Tradition weiterführen und dafür sorgen, dass für fortgeschrittene Benutzer und Benutzerinnen sämtliche Funktionalität weiterhin auch durch Tastenkürzel aufrufbar ist. 2 Übersicht von Tiling Window Managern Abbildung 1: TwoUp Tiling Window Manager sind hauptsächlich in freien Betriebsystemen wie z.b. Linux vertreten. Microsoft Windows und Mac OS bieten keine einfache Möglichkeit, die Komponente, die die Verwaltung von Fenstern ausführt, durch Alternativen zu 4

5 ersetzen. Dementsprechend kann Software, die solche Funktionalität unter diesen Betriebsystemen bereitstellen möchte, nur eine aufgesetzte Umsetzung bieten. Diese beschränkt sich meistens darauf, Fenster nur auf Anfrage der Benutzerin gekachelt anzuordnen, dann diese Anordnung jedoch nicht weiter aufrecht zu erhalten. Das Öffnen neuer Fenster oder das Verschieben und Ändern der Größe von Fenstern führt dann wieder zu Überlappung, bis die Benutzerin erneut Kommandos zum Kacheln der Fenster ausführt. Beispiele für solche Software sind WinSplit Revolution 1 für Microsoft Windows und TwoUp 2 für Mac OS (siehe Abbildung 1). Unter Linux hingegen ist es kein Problem, verschiedene Windowmanager zu nutzen und eine komplette Integration zu erzielen. Daher ist es keine Überraschung, dass für 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 unterteilen: Statische und dynamische TWMs. Die statischen TWMs arbeiten nach dem Konzept, dass die Benutzerin eine Aufteilung des Bildschirms in verschiedene Teilbereiche manuell vornimmt und diese unabhängig von tatsächlich offenen Fenstern bestehen bleiben. Ein neues Fenster wird dann einem der bestehenden Teilbereiche zugeordnet und nimmt die entsprechende Größe an. In TWMs dieser Art wird also nicht zwangsläufig die gesamte Bildschirmfläche genutzt, da Teilbereiche auch unbelegt bleiben können (siehe Abbildung 2). Vertreter dieser Kategorie sind beispielsweise Ion 3, Ratpoison 4 und StumpWM 5. Demgegenüber passen dynamische TWMs das Layout der aktuellen Anzahl offener Fenster an. Ein manuelles Einteilen der Bildschirmfläche ist nicht nötig, das Öffnen eines neuen Fensters führt 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äglich anpassen oder komplett zu einem anderen Layout-Algorithmus wechseln. Wenn der Windowmanager virtuelle Desktops unterstützt wie es unter Linux die Regel ist kann der Layout-Algorithmus in vielen Fällen für 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ählt die Anordnung so, dass dieses Fenster die meiste Fläche zugewiesen bekommt (siehe Abbildung 3). 1 (16. August 2009) 2 (Quelle des Screenshots, 16. August 2009) 3 (16. August 2009) 4 (16. August 2009) 5 (16. August 2009) 5

6 Abbildung 2: StumpWM mit ungenutztem Bereich Die TWMs wmii 6, XMonad 7 und awesome 8 sind Beispiele für dynamische TWMs. Was alle der genannten Beispiele für TWMs gemein haben, ist ein grundsätzliches Bestreben nach Minimalität 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önlichen 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 programming language. [... ] We provide an easily usable and very-well documented API to configure and define the behaviour of your window manager (17. August 2009) 7 (17. August 2009) 8 (17. August 2009) 9 (17. August 2009) 10 (17. August 2009) 6

7 Abbildung 3: Awesome mit Masterfenster auf der linken Seite Wie im Abschnitt 1 ausgeführt, halte ich diese Ansätze für eine Quelle von großen Einstiegshürden und sehe daher das Potential für 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önnen, habe ich grob eine Zielgruppe festgelegt: Meine Annahme ist, dass die typische Benutzerin von BlueTile jemand ist, die einen Tiling Window Manager ausprobieren möchte, um herauszufinden, ob ein TWM für ihre Arbeitsweise von Nutzen sein kann. Sie möchte dafür 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 Metacity verwendet. Grundsätzlich funktioniert BlueTile auch in Kombination mit KDE oder ganz unabhängig von einer Desktopumgebung. Eine Desktopumgebung anzunehmen, hat jedoch den Vorteil, dass auf viele 7

8 unterstützende Komponenten zurückgegriffen werden kann. Die wichtigste davon ist die Taskleiste, welche die offenen Fenster aufführt und Zugriff auf sie bietet. In Abbildung 4 ist zu sehen, welche Komponenten alleine durch die Desktopumgebung GNOME bereitgestellt werden, da hier vorübergehend Metacity deaktiviert wurde. Die konkrete Kombination GNOME & Metacity anzunehmen, ermöglicht eine wesentlich bessere Integration, wie in Abschnitt 6 noch deutlich wird. Abbildung 4: GNOME ohne Metacity 4 XMonad Basis für BlueTile Für die Entwicklung von BlueTile stellten sich mehrere Möglichkeiten. Zum Einen hätte ich einen komplett neuen Windowmanager von Grund auf schreiben können. Da mein Fokus aber auf der einfachen Benutzbarkeit von bestehender Funktionalität lag und nicht auf der Entwicklung von komplett neuer Funktionalität, lag es nahe, bei diesem Vorhaben auf einer bestehenden Software aufzubauen. Es gab nun die Möglichkeiten, entweder einen klassischen Windowmanager um TWM-Funktionalität zu erweitern oder einen TWM so zu verändern, dass er einem klassischen Windowmanager ähnlicher ist, um vorhandene Kenntnisse der Benutzerin ausnutzen zu können. 8

9 Da mein Ziel mit BlueTile darin besteht, das Tiling Window Paradigma leichter zugänglich zu machen, war es für mich wichtig, so viel Funktionalität wie möglich aus diesem Bereich beizubehalten. Um diese Vorgabe leichter einhalten zu können, habe ich mich daher entschieden, meine Implementierung auf einem bestehenden TWM zu basieren. Da ich persönlich 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 Entwicklersicht eine gute Wahl wäre, haben schnell gezeigt, dass eine Reihe von Fakten für XMonad sprechen: XMonad ist in Haskell geschrieben, einer Sprache, die dafür bekannt ist, sehr kompakten Code zu produzieren. Im Vergleich zu anderen Windowmanagern hat XMonad daher auch eine sehr übersichtliche 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 Übersicht über die Architektur des Kerns zu erarbeiten. Zudem hat das XMonad-Team sehr strikte Regeln festgesetzt, was die Dokumentation 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, über 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ächlicher Windowmanager ist, als mehr ein Baukastensystem für einen individuell zusammengestellten Windowmanager. Bei der Erstellung der Konfiguration schreibt die Anwenderin im Prinzip das Hauptprogramm dieses Windowmanagers, in dem sie die gewünschten Module kombiniert (siehe Abbildung 5). Dies ermöglicht eine extreme Flexibilität bei der Konfiguration, da beliebiger Haskell-Code integriert werden kann. Auf der anderen Seite ist es ein Beispiel für eine große Einstiegshürde. Selbst wenn man auch ohne Haskell-Kenntnisse bis zu einem gewissen Grad eine bestehende Konfiguration anpassen kann, können doch die unvertrauten Fehlermeldungen des Haskell-Compilers sehr frustrierend für eine Einsteigerin sein. Zudem braucht man nun nur für die Konfiguration des Windowmanagers einen Haskell-Compiler aus Sicht einer Anwenderin eine zusätzliche Installation von recht umfangreicher Software. Wie in Abschnitt 6 genauer ausgeführt, habe ich daher diese Art der Konfiguration für BlueTile nicht übernommen. Ich habe jedoch das zu Grunde liegende Baukastensystem genutzt, um die Standardkonfiguration von BlueTile damit zu erstellen. 9

10 1 import XMonad 2 import XMonad. Hooks. DynamicLog 3 import XMonad. Hooks. ManageDocks 4 import XMonad. U t i l. Run( spawnpipe ) 5 import XMonad. U t i l. EZConfig ( additionalkeys ) 6 import System. IO 7 8 mymanagehook = composeall 9 [ classname =? Gimp > dofloat 10, classname =? Vncviewer > dofloat 11 ] main = do 14 xmproc < spawnpipe 15 / path / to / xmobarbinary / path / to /. xmobarrc 16 xmonad $ d e f a u l t C o n f i g 17 make sure to i n c l u d e mymanagehook 18 d e f i n i t i o n from above 19 { managehook = managedocks <+> mymanagehook 20 <+> managehook d e f a u l t C o n f i g 21, layouthook = a v o i d S t r u t s $ 22 layouthook d e f a u l t C o n f i g 23, loghook = dynamiclogwithpp $ xmobarpp 24 { ppoutput = hputstrln xmproc 25, pptitle = xmobarcolor green 26. shorten } 28 Rebind Mod t o t h e Windows key 29, modmask = mod4mask 30 } additionalkeys 31 [ ( ( mod4mask.. shiftmask, xk z ), 32 spawn xscreensaver command l o c k ) 33, ( ( controlmask, xk Print ), 34 spawn s l e e p 0. 2 ; s c r o t s ) 35, ( ( 0, xk Print ), spawn s c r o t ) 36 ] Abbildung 5: Beispiel einer XMonad-Konfiguration (Quelle: XMonad Wiki) 10

11 5 Entwicklungsumgebung Wie viele andere Haskell-Projekte auch, verwendet XMonad für die Versionskontrolle die Software Darcs 11. Da ich auf XMonad aufbaue, lag es nahe, dass ich auch Darcs nutzen würde. Insbesondere unter dem Aspekt, dass ich vielleicht zukünftige Entwicklungen oder Fehlerbehebungen im XMonad-Projekt auch in BlueTile übernehmen wollen würde und umgekehrt sicherlich auch einige meiner Erweiterungen für das XMonad-Projekt nützlich sein können, war es sinnvoll, Darcs beizubehalten. Ich hatte bisher für meine Projekte im Wesentlichen nur Subversion im Einsatz und darüber hinaus nur ein wenig Erfahrung mit Git 12 und Mercurial 13 durch kurzes Ausprobieren gesammelt. Für den tatsächlichen 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 Darcs einarbeiten, allerdings hat es etwas länger gedauert, bis ich einen Arbeitsfluss finden konnte, der die Möglichkeiten von Darcs sinnvoll ausnutzt. Darcs hat keine zeitliche Abfolge von Patches. Ein Repository besteht aus einer Sammlung von Patches, von denen einige komplett unabhängig sein können und andere voneinander abhängen, weil beispielsweise die entsprechenden Änderungen aufeinander aufbauen. Dies ermöglicht ein beliebiges Zusammenstellen von ausgewählten Patches, so lange alle Abhängigkeiten erfüllt sind. Ich habe es daher schließlich so gemacht, dass ich für jede neue Funktionalität, die ich implementieren wollte, eine komplette Kopie des Repositorys erstellt habe und dort die Funktionalität entwickelt und committet habe. Wenn alles funktioniert hat, habe ich dann die entsprechenden Patches wieder in das Hauptrepository herüberkopiert. Auf diese Weise war es leicht möglich, an verschiedenen Aspekten parallel zu arbeiten und Fehlentwicklungen zu verwerfen, ohne dass sie anderen Code beeinträchtigt hätten. Auch das Verfolgen und Integrieren von Entwicklungen im XMonad-Projekt war dadurch sehr problemlos, da natürlich einfach die entsprechenden Patches hinzugefügt werden konnten. Für die eigentliche Softwareentwicklung in Haskell habe ich den Texteditor VIM 14 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 Unterstützung für Haskell in Entwicklungsumgebungen wie Eclipse 15 noch in den Anfängen steckt. Dagegen sind entsprechende Unterstützungen in mächtigen Texteditoren wie Emacs oder VIM in der Regel schneller verfügbar. In der Tat gibt es 11 (5. August 2009) 12 (5. August 2009) 13 (5. August 2009) 14 (5. August 2009) 15 (5. August 2009) 11

12 für VIM einen eigenen Haskell-Modus 16, der sich bei der Entwicklung als hilfreiche Unterstützung herausgestellt hat. Er ermöglicht Dinge wie das automatische Compilieren 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 für Haskell-Projekte in der Regel mit Haddock 17 erstellt, welches übersichtliche HTML-Seiten generiert und meiner Erfahrung nach bei der Haskellprogrammierung eine exzellente und unverzichtbare Unterstützung darstellt. Die Programmiersprache Haskell kann mit ihrem kompromisslosen Ansatz und der rein funktionalen Natur teilweise eine sehr frustrierende Sprache sein. Meine Erfahrung war aber, dass diese eingeforderte Disziplin oft zu besseren Lösungen geführt 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 verhindert, was in der Regel zu sehr stabilem Code führt. Dies zeigte sich auch darin, dass BlueTile zu jedem Zeitpunkt der Entwicklung komplett und ohne Abstürze verwendbar war. Haskell ermöglichte es darüber hinaus, sehr kompakten Code zu schreiben, was es leichter macht, die Übersicht zu behalten. Auch Umstrukturierungen von Code sind dadurch weniger aufwendig. Nachteilig wirkt sich aus, dass Haskell keine sehr verbreitete Sprache ist. Dies zeigt sich in Angebot und Qualität von Hilfsbibliotheken. So lange man keine allzu exotischen 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örte, die mit dieser Bibliothek eine Dock-Applikation schreiben wollten (siehe Abschnitt 9.7). Dafür benötigte GTK-Funktionen wurden nämlich noch nicht durch die Bibliothek zur Verfügung gestellt und ich musste unter Verwendung von C-Code und dem Foreign Function Interface von Haskell 18 direkt auf die entsprechenden Funktionen zugreifen. Dies wäre sicher in einer stärker verbreiteten Sprache mit ausgereifteren Bibliotheken nicht nötig 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 Lerninvestition lohnt, da ich die Programmierung in Haskell als sehr angenehm erfunden habe und sehr viel Vertrauen in die Qualität der Ergebnisse gewinnen konnte (5. August 2009) 17 (5. August 2009) 18 (6. August 2009) 12

13 6 Konfiguration Ein erklärtes Ziel von BlueTile ist die Verwendbarkeit out of the box, also ohne dass es nötig ist, die Konfiguration anzupassen. Wie bereits erwähnt, stellt die Konfiguration eine erhebliche Einstiegshürde dar, da die Benutzerin natürlich noch nicht mit den verschiedenen Möglichkeiten vertraut ist. Im Fall von XMonad verwenden wahrscheinlich die wenigsten Benutzer und Benutzerinnen die minimale Standardkonfiguration, jedoch gibt es keine empfohlene Konfiguration, sondern nur eine riesige Sammlung von Möglichkeiten 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önnen, habe ich eine Zusammenstellung von XMonad-Modulen vorgenommen, die verbreitete Zusätze und Funktionalität enthält. Zudem habe ich die Gelegenheit genutzt, von der Alt-Taste zur Windows-Taste für alle Tastenkürzel zu wechseln. Dieser Modifier key ist in XMonad frei konfigurierbar und fast alle Tastenkürzel beinhalten diese Taste. Sie ist für maximale Kompatibilität mit verschiedenen Tastaturen standardmäßig mit der Alt-Taste belegt. Dies ist jedoch keine sehr praktikable Wahl, da viele andere Applikationen mit Tastenkürzeln arbeiten, die Alt beinhalten. Daher ändern 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ätsprobleme mit einigen exotischen Tastaturlayouts zu riskieren. Einige wenige von mir hinzugefügten Tastenkürzel beinhalten nicht die Windows- Taste. Grundsätzlich halte ich es für sinnvoll, sich auf möglichst wenig Modifier keys zu beschränken, um die bereits angesprochenen Konflikte mit anderen Applikationen zu minimieren. Für einige Tastenkürzel habe ich jedoch eine Ausnahme gemacht, da es sich hierbei um Metacity-Tastenkürzel für häufig verwendete Aktionen wie dem Wechsel des virtuellen Desktops handelt. Da BlueTile als Metacity-Ersatz konzipiert ist, scheint es mir nützlich, einige vertraute Tastenkürzel zu übernehmen. 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ält, sobald sich die Maus nur darüber hinwegbewegt. Es ist also nicht nötig 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 für viele Benutzer und Benutzerinnen ausreichend sein kann, wird es immer die Notwendigkeit geben, die Konfiguration anpassen zu können. Wie in Abschnitt 4 schon erwähnt, habe ich XMonads Strategie der Konfiguration in Haskell selbst nicht übernommen. Zwar ist es ein mächtiges System, bringt jedoch für BlueTiles Zielgruppe zuviel Komplexität und zusätzli- 13

14 che Schwierigkeiten mit sich. Daher sollte es für zukünftige Versionen von BlueTile ein wichtiges Ziel sein, eine einfachere Konfigurationsmöglichkeit 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önnte sein, dass die Benutzerin ihren aktuellen Windowmanager verwendet und nun BlueTile ausprobieren möchte (siehe Abschnitt 3). Dazu sollte es nicht nötig sein, die aktuelle Sitzung zu beenden und sich neu einzuloggen oder irgendwelche Konfigurationsdateien zu editieren. Viele Windowmanager (z.b. XFWM4, Compiz und Metacity) besitzen die Möglichkeit, einen bestehenden Windowmanager im laufenden Betrieb zu ersetzen. Teilweise muss dies explizit durch eine Option wie --replace angefordert werden. XMonad besaß solch eine Funktionalität noch nicht, daher habe ich sie entsprechend den Angaben im Xlib Manual [Nye93] und meinen Anforderungen implementiert. Ich habe mich dafür entschieden, diese Funktionalität grundsätzlich aktiv zu haben und es nicht nötig 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öglicht diese Entscheidung das Starten von BlueTile ohne jegliche Parameter, also insbesondere auch durch ein Icon oder einen Menüeintrag, wie er eventuell nach einer Installation durch einen Paketmanager vorhanden wäre. 8 Hilfesystem BlueTile versucht Funktionalität auf leicht erschließbare Art und Weise zur Verfügung zu stellen und dies bedeutet oft den Einsatz der Maus, da viele Benutzer und Benutzerinnen einen solchen Ansatz aus anderen Windowmanagern gewöhnt sind. Ein wesentlicher Vorteil von Tiling Window Managern besteht aber darin, dass sich dieses Paradigma im Vergleich zu Stacking Window Managern wesentlich besser für ein Tastatur-basiertes Arbeiten eignet. Viele Arbeitsabläufe lassen sich durch Tastenkürzel sehr effizient ausführen [LNPS05, S. 140]. Es wäre daher wünschenswert, die Benutzerin an solche Tastenkürzel heranzuführen. Es stellt sich somit die Frage, auf welche Weise dies am besten erzielt werden kann. Grundsätzlich 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 auszuführen gelernt hat 14

15 diesen Weg beizubehalten, auch wenn sie weiß, dass es vermutlich effizientere Möglichkeiten gibt, die gleiche Operation auszuführen [KA08, S. 239]. Ein Windowmanager, der zum Einstieg leicht erschließbare Bedienungsmöglichkeiten bietet und später Tastaturkürzel vermitteln möchte, ist mit dieser Schwierigkeit konfrontiert. Im Folgenden sollen einige Möglichkeiten zur Lösung diskutiert werden. Eine begleitende Dokumentation kann und sollte vorhandene Tastenkürzel aufführen und detailliert beschreiben. Allerdings wird diese von vielen Benutzern und Benutzerinnen nicht gelesen [CR87, S. 2]. Viele Anwendungen gehen daher andere, zusätzliche Wege, um die Benutzerin zu informieren. Ein verbreiteter Ansatz ist das Anzeigen eines Tipp des Tages beim Starten der Anwendung. In anderen Situationen werden Informationen, die für den aktuellen Kontext relevant sind, kurzzeitig eingeblendet. Ein Beispiel dafür stellt das YouTube 19 -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 für einen Windowmanager zu aufdringlich zu sein: Der vorherige, klassische Windowmanager der Benutzerin ließ sich vermutlich ohne Dokumentation bedienen. Daher wird die Benutzerin sicherlich wenig Verständnis dafür haben, dass BlueTile sie bei jedem Starten belehren möchte. Eine kurzzeitige Einblendung hat den Nachteil, dass sie zwangsläufig die Aufmerksamkeit auf sich zieht. Sie ist somit schwer zu ignorieren, selbst wenn die einzige Reaktion darin besteht, zu erkennen, dass die Meldung im Moment nicht von Interesse ist. Ein weiteres, sehr bekanntes Beispiel für kontext-bezogene Hilfe, stellt die Büroklammer dar, ein Assistent, welcher Bestandteil einiger Versionen von Microsoft Word war. Sie ist gleichzeitig ein Beispiel dafür, welche Problematik solche Hilfesysteme mit sich bringen, denn die Büroklammer wurde von vielen Benutzern und Benutzerinnen als störend empfunden: In der Studie [Swa03] wurde die Büroklammer 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ätzlich nicht ungefragt belehrt werden möchten oder ob diese konkrete Implementation eines Hilfesystems einfach nur ungeschickt und zu aufdringlich war. Auf der Suche nach einem Mittelweg zwischen unbeachteter Dokumentation und aufdringlicher Büroklammer, scheint mir die beste Option darin zu bestehen, ein schmales Fenster ausschließlich für Meldungen vom Hilfesystem zu reservieren. Kurzzeitige Einblendungen würden zwar dauerhaft weniger Bildschirmfläche in Anspruch nehmen, sie sind aber wie bereits erwähnt von der Benutzerin schwer zu ignorieren. Ein speziell dafür vorgesehener Bereich vergleichbar mit der Statuszeile eines 19 (5. August 2009) 15

16 Browsers kann leichter von der Benutzerin ignoriert werden, wenn sie im Moment keine zusätzlichen Informationen erhalten möchte. Wenn die Benutzerin Aktionen mit der Maus ausführt, könnte diese Hilfesystemstatuszeile dann dafür genutzt werden, um die entsprechenden Tastenkürzel einzublenden. Dies hat gleichzeitig den Vorteil, dass es eine sehr kontext-bezogene Hilfestellung darstellt. Ein umfassendes Hilfesystem in dieser Form konnte im Rahmen des Individuellen Projekts leider nicht mehr implementiert werden und muss zukünftigen Versionen von BlueTile vorbehalten bleiben. Implementieren konnte ich allerdings ein minimales Hilfesystem, welches sich darauf beschränkt, eine einzelne Schnellstart- Anleitung beim allerersten Starten der Software einzublenden (siehe Abbildung 6). Sie vermittelt die Kernfunktionalität von BlueTile, indem sie die Benutzerin anleitet, einige Fenster zu öffnen und erklärt, wie diese gekachelt werden können. Zudem wird auf weitere Dokumentation verwiesen. Die Benutzerin kann dann dafür sorgen, dass diese Anleitung zukünftig nicht mehr eingeblendet wird. Abbildung 6: Schnellstart-Anleitung 9 Funktionalitäten Bevor ich die wesentlichen Funktionen von BlueTile im Detail diskutiere, möchte ich an diese Stelle kurz die grundsätzlichen Designüberlegungen darlegen. Diese 16

17 folgen den zwei Leitsätzen Bekanntes wiederverwenden und Neues erschließbar machen. Wo immer es möglich ist, Bekanntes wiederzuverwenden, möchte ich diese Gelegenheit nutzen, um auf Erfahrungen der Benutzerin mit traditionellen WMs zurück- zugreifen. Dies kann überall dort erfolgen, wo sich die Funktionalität von traditionellen WMs und BlueTile gleicht oder zumindest ähnelt. Der Vorgang des Verschiebens von Fenstern ist ein Kandidat dafür (siehe Abschnitt 9.3). Auch wenn in einer gekachelten Ansicht das Verschieben von Fenstern eingeschränkt ist, kann die Funktion trotzdem in bekannter Weise aufgerufen werden in diesem Fall über 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äsentieren, die es im Idealfall möglich macht, die neue Funktionalität intuitiv zu nutzen, ohne weitere Dokumentation zu benötigen. In diese Kategorie fällt 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 Funktionen haben. Auf diese Weise kann ich mich in späteren Abschnitten leichter darauf beziehen und es wird klar, wie die Funktionen zusammenspielen. Dies gilt inbesondere für 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öglichen es, zwischen verschiedenen Arten zu wechseln, wie die vorhanden Fenster angeordnet werden. Dieser Mechanismus ist so flexibel, dass er theoretisch auch das klassische Paradigma von frei positionierten, sich überlappenden Fenstern nachstellen kann. Ich habe diese Möglichkeit genutzt, um einen solchen Layout-Algorithmus im folgenden als SWM-Modus bezeichnet zu implementieren 20 (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äsentiert werden und sie wird dann dazu angeleitet, zu anderen Layout-Algorithmen zu wechseln, die dann tatsächlich eine gekachelte Ansicht zeigen. Dies erfolgt unter Nutzung des Hilfesystems, wie in Abschnitt 8 diskutiert. Der SWM-Modus bleibt jederzeit verfügbar und die Benutzerin kann zu ihm zurückwechseln, wenn sie beispielsweise einen bestimmten Arbeitsablauf lieber in einer gewohnten Umgebung durchführen möchte. 20 Man könnte argumentieren, dass BlueTile damit kein TWM mehr ist, sondern eher einen Hybrid- WM darstellt. Da ich aber die TWM-Funktionalität von BlueTile als den wesentlichen Aspekt betrachte, bezeichne ich ihn weiterhin als solchen. 17

18 Da der SWM-Modus nur einen speziellen Layout-Algorithmus darstellt, bleiben alle Funktionen, die vom Layout-Algorithmus unabhängig sind, in einer einheitlichen Form erhalten. Dies gilt beispielsweise für das Minimieren und Maximieren von Fenstern (siehe Abschnitt 9.5 bzw. 9.6). Abbildung 7: SWM-Modus An dieser Stelle sollte erwähnt werden, dass XMonad bereits eine ähnliche Funktionalität enthält, die jedoch auf andere Weise umgesetzt wurde. Die Erfahrung hat gezeigt, dass einige Applikationen insbesondere solche mit vielen kleinen Fenstern 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ätzliche Schicht über 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öße verändert werden. Für den darunter liegenden Layout-Algorithmus existiert das Fenster nun nicht mehr und die restlichen Fenster werden entsprechend neu angeordnet. Dies stellt meiner Ansicht nach bereits das größte Problem mit diesem Ansatz dar. Da der darunter liegende Layout-Algorithmus, auf Grund der Kachelung der Fenster, sämtlichen verfügbaren Platz ausnutzt, überdecken die Fenster im Floating Layer zwangsläufig irgendwelche Fenster in der unteren Schicht. Da der Ein- 18

19 satz des Floating Layers daher meistens nur sinnvoll ist, wenn die unterliegende Schicht keine Fenster enthält, scheint es mir sinnvoller, diesen gleich als eigenen Layout-Algorithmus umzusetzen. Zudem erfolgt das Positionieren und Verändern der Größe von Fenstern im Floating Layer von XMonad durch eine sehr ungewohnte Kombination von Tastenkürzeln und Mauskommandos. In einem eigenen Layout- Algorithmus, lassen sich diese Aspekte leichter an gewohnte Konventionen anpassen. Verloren geht bei diesem Ansatz nur die Möglichkeit, schwebende Fenster und gekachelte Fenster gleichzeitig sichtbar zu haben. Dies stellt meiner Ansicht nach keine große Einschränkung dar, mit der wichtigen Ausnahme von kurzlebigen Fenstern 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 einzufügen, noch für so kurze Zeit in den SWM-Modus zu wechseln. Daher ist der Floating Layer in BlueTile nicht komplett verbannt, sondern er wird ausschließlich für solche Dialogboxen verwendet 21 und es existiert keine direkte Möglichkeit, 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äre 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 zurückgewechselt hat. Ich habe mich jedoch aus mehreren Gründen gegen eine solche Interaktion entschieden. 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 weiteren Layout-Algorithmus handelt auch nicht von den anderen Layout-Algorithmen beeinflusst wird. Zum Anderen würde sich eine etwaige Interaktion vermutlich für die Benutzerin als recht undurchsichtig darstellen. Denn eine beliebige Anordnung einer gekachelten Ansicht lässt sich natürlich 1-zu-1 in den SWM-Modus übertragen, aber umgekehrt besitzt der SWM-Modus so wenig Einschränkungen, dass eine Übertragung des aktuellen Zustands in eine gekachelte Ansicht in der Regel nicht ohne Weiteres durchzuführen ist. Der Versuch einer solchen Übertragung würde daher vermutlich nur eine Quelle für Verwirrung der Benutzerin darstellen. Es scheint mir daher besser, wenn die Fensteranordnung des SWM-Modus komplett unabhängig vom Rest ist. Dazu ist es sinnvoll, für sämtliche Fenster vorzuhalten, welche Position und Größe sie im SWM-Modus zuletzt hatten. Dadurch lässt 21 Dialogboxen tragen spezielle Auszeichnungen, die es dem Windowmanager ermöglichen sie als solche zu erkennen und falls nötig speziell zu behandeln. 19

20 sich jederzeit die entsprechende Fensteranordnung wiederherstellen. Beim Öffnen eines neuen Fensters, kündigt dieses dem Windowmanager an, welche Position und Größe es bevorzugt. Diese Informationen können direkt gespeichert werden, selbst wenn das Fenster im TWM-Modus geöffnet und unmittelbar gekachelt wird. Die Informationen kommen erst zum Einsatz, wenn später in den SWM-Modus gewechselt wird. Diese Funktionalität ermöglicht ein nützliches Anwendungsszenario: Die Benutzerin befindet sich im TWM-Modus und öffnet eine Applikation mit vielen kleinen Fenstern und Dialogen. Der aktuell aktive Layout-Algorithmus kachelt sämtliche Fenster, aber die Benutzerin entscheidet, dass es für 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 würde. Die Information über Fensterposition und -größe im SWM-Modus stets vorzuhalten ist außerdem nützlich, wenn ein Fenster auf einen anderen virtuellen Desktop verschoben wird. Eventuell befindet sich der Zieldesktop im TWM-Modus und dadurch wird das verschobene Fenster sofort gekachelt. Wird später auf diesem virtuellen Desktop in den SWM-Modus gewechselt, muss weiterhin bekannt sein, wie das Fenster nun positioniert werden soll. Berücksichtigung von Dual-Head-Systemen XMonad und damit auch BlueTile besitzt eine sehr gute, wenn auch ungewöhnliche Unterstützung für Dual-Head-Systeme sprich die gleichzeitige Nutzung von zwei Bildschirmen. Typischerweise betrachten Windowmanager zusätzliche Bildschirme einfach als eine Vergrößerung der Desktopfläche. Wenn die Benutzerin dann auf einen anderen virtuellen Desktop wechselt, zeigen beide Bildschirme den neuen virtuellen Desktop. XMonad setzt stattdessen das Konzept um, dass eine Reihe von virtuellen Desktops existiert und jeder Bildschirm unabhängig vom anderen stets einen virtuellen Desktop komplett anzeigt. In einem Dual-Head-Setup können dementsprechend stets zwei der virtuellen Desktops für die aktuelle Anzeige ausgewählt werden und sämtliche Kombinationen sind möglich. Aus diesem ungewöhnlichen Konzept ergeben sich Konsequenzen für den SWM- Modus. Fenster befinden sich stets auf genau einem virtuellen Desktop 22. Ein virtueller Desktop kann jedoch zu verschiedenen Zeiten auf verschiedenen Bildschirmen sichtbar sein. Das System muss also berücksichtigen, dass Fensterpositionen nicht absolut zur gesamten Desktopfläche gelten, sondern relativ zum zugehörigen Bildschirm. Hinzu kommt, dass die Benutzerin bei einem Dual-Head-Setup die Möglichkeit hat, ein Fenster per Drag & Drop von einem Bildschirm auf den anderen zu ziehen 22 Die Möglichkeit ein Fenster auf allen virtuellen Desktops sichtbar zu machen, existiert zur Zeit in XMonad nicht. 20

21 und damit von einem virtuellen Desktop auf einen anderen. Da auf dem Zieldesktop unter Umständen ein anderer Layout-Algorithmus aktiv ist, kann dies dazu führen, dass ein gekacheltes Fenster in den SWM-Modus übergeht oder umgekehrt. Aus Sicht der Benutzerin unterscheiden sich diese verschiedenen Fälle nicht groß, aber das System muss alle Kombinationen korrekt behandeln. Darüberhinaus ist es möglich, dass die beiden Bildschirme mit unterschiedlichen Auflösungen arbeiten. Wenn nun ein virtueller Desktop vom Bildschirm mit der größeren Auflösung zu dem mit der kleineren wechselt, können die Fenster nicht mehr komplett dargestellt werden. Im TWM-Modus löst der aktive Layout-Algorithmus dieses Problem, in dem die Fenster entsprechend der veränderten Auflösung neu angeordnet werden. Um einen ähnlichen Effekt im SWM-Modus zu erzielen, habe ich auch hier eine automatische Größenänderung implementiert. Beim Wechsel von einer Auflösung zu einer anderen, werden sämtliche Fenster in ihrer Größe und Position proportional zur Veränderung angepasst (siehe Abbildungen 8 und 9). Abbildung 8: Der linke Monitor zeigt den virtuellen Desktop 5, der rechte den virtuellen Desktop 3 Abbildung 9: Die Position der zwei virtuellen Desktops wurde getauscht die Fenster passen sich entsprechend an 21

22 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öglicht es, eine Reihe von Funktionen für das entsprechende Fenster mit der Maus zu aktivieren. Dazu zählt das Ändern der Größe des Fensters, das Verschieben des Fensters, sowie weitere Funktionen, die über Symbole am linken und rechten Rand der Titelleiste aufrufbar sind. Dazu gehören in der Regel das Minimieren, Maximieren und Schließen des Fensters, sowie der Aufruf eines Fenstermenüs, welches sämtliche auch weniger genutze Funktionen für das Fenster enthält (siehe Abbildung 10 für ein Beispiel). Abbildung 10: Fensterdekoration und -Menü in Metacity Viele TWMs bieten nur eine sehr minimale oder überhaupt keine Fensterdekoration an. Da der Fokus auf der Nutzung durch die Tastatur liegt, ist die Fensterdekoration überflüssig und der gewonnen Platz wenn auch minimal kann besser für die eigentlichen Fensterinhalte genutzt werden. Diese Überlegung trifft nicht auf BlueTile zu, daher habe ich dieses bekannte Bedienelement wieder eingeführt. Genau wie in klassischen WMs, ermöglicht es den Zugriff auf die bereits angesprochene Funktionalität (siehe Abbildung 11). Das Symbol X zum Schließen eines Fensters erklärt sich von selbst. Die Details des Minimierens (Symbol ) und Maximierens (Symbol []) werden in den Abschnitten 9.5 und 9.6 genauer ausgeführt. Über das Symbol (M) lässt sich das Fenstermenü aufrufen (siehe Abbildung 12). Um Entwicklungszeit zu sparen, habe ich hierfür ein bereits bestehendes Modul von XMonad genutzt, welches eine Reihe von Optionen in Form einer Raute anzeigt. Anstatt ein konventionelles Menü von Grund auf 22

23 Abbildung 11: Fensterdekoration in BlueTile zu entwickeln, habe ich auf diesem Code aufgebaut. Um zu signalisieren, dass das Menü zum Fenster gehört, zentriere ich die Raute grob in der Mitte des Fensters. Neben den bereits angesprochenen Funktionen bietet das Menü die Möglichkeit, das Fenster auf einen anderen virtuellen Desktop zu verschieben. Abbildung 12: Fenstermenü 9.3 Fenster verschieben Offensichtlich gehört zum täglichen Arbeiten mit Windowmanagern auch das Verschieben von Fenstern an eine neue Position. Aus klassischen Windowmanagern ist man gewöhnt, dass dies typischerweise mit Hilfe der Maus und der Fensterdekoration erfolgt genauer gesagt über die Titelleiste eines Fensters, die per Drag & Drop an eine neue Position gezogen wird. Für den SWM-Modus von BlueTile kann diese Herangehensweise unverändert übernommen werden. Aber auch im TWM-Modus gibt es das Konzept des Verschiebens von Fenstern, auch wenn die Verschiebung hier stärker eingeschränkt ist. Da die Position der Fens- 23

24 ter durch den Layout-Algorithmus bestimmt werden und somit keine beliebigen Fensterpositionen möglich sind. Das Verschieben eines Fensters beschränkt 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ählt damit aus, welche Position das ursprüngliche Fenster nun einnehmen soll. Um ein visuelles Feedback zu geben, habe ich es so umgesetzt, dass während des Vorgangs das Fenster dem Mauszeiger folgt (siehe Abbildung 13). Wird kein gültiges Ziel ausgewählt, springt das Fenster zurück an seine ursprüngliche Position im anderen Fall nimmt es die Position des ausgewählten Ziels an (siehe Abbildung 14). Abbildung 13: Fenster wird per Drag & Drop verschoben Abbildung 14: Fenster tauscht mit dem ausgewählten Ziel die Position 24

25 Es stellt sich nun noch die Frage, wohin das Zielfenster verschoben wird. Da es eine feste Reihenfolge der Fenster gibt, könnte das verschobene Fenster einfach an der ausgewählten Position eingefügt werden und die nachfolgenden Fenster würden eine Position nach hinten wandern. Eine weitere Möglichkeit besteht darin, dass das Zielfenster die alte Position des verschobenen Fensters einnimmt und somit die beiden Fenster einfach die Positionen tauschen. Ich habe mich für letztere Möglichkeit entschieden, da es mir sehr naheliegend erscheint und möglichst wenig potentiell verwirrende - zusätzliche Bewegung auf dem Bildschirm erzeugt. 9.4 Fenstergröße ändern Ähnlich grundlegend wie das Verschieben von Fenstern ist das Verändern der Größe von Fenstern. In klassischen Windowmanagern erfolgt auch dies über die Fensterdekoration. Diese beinhaltet einen Rahmen um das Fenster herum, der genutzt werden kann, um das Fenster mit der Maus in die gewünschte Größe zu bringen. Erneut kann dieser Ansatz für den SWM-Modus von BlueTile übernommen werden. Im TWM-Modus sieht die Situation etwas anders aus. Fenster überlappen sich nicht und die gesamte Bildschirmfläche wird genutzt. Daher werden durch ein Vergrößern oder Verkleinern eines Fensters, zwangsläufig auch andere Fenster in ihrer Größe beeinflusst. Zudem sind nicht alle Arten der Größenänderung in diesem Modus überhaupt sinnvoll. Beispielsweise könnte die Situation gegeben sein, dass ein Fenster durch einen Layout-Algorithmus bündig mit dem linken Rand plaziert wird. Würde man dieses Fenster nun von der linken Seite aus verkleinern, würde es stets automatisch neu an den linken Rand herangeschoben werden. Im Endeffekt wäre das Ergebnis also das selbe, wie wenn man das Fenster von der rechten Seite aus verkleinert hätte. Daher ist es im TWM-Modus sinnvoller statt mit der Größenänderung einzelner Fenster, mit dem Konzept der Veränderung der Trennlinien zwischen den Fenstern zu arbeiten. Dadurch wird automatisch deutlich, dass das Verschieben einer Trennlinie zwischen zwei Fenstern offensichtlich die Größe beider Fenster beeinflusst. Diesem Konzept folgend, habe ich die gekachelten Layouts von BlueTile um die Möglichkeit erweitert, die Trennlinien mit der Maus zu verschieben. Um diese Möglichkeit zu signalisieren, verändert sich der Mauszeiger beim Überfahren der Trennlinien (siehe Abbildung 15). Die Tastaturbedienung der Größenänderung im TWM-Modus konnte ich unverändert von XMonad übernehmen. Hierbei werden die Trennlinien über Tastaturkommandos um einen festen Wert nach links oder rechts bzw. oben oder unten verschoben. Das aktuell fokusierte Fenster entscheidet dabei, welche Trennlinie verändert wird. Je nach Tastaturkommando beziehen sich die Änderungen auf die Trennlinie rechts vom Fenster oder diejenige unterhalb des Fensters. Auf Grund der vielen Freiheitsgrade ist für den SWM-Modus zur Zeit keine Möglichkeit vorgesehen, 25

26 Abbildung 15: Mauszeiger über einer Trennlinie die Fenster alleine durch die Tastatur in ihrer Größe zu verändern. 9.5 Minimieren Von klassischen Windowmanagern ist man gewöhnt, Fenster minimieren zu können, die gerade nicht von Interesse sind. Wie viele TWMs bietet XMonad eine derartige Möglichkeit nicht direkt. Allerdings halte ich eine Minimierungsfunktion in einem TWM für noch wichtiger als in einem SWM. In einem SWM können 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 überlappen, nehmen hier solche Fenster zwangsläufig Bildschirmfläche ein. Dies ist also eine potentiell frustrierende Erfahrung für eine neue Benutzerin, daher würde eine vertraute Minimierungsfunktion eine große Einstiegshilfe darstellen. Die einzige Funktionalität XMonads, die ein Stück in diese Richtung geht, sind Layout-Algorithmen, die manche Fenster überhaupt nicht darstellen. So bietet XMonad 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ächs- 26

27 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 sichtbar sein soll, wird durch den Fokus bestimmt. Diese Möglichkeit scheint mir jedoch relativ ungewohnt zu bedienen zu sein und sie bedeutet insbesondere, dass der Layout-Algorithmus geändert werden muss, nur um einige Fenster zu minimieren. Dies ist schwer vermittelbar an eine Benutzerin, die an klassische Windowmanager gewöhnt ist. Eine weitere Möglichkeit 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ösung für eine fehlende Minimierungsfunktion dar. Sich allein auf diese Möglichkeit zu verlassen, würde 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ällen nicht zutreffen. Ich habe mich daher entschlossen, eine Minimierungsfunktion vergleichbar dazu, wie sie sich in klassischen Windowmanagern findet zu implementieren. Diese soll es ermöglichen, beliebige Fenster unabhängig vom Layout-Algorithmus zu minimieren und später wiederherstellen zu können. Sobald ein Fenster minimiert wird, ist es nur noch auf der Taskbar sichtbar. Der aktuelle Layout betrachtet es als nicht-existent und ordnet die verbleibenden Fenster entsprechend neu an. Dadurch, dass die Funktionalität in vertrauter Weise gestaltet wird, können Benutzer und Benutzerinnen erneut Kenntnisse aus klassischen Windowmanagern nutzen (siehe Abbildungen 16 und 17). Beim Design der Funktionalität waren mehrere Aspekte zu beachten: Wie erfolgt die Bedienung durch die Maus? Wie verhält sich der Fokus in Bezug auf minimierte Fenster? Wie verhält sich der Fokus beim Minimieren und Wiederherstellen von Fenstern? 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 Windowmanager modellieren. Über einen Button in der Fensterdekoration lässt sich ein Fenster minimieren und findet sich dann nur noch auf der Taskleiste. Da GNOME als Desktop Environment angenommen wird (siehe Abschnitt 3), ist eine solche vorhanden. Das Wiederherstellen eines Fensters erfolgt durch Anklicken auf der Taskleiste. Ein weiterer Aspekt ist die Interaktion zwischen dem Fokus und minimierten Fenstern. Wenn der Fokus über die Tastatur gewechselt wird, existiert eine bestimmte 27

28 Abbildung 16: Rotes Fenster soll minimiert werden Abbildung 17: Rotes Fenster wurde minimiert 28

29 Reihenfolge, in der Fenster den Fokus bekommen. Es stellt sich nun die Frage, ob minimierte 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 Überlegung habe ich mich dafür 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 müssen. Zudem bleibt die Fokus-Reihenfolge damit leichter zu überblicken. Beim Erreichen des letzten Fensters der Reihe, springt der Fokus wieder an den Anfang. Dies ist wesentlich intuitiver, als wenn vorher noch minimierte Fenster durchlaufen würden und der Fokuswechsel hier sogar andere Aktionen ein Wiederherstellen von Fenstern auslösen würde. 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ächsten Fenster in der Fokus-Reihenfolge. Dies habe ich übernommen für das Minimieren von Fenstern. Das Wiederherstellen eines Fensters drückt aus, dass die Benutzerin sich damit beschäftigen möchte. Es ist also sinnvoll, dem wiederhergestellen Fenster den Fokus zu geben. Bei der Positionierung von wiederhergestellen Fenstern eröffnen sich im Wesentlichen zwei Möglichkeiten: Das Fenster könnte als Master-Fenster gesetzt werden, da die Benutzerin sich offensichtlich damit beschäftigen will. Alternativ könnte man das Fenster wieder dort einreihen, wo es sich vorher befunden hat. Ich habe mich für letztere Option entschieden, da dadurch ein Minimieren und sofortiges Wiederherstellen erneut zur Ausgangsanordnung führt und die Fensterpositionen nicht unnötig durcheinander bringt. Da die Bedienung durch die Tastatur für fortgeschrittene Benutzer und Benutzerinnen ein wesentliches Feature darstellt, sollte die Minimierungsfunktion auch über Tastenkürzel benutzbar sein. Das Minimieren des fokusierten Fensters lässt sich leicht auf eine Tastenkombination legen. Schwieriger sieht es mit dem Wiederherstellen von Fenstern aus. Hier stellt sich die Frage, wie ausgewählt wird, welches Fenster wiederhergestellt werden soll. Schließlich können potentiell mehrere Fenster gleichzeitig minimiert sein. Die Option, diese Auswahl durch Wechsel des Fokus zu treffen, wurde bereits diskutiert und verworfen. Es wäre möglich, eine alternative Fokus-Reihenfolge nur für minimierte Fenster einzuführen. Dies scheint mir jedoch verhältnismäßig aufwendig und potentiell verwirrend zu sein. Ich habe mich daher entschlossen, eine einfache Lösung zu wählen und dafür eine Einschränkung in Kauf zu nehmen: Das Wiederherstellen wird nun über ein einzelnes Tastenkürzel ausgelöst. Wiederhergestellt wird dabei das zuletzt minimierte Fenster. 29

30 Somit lässt sich nur mit der Tastatur nicht direkt auswählen, welches Fenster wiederhergestellt werden soll. Zur Not müssen mehrere Fenster wiederhergestellt und dann einige wieder minimiert werden. Um leichter durch alle minimierten Fenster wechseln zu können, wäre eine Variante denkbar, bei der das mehrmalige Betätigen des Tastenkürzels dazu führt, dass zum einen das nächste minimierte Fenster wiederhergestellt wird, jedoch gleichzeitig das zuvor wiederhergestellte Fenster zurück in den minimierten Zustand wechselt. Auf diese Weise könnte man gezielt nach einem bestimmten minimierten Fenster suchen. Bei dieser Variante bleibt jedoch die Frage offen, wie man ein Fenster dauerhaft wiederherstellt, wenn man nicht mehr möchte, dass es zurück in diesen Kreislauf fällt. Natürlich wäre ein weiteres, zusätzliches Tastenkürzel denkbar, aber eine solche Lösung scheint wenig transparent für die Benutzerin zu sein. Ich habe daher die ursprüngliche Variante implementiert und in Kauf genommen, dass bei Tastatur-Benutzung unter Umständen Fenster vorübergehend wiederhergestellt und direkt wieder minimiert werden müssen. Der Vorteil dieser Lösung ist, dass nur ein Tastenkürzel benötigt wird. 9.6 Maximieren Neben dem Minimieren, ist das Maximieren eine Funktion, die aus klassischen Windowmanagern bekannt ist. Auch sie wird dort in der Regel über einen Button in der Fensterdekoration aufgerufen. Diese Vorkenntnisse lassen sich nutzen, um auch in BlueTile eine vergleichbare Funktionalität auf ähnliche Weise zur Verfügung zu stellen. Grundsätzlich ist es in einer gekachelten Ansicht schwierig, einem einzelnen Fenster besonders viel Fläche zu geben. Denn dies führt zwangsläufig 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öglichkeit, 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 vorübergehend ein Fenster zu maximieren, könnte man also das entsprechende Fenster fokusieren, dann zum Layout-Algorithmus Vollbild wechseln und später wieder zurück zum vorher verwendeten Layout- Algorithmus wechseln. Diese Möglichkeit setzt jedoch voraus, dass die Benutzerin bereits relativ vertraut mit den verschiedenen Layout-Algorithmen ist und mit der Möglichkeit, 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 darüber entstehen, wie die restlichen Fenster wiederhergestellt werden können, bevor die Benutzerin mit der genauen Semantik dieses Layout- Algorithmus vertraut ist. 30

31 Ich habe mich daher entschieden, die Funktionalität des Maximierens unabhängig vom Layout-Algorithmus zur Verfügung zu stellen und derart umzusetzen, dass Verwirrung möglichst vermieden wird. Dies führt zu mehreren Designentscheidungen: In jedem Layout kann ein beliebiges Fenster maximiert werden dies erfolgt entweder über einen Button in der Fensterdekoration oder über ein Tastenkürzel. Dieses Fenster wird dann aus dem bestehen Layout herausgelöst und vergrößert dargestellt. Um der Benutzerin Orientierung 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öglichen, 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 Lücke sichtbar, an der es sich vorher in nicht-maximierter Form befunden hat (siehe Abbildung 19). Auf diese Weise lässt sich relativ leicht zwischen dem maximierten Fenster und den restlichen Fenstern wechseln. Zusätzlich habe ich noch die Limitierung eingeführt, dass nur ein Fenster zur gleichen Zeit maximiert werden kann. Dies soll ebenfalls die Orientierung erleichtern. Da mehrere maximierte Fenster sich sowieso überdecken würden, geht hier auch kei- 31

32 Abbildung 19: Maximiertes Fenster im Hintergrund ne wichtige Funktionalität verloren. Wird ein anderes Fenster maximiert, so gleitet das aktuell maximierte Fenster zurück an seine ursprüngliche Position und das neue Fenster wird maximiert. Auf diese Weise bleibt es stehts möglich, Fenstern durch Anklicken den Fokus zu geben, da sie sich niemals komplett überdecken. 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önnen, die nur in TWMs zu finden sind. Funktionen also, die erschließbar gemacht werden müssen, 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 überhaupt Fenster zu kacheln. 32

33 Abbildung 20: Dock-Applikation Hot Corners Meine erste Überlegung war, diese Funktionalität über das Konzept der Hot Corners verfügbar 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ären. Da BlueTile vier verschiedene Layout-Algorithmen anbietet, würde sich eine entsprechende Belegung der vier Ecken anbieten. Es ergeben sich jedoch eine Reihe von Problemen mit diesem Ansatz: Zum Einen lässt er sich nicht ohne Weiteres auf ein Dual-Head-Setup übertragen. In einem solchen Setup gibt es weiterhin nur vier nutzbare Ecken die äußeren Ecken der gesamten Bildschirmfläche denn nur diese sind mit der Maus gezielt ansteuerbar. Layout-Algorithmen sind jedoch für jeden virtuellen Desktop und damit für jeden Bildschirm separat einstellbar. Von den vier nutzbaren Ecken bleiben somit nur zwei für jeden Bildschirm übrig. Um damit noch alle vier Layout-Algorithmen verfügbar zu machen, wäre es zwar denkbar, die Belegungen nächster Layout- Algorithmus und vorheriger Layout-Algorithmus zu wählen, 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äre also nötig, die Benutzerin darauf hinzuweisen, dass 33