Warum Rectangles Fenster nicht perfekt bündig sind (und wann das behoben ist)
Eine bestimmte Art von Beschwerde taucht bei Rectangle app immer wieder auf: Ein Fenster, das perfekt maximiert oder exakt die halbe Bildschirmbreite haben sollte, hat stattdessen irgendwo eine dünne, sichtbare Lücke – meist nahe der Menüleiste oder zwischen zwei eigentlich benachbarten Fenstern. Manches davon ist eine bewusst gesetzte Einstellung, manches ein echter, gemeldeter Bug, und manches wurde in aktuellen Versionen bereits behoben.
Zuerst: prüfen, ob eine Abstandseinstellung aktiviert ist
Rectangle mac unterstützt einen bewussten Pixel-Abstand zwischen gekachelten Fenstern und Bildschirmrändern, gesetzt über Terminal-Befehle (gapSize, oder die feiner einstellbaren snapEdgeMarginTop/Bottom/Left/Right). Wenn du – oder eine Setup-Anleitung, der du gefolgt bist – das irgendwann aktiviert hat, ist eine sichtbare Lücke erwartetes Verhalten, kein Bug. Prüfe deine aktuellen Werte:
defaults read com.knollsoft.Rectangle gapSize Kommt hier eine Zahl ungleich null zurück, hast du deine Antwort. Entfernen kannst du es mit:
defaults delete com.knollsoft.Rectangle gapSize und Rectangle app danach neu starten.
Ein tatsächlich gemeldeter Bug: Lücke speziell am oberen Rand
Issue #1554 beschreibt eine 1-Pixel-Lücke, die speziell zwischen der Oberkante eines maximierten Fensters und der Menüleiste auftritt, ohne dass eine Abstandseinstellung bewusst konfiguriert wurde. Issue #1347, separat eingereicht, beschreibt etwas Verwandtes, aber Ausgeprägteres: Bei aktivierter Abstandseinstellung war die Lücke am oberen Bildschirmrand etwa 20 % größer als dieselbe Abstandseinstellung am linken, rechten und unteren Rand – eine Inkonsistenz speziell oben, kein allgemeiner Fehler bei der Abstandsberechnung. Beide verweisen auf denselben allgemeinen Codebereich (wie Rectangle app die Grenze nahe der Menüleiste berechnet) statt auf eine Einstellung, die du einfach ausschalten könntest.
Siehst du eine kleine, konsistente Lücke speziell oben bei maximierten oder oberen-Hälfte-Fenstern und sonst nirgends, ist das eine bekannte Kategorie von Meldungen und keine Fehlkonfiguration deinerseits – prüfe den aktuellen Status dieser Issues, denn Abstandsberechnungs-Code ist genau die Art von Sache, die über Point-Releases hinweg verfeinert wird.
Negative Abstände verhalten sich nicht wie erwartet
Issue #576 beschreibt einen spezielleren Fall: Das Setzen eines negativen Werts für screenEdgeGapBottom (gedacht, damit ein maximiertes Fenster leicht über den sichtbaren Bildschirmrand hinausragt und einen schmalen Streifen außerhalb des Bildschirms versteckt) hatte keinerlei Effekt – das Fenster maximierte sich, als wäre der Abstand null, während derselbe positive Abstandswert korrekt funktionierte. Versuchst du, einen negativen Abstandswert für genau diesen Effekt zu nutzen, und passiert nichts, ist das ein dokumentierter Bericht über genau dieses nicht wie erwartet funktionierende Verhalten, kein Syntaxfehler in deinem Befehl.
Ein bereits ausgelieferter Fix: geklemmte Fenster mit unerwünschten Lücken
Die Release Notes zu Version 0.97 gehen speziell auf ein verwandtes, aber eigenständiges Problem ein: Fenster, die geklemmt sind (daran gehindert, ihre volle berechnete Größe zu erreichen, typischerweise wegen einer von der App selbst erzwungenen Mindestgröße – dieselbe Problemkategorie, die bei Apps wie Discord oder Spotify besprochen wird), blieben früher mit einer Lücke zwischen Fenster und Snap-Kante schwebend, statt bündig dagegen geschoben zu werden. Der v0.97-Changelog listet dafür konkret die Fixes „Geklemmte Fenster an der Snap-Kante verankern, statt eine Lücke zu lassen» und „Geklemmte Fenster standardmäßig an Snap-Kanten ausrichten» auf. Hattest du speziell bei Fenstern eine Lücke gesehen, die sich auch sonst widerspenstig gegen vollständiges Schrumpfen zeigten – das Discord/Spotify-artige Problem –, und läuft bei dir eine Version älter als 0.97, könnte ein Update speziell diese Lücke beheben, auch wenn es die zugrunde liegende Mindestgrößen-Beschränkung der App nicht aufhebt.
Das Halbierungs-Verhältnis und Ecken-Aktionen
Dasselbe v0.97-Release „wendet das Halbierungs-Verhältnis auch auf Ecken-Aktionen und Snap-Bereiche an» – ein Fix, der auf Konsistenz zwischen einer einfachen Halbbildschirm-Aktion und einer Ecken- oder Snap-Bereich-Aktion abzielt, und ein Szenario adressiert, in dem diese beiden Pfade zuvor leicht unterschiedliche Grenzberechnungen für das, was derselbe Teilungspunkt sein sollte, hervorbringen konnten.
So prüfst du, ob deine spezielle Lücke bereits behoben ist
- Prüfe deine aktuelle Rectangle app-Version (Menüleisten-Icon → About, ohne Option gedrückt zu halten).
- Vergleiche sie mit der Version, in der jeder oben genannte Fix ausgeliefert wurde – v0.97 für den Fix bei geklemmten Fenstern –, und prüfe direkt den aktuellen Status der Lücke-am-oberen-Rand-Issues (#1554, #1347), da sie möglicherweise in einer Version nach Erstellung dieses Artikels behoben wurden.
- Bist du hinterher, update zuerst, bevor du davon ausgehst, dass eine bestimmte Beschwerde ein dauerhaftes, unbehebbares Problem ist – mehrere der abstandsbezogenen Meldungen im Tracker wurden durch Point-Releases geschlossen, die genau die betroffene Berechnung adressierten.
Wann es wirklich kein Bug ist
Eine Lücke, die nur in einer bestimmten App auftritt und sonst nirgends, ist eher das eigene Mindestgrößen-Verhalten der App (an anderer Stelle in dieser Reihe ausführlich für Apps wie Discord, Spotify und Terminal-Emulatoren behandelt) als ein Pixel-Berechnungsfehler auf Rectangle-Seite. Der unterscheidende Test ist derselbe, der in dieser ganzen Reihe verwendet wird: Erzeugt dieselbe Aktion in den meisten Apps ein sauberes, bündiges Ergebnis und verhält sich nur in einer bestimmten App falsch, ist die App die Variable. Tritt die Lücke konsistent über jede App hinweg am selben Bildschirmrand auf, deutet das eher auf Rectangles eigenen Kantenberechnungs-Code hin, und es lohnt sich, die oben genannten spezifischen Issues zu prüfen oder ein neues mit deiner macOS- und Rectangle-Version einzureichen, falls es noch nicht gemeldet ist.