blog · git · desktop · images · contact


Nichtverfehlbare Ziele – Teil 3

2013-10-19

Im zweiten Teil zu diesem Thema habe ich Pointer Barriers eingeführt: Barrieren, die der Mauszeiger nicht oder nur unter bestimmten Bedingungen überschreiten darf. Bisher hatte ich nur eine solche Barriere tatsächlich im Einsatz, nämlich genau unter der status bar von dwm. Ihr Sinn ist im alten Posting erklärt.

Die Barriere hat sich erwartungsgemäß sehr bewährt und ich möchte sie nicht mehr missen. Das ganze Konzept fällt jedoch in sich zusammen, wenn man mehr als einen Bildschirm benutzt. Ich brauche nämlich nicht nur eine Barriere ganz oben, sondern eigentlich auch links, rechts und unten. Bei nur einem Bildschirm genügt der normale Bildschirmrand.

Nun ist es so, dass ich vor über einem Jahr meinen zusätzlichen Bildschirm abgeschafft und den Widescreen letztendlich durch einen 4:3-19-Zöller ersetzt habe. Ich finde das einfach deutlich angenehmer – ein großer Bildschirm erschlägt mich. Man könnte also meinen, dass ich mich um Multi-Monitor-Setups nicht zu scheren brauche.

Kürzlich habe ich nach viel Rumprobieren festgestellt, dass es tatsächlich nur ein Widescreen-Bildschirm ist, der mich richtig stört. Zusätzliche 4:3-Bildschirme empfinde ich nicht als Problem. Meine Theorie ist, dass ich mich sowieso immer nur auf einen Bildschirm konzentrieren kann, ein zweiter Bildschirm „schadet“ also nicht. Ein großer Bildschirm schadet hingegen schon, weil er mir mehr Aufmerksamkeit abverlangt. So versuche ich mir das jedenfalls zu erklären. Naja.

Zuhause brauche ich tatsächlich nur einen Bildschirm. Auf der Arbeit ist es aber sehr praktisch, einen zweiten (oder gar noch mehr?) zu haben, auf dem dann Server-Monitoring oder ähnliches zu sehen ist. Und hier beginnt das Problem, da mir nun die eine Pointer Barrier nicht mehr genügt.

Das Problem ist natürlich nicht neu und für genau diesen Zweck wurden die Barrieren auch ursprünglich eingeführt. Ubuntu hat das Konzept der „klebrigen Ecken“ auch schon länger. Ich musste hier also das Rad nicht neu erfinden, sondern – plump gesagt – nur aus bereits existierenden Lösungsszenarien das auswählen, was ich in meinem dwm einbauen möchte.

Daher habe ich zunächst versucht, einfach pro Screen rundherum Barrieren anzulegen. Leider haben sich die Barrieren als etwas buggy herausgestellt. In folgendem Szenario (nämlich bei zwei angrenzenden Screens) ist es dem Mauszeiger möglich, auf dem eingezeichneten Weg die Barrieren zu überwinden:

Illustration des Barrierentunnels

Ich konnte die Maus in die rechte obere Ecke werfen und dann nach rechts unten ziehen – die Barriere war manchmal überwunden. Habe ich die Maus dagegen einfach nur weiter nach rechts oder oben bewegt, blieb die Barriere intakt. Auf dem Rückweg blieb die Barriere immer intakt und die beiden unteren Bildschirmecken betraf es auch nicht.

Am Ende habe ich mich für das folgende Konzept entschieden, wobei die „useless gaps“ optional sind. Bei den useless gaps kann ich mich noch nicht entscheiden, ob sie gut sind oder nicht oder ob sie sowieso nur Kosmetik sind. Im Moment tendiere ich dazu, dass sie Platzverschwendung sind und mich in der Wahl des Wallpapers stark einschränken, da dieses nicht „ablenken“ darf. Insgesamt find ich window borders von mindestens 5 Pixeln Breite dann doch übersichtlicher.

Illustration der neuen Barrieren

Um den „Bug“ (sofern es einer ist – vielleicht ist es auch ein Verständnisproblem) zu umgehen, habe ich also die Barrieren verlängert, sodass sie an den Ecken „dichter abschließen“. Nimmt man nun an, dass sich aktuell nur ein Fenster auf dem Bildschirm befindet, dann ist der Mauszeiger auf genau diesen Bereich eingeschränkt. Hier kann er sich also nur im Browser bewegen:

Screenshot

Wenn ich die Maus jetzt in die rechte obere Ecke werfe, lande ich nicht bei der Uhr in der status bar, sondern auf dem „Home“-Button des Browsers. Cool! Und logischerweise funktioniert das auch prima, wenn mehrere Bildschirme angeschlossen sind. Zum Bildschirmwechsel verwende ich dann die normale Funktion, die dwm dazu von Haus aus bereitstellt („focusmon()“), angereichert mit einem Pointer Warp, der den Mauszeiger in die Mitte des neuen Screens positioniert. Ein manueller Wechsel durch Herumschieben der Maus ist also nicht mehr möglich, was sich bei meiner (sehr) langsamen Mausgeschwindigkeit aber ohnehin nicht anbietet, da ich dann zwei oder drei Mal umsetzen muss.

Übrigens: Damit das vernünftig funktioniert, muss der noborder-Patch wieder raus. Sieht sehr ungewohnt aus für mich, aber ist im Endeffekt im Hinblick auf die Usability auch egal.

Fast schon obligatorisch in dieser Posting-Serie ist ein weiterer Fix für den Firefox. Diesmal betrifft es das kleine Suchfeld, das man mit „Strg+F“ öffnen kann und das auch schon in obigem Screenshot zu sehen war:

Screenshot Firefox

Auf diesem Bild ist der nachfolgende Eintrag in der „userChrome.css“ schon zu sehen. Der Knopf zum Schließen reicht jetzt nämlich bis ganz in die linke untere Ecke. Von Haus aus ist da ein winziger Abstand. Klar: Man kann die Maus nicht in die Ecke werfen und blind klicken, um das Suchfeld zu schließen … dämlich. Dasselbe Problem betrifft die anderen Knöpfe.

So geht’s weg:

findbar {
    margin-bottom: -1px !important;
}

Natürlich kann man den Firefox-Leuten das alles nicht übel nehmen. Schließlich wird es erst durch meine „Sonderfälle“ relevant. Und immerhin ist es leicht änderbar, das ist auch sehr viel wert. Wahrscheinlich bin ich sowieso der einzige Mensch auf diesem Planeten, der kein Firefox-Theme verwendet.

– Nachtrag, 2013-01-11: Der Firefox-Fix ist obsolet mit Firefox 25. Sie haben dort den Suchbereich komplett umgestaltet. Guess what: Die Löcher sind NOCH größer geworden. m(

Comments?