Dies ist eine Übersetzung meines englischsprachigen Blog-Posts Cube and Pager
Es ist ziemlich offensichtlich, dass der Cube Effekt das Layout der virtuellen Arbeitsflächen, welches vom Pager vorgegeben ist, nicht nutzen kann. Für den Würfel muss das Layout folgendermaßen aussehen:
+--+--+--+--+
| 1 | 2 | 3 | 4 |
+--+--+--+--+
So erwartet der Nutzer wohl wie der Würfel arbeitet. Alle virtuellen Arbeitsflächen werden auf die Flächen der geometrischen Figur abgebildet. So kennen wir es von Compiz. Aber dieses vom Cube verwendete Layout entspricht nicht dem eigentlichen Layout, welches bei 4 Arbeitsflächen in der Regel so aussieht:
+--+--+
| 1 | 2 |
+--+--+
| 3 | 4 |
+--+--+
Meiner Meinung nach ist es unmöglich dieses Layout für den Cube zu verwenden. Natürlich könnte man etwas in der Art machen, dass man nur zwei Flächen hat und die Arbeitsflächen so skaliert, dass (1,3) auf einer Fläche sind und (2,4) auf der anderen Fläche. Aber dies würde den Würfel irgendwie unnütz machen. Es würde mindestens 8 Arbeitsflächen in einem 2×4 Layout erfordern. Aber ich kann mir nicht vorstellen, dass jemand mit 8 Arbeitsflächen den Würfel nutzt. Persönlich denke ich, dass der Cube Effekt eher von normalen Nutzern, nicht aber von Power Usern benutzt wird. Und ich würde mal behaupten, dass 8 Arbeitsflächen schon irgendwie Power Using ist 😉
Also der Würfel muss das Layout der Arbeitsflächen ignorieren. Dies ist OK und sogar im EWMH erlaubt.
Aber wenn man den Cube zum Animieren des Wechselns der Arbeitsfläche über den Pager, Strg+F1-4 oder über aktive Arbeitsflächenränder verwendet, dann sollte das Layout verwendet werden. Wenn man also z.B. den Pager mit obigen Layout verwendet um von Arbeitsfläche 1 nach 3 zu wechseln, dann erwartet man eine nach unten gehende Animation und nicht zwei Animationen nach rechts. Man erwartet das gleiche Verhalten wie in der Slide Animation.
Für die Benutzung über Pager und Strg+F1-4 ist dieses Verhalten noch benutzbar, aber wenn man aktive Arbeitsflächenränder verwendet und ein Fenster von einer Arbeitsfläche zur nächsten verschiebt, dann wird es unangenehm. Man nehme z.B. das Verschieben eines Fensters von Arbeitsfläche 1 nach links. Wenn man an den Cube denkt, landet man auf der 4. Arbeitsfläche, aber in Wahrheit landet man auf der 2. Man bewegt das Fenster nach links, aber die Animation nach rechts. Noch schlimmer, wenn man Fenster nach oben oder unten bewegt. Anstatt einer Animation nach oben oder unten, wird zwei mal nach links oder rechts animiert. Die Animation entspricht überhaupt nicht der Aktion, welche sie ausgelöst hat. Das ist einer der Gründe, warum ich selbst den Cube nicht verwende um das Wechseln der Arbeitsfläche zu animieren 😉
So ihr habt es vielleicht schon erraten: ich hab daran gearbeitet die Situation zu verbessern und es gibt eine neue Lösung für das Problem in meinem git branch. Es bedarf noch etwas mehr Arbeit bevor es in den Trunk gemergt werden kann (es gibt noch mehr Verbesserungen außer dieser). Während der Animation für das Wechseln der Arbeitsfläche folgt der Würfel nun dem Pager Layout. Also das Wechseln von Arbeitsfläche 1 nach 3 erzeugt eine Animation nach unten, der Wechsel von 1 nach 4 eine Animation nach rechts und eine nach unten. Hier ein Screenshot wie das dann aussieht:
Der Screenshot zeigt auch noch ein weiteres angefordertes Feature: die Kontrollleisten können statisch gehalten werden, während der Cube rotiert. Mir gefällt das sehr gut und ich denke ich werde es von einem zur Zeit opt-in in ein opt-out umwandeln 😉 Natürlich ist dieses Feature nicht im Strg+F11 Modus verfügbar.
Übrigens: aktuell ist die beste Zeit Features für den Cube anzufordern. Ich habe keine Vorlesungen und keine Prüfungen. Also viel Zeit und ich arbeite sowieso am Cube. Ich warte also auf Feature Requests auf bugs.kde.org