Audiokorrektur soll unbemerkte App-Abbrüche und Tonaussetzer beheben
emirb hat omacom/omarchy#16824 in den Quattro-Entwicklungszweig übernommen. Die Änderung installiert rtkit plattformübergreifend, ermöglicht PipeWire-Clients auf dem Host, Echtzeit-Scheduling direkt anzufordern, und korrigiert laufende Sitzungen, bevor der Dienst aktiviert wird. Der Vorschlag nennt ein Echtzeitbudget von null als Ursache dafür, dass Anwendungen ohne Fehlermeldung beendet werden. Hinzu kommen Audio-Threads, die unter Last ihre Zeitvorgaben verfehlen.
Die Korrektur erhöht vorhandene Null-Limits vor der Installation und koordiniert gleichzeitige Aktualisierungen. Laut PR wurden auf zwei getesteten physischen Rechnern keine Anwendungen durch das Upgrade beendet; bei Tests mit kleinen Audiopuffern gingen die Pufferunterläufe von 111 beziehungsweise 92 auf null zurück. Diese Messwerte stammen von den Mitwirkenden. Für Flatpak-Clients und WirePlumber bestehen weiterhin portalbedingte Einschränkungen. Die Übernahme belegt daher nicht, dass alle betroffenen Ausführungspfade korrigiert sind.
Monitorskalierung wird für jeden Bildschirm unabhängig gespeichert
dhh hat omacom/omarchy#16923 vorgeschlagen und in Quattro übernommen. Statt die Skalierung über eine gemeinsame Einstellung zu speichern, wird nun eine Regel für den fokussierten Monitor verwendet. Eine Änderung der Skalierung des Laptopdisplays sollte dadurch nach dem Neuladen der Konfiguration nicht mehr auch die Skalierung eines externen Bildschirms ändern.
In späteren Antworten beschrieb dhh atomare Schreibvorgänge, die symbolische Links der Konfiguration erhalten, sowie Schutzmechanismen, die komplexe Monitorregeln unangetastet lassen. Anschließend übernahm
dhh omacom/omarchy#16950, um den sitzungsweiten Wert von GDK_SCALE aus der niedrigsten Skalierung der aktivierten Monitore abzuleiten. Das behebt die übergroße Darstellung von XWayland-Anwendungen auf einem Bildschirm mit geringerer Pixeldichte. Als Abwägung wird genannt, dass sie auf dem Bildschirm mit höherer Pixeldichte etwas klein erscheinen können.
Standardgesten für das Touchpad kommen in Quattro an
dhh hat omacom/omarchy#16891 vorgeschlagen und in Quattro übernommen. Wischgesten mit drei Fingern wechseln Arbeitsflächen, blenden die KI-Konsole ein oder aus oder öffnen das Omarchy-Menü. Wischgesten mit vier Fingern verschieben das aktive Fenster zwischen Arbeitsflächen oder schalten den Vollbildmodus um.
Bei vorhandenen eigenen Gesten deaktiviert eine Migration die Standardgesten, um widersprüchliche Belegungen zu vermeiden. Im weiteren Verlauf erweiterte dhh die Erkennung auf verschachtelte Konfigurationsdateien und symbolische Links und sorgte dafür, dass diese Links beim Bearbeiten der Konfiguration erhalten bleiben. Nutzer können alle Standardgesten deaktivieren oder eine einzelne Belegung aufheben, bevor sie diese ersetzen.
Die Desktop-Shell übernimmt die Ablaufsteuerung der Hintergrund-Intros
dhh hat omacom/omarchy#16884 vorgeschlagen und in Quattro übernommen. Damit wandert die Ablaufsteuerung der Hintergrund-Intros aus Shell-Skripten in die Desktop-Shell. Der Ablauf hält das bisherige Bild, bis das neue bereitsteht, und koordiniert den Hintergrund-Link, die Intro-Wiedergabe und das anschließende Neuladen von Hyprland.
In den späteren Antworten beschreibt dhh, wie Hintergrundänderungen gegen gleichzeitige Theme-Wechsel gesperrt werden, wie bei gehaltener Neuladesperre geprüft wird, ob ein Intro aktiv ist, und wie ein gewöhnlicher Übergang als Rückfalllösung dient, wenn einer älteren laufenden Shell die neue Übergabe fehlt. Die Änderungen sollen Aufblitzen, unterbrochene Übergänge und Konflikte bei rasch aufeinanderfolgenden Auswahlen verhindern.
Ein nativer Wayland-Bildschirmschoner ersetzt Terminalfenster
omarchybot hat omacom/omarchy#16800 in Quattro übernommen. Der neue Bildschirmschoner zeigt auf jedem Bildschirm ein Overlay an und verschwindet bei Mausbewegungen, Klicks, Scrollen oder Tasteneingaben. Er ersetzt Terminalfenster, die nicht auf Mauseingaben reagierten.
Der Inaktivitätsdienst beendet den Bildschirmschoner auch bei Aktivitäten, die das Overlay nicht empfangen kann, etwa bei belegten Medientasten, und hebt die anstehende Bildschirmsperre auf, wenn der Nutzer zurückkehrt. Laut PR ist das Paket für beide Architekturen in edge verfügbar. Bevor eine Omarchy-Version mit dieser Änderung die Kanäle rc und stable erreicht, muss das Paket noch dorthin übernommen werden.
Per Passwort ausgewählte Familienkonten bleiben in Entwicklung
omarchybot hat omacom/omarchy#16920 eröffnet, einen noch offenen Quattro-Vorschlag für mehrere Erwachsene und Kinder auf einer gemeinsamen Installation. Jedes Konto hätte einen eigenen Schlüsselplatz zur Datenträgerentschlüsselung; das zum Entsperren verwendete Passwort würde den Desktop auswählen. Kinderkonten würden App-Beschränkungen, Theme-Sammlungen, Bildschirmzeit und eine Freigabeliste für Websites ergänzen.
In späteren Antworten berichtet omarchybot über Korrekturen beim kontenübergreifenden Zugriff auf die DNS-Resolver der Kinderkonten, bei unterbrochenen Übergaben der Verantwortung für das root-Passwort und bei der Kontoerstellung, wenn sudo ein Passwort verlangt. Diese Korrekturen befinden sich im vorgeschlagenen Branch und sind noch keine übernommenen Funktionen.
Der Vorschlag benennt ausdrücklich die Grenzen seiner Kinderschutzfunktionen: Ein entschlossenes Kind kann seine Sitzung verändern, und mit einem bekannten Datenträgerpasswort lässt sich der Datenträger von einem Live-USB-System aus lesen. Auf Apple Silicon ist außerdem Unterstützung durch die Boot-Pakete nötig, bevor der Schlüsselplatz einer weiteren Person akzeptiert werden kann.
Diskussion über die Befehlspriorität in mise tendiert zur ausdrücklichen Deaktivierung
omarchybot hat omacom/omarchy#16881 eröffnet, weil noch nicht installierte mise-Standardwerkzeuge mit bedarfsgesteuerter Installation Vorrang vor separat installierten Befehlen erhalten. In einer Antwort früher am selben Tag hatte
omarchybot die Präferenz eines Maintainers weitergegeben: Nur noch nicht installierte Standardwerkzeuge sollten hinter anderen Installationen zurückstehen.
cobrakoral berichtete anschließend von Tests, denen zufolge die vorgeschlagenen PATH-Anordnungen explizit festgelegte Projektversionen umgehen oder bei der Ausführung über mise scheitern könnten.
cobrakoral unterschied außerdem zwischen einer verbesserten Statusanzeige im Upstream-Projekt und der Auswahl der ausführbaren Datei: Ein Werkzeug als lazy anzuzeigen, ändert nicht, welche Binärdatei ausgeführt wird.
Als Reaktion auf diese Ergebnisse erklärte jdx, eine ausdrückliche Deaktivierung solle die Lösung sein, und bat darum, einen automatischen Rückgriff auf andere Installationen weder in mise noch in Omarchy weiterzuverfolgen.
jdx empfahl disable_tools für einzelne Befehle oder Remove > Preinstalls für die Standardwerkzeuge von Omarchy. Das Issue bleibt offen; die vorliegende Diskussion belegt diese Empfehlung, aber keine bereits übernommene Änderung der Prioritätsregeln in Omarchy.
Installer-Vorschlag verringert Ressourcenkonkurrenz beim Start vom USB-Stick
hegjon eröffnete omacom/omarchy-iso#355; der PR ist weiterhin offen. Er erfasst die Ein- und Ausgabe der Verifizierungsdienste getrennt, vermeidet unnötige Arbeit der Shell beim Start und erstellt Konsolenschriften vorab. So soll der Begrüßungsbildschirm des Installers früher erscheinen, während die Überprüfung des Installationsmediums erhalten bleibt.
Nach ersten Messungen in virtuellen Maschinen berichtete hegjon von einem Test auf einem echten ThinkPad X200 mit demselben USB-Stick: Die Zeit vom Kernelstart bis zum Begrüßungsbildschirm sank von 25.5 auf 20.5 Sekunden. Anschließend wurde eine vollständige Installation erfolgreich durchgeführt. Diese Messwerte stammen vom Urheber des Vorschlags. Der Nachtrag grenzt den erwartbaren Nutzen auf diesem Rechner ein, auf dem die unveränderte initramfs-Phase weiterhin die größte Verzögerung verursachte.
Loader mit standardmäßiger Display- und GPU-Übergabe für den M3 Max erreicht edge
ryanrhughes übernahm omacom/omarchy-pkgs#1707 von
chriskearney in master. Das Loader-Paket aktiviert auf dem J516C, dem M3 Max mit 16 Zoll, standardmäßig die vorhandenen Display- und GPU-Übergaben, sofern die Zulässigkeitsprüfungen bestanden werden. Es enthält außerdem eine davon abhängige Speicherübergabe für externe Displays am T6030.
Bei der Freigabe verlangte Reviewer maralcbr, den passenden Kernel und Mesa vor dem Loader auszuliefern, damit dieser in edge nicht mit dem alten Kernel kombiniert würde.
github-actions[bot] meldete anschließend die erfolgreiche Veröffentlichung von m1n1-aurora 1.6.1.aurora22-1 in edge für aarch64.
Der PR unterscheidet zwischen früheren Hardwaretests und der Qualifizierung genau dieses kombinierten Pakets. Bei bestehenden Installationen muss boot.bin neu erstellt und davon gebootet werden, um die neue Stage2 zu nutzen. Neue Installer-Builds und die vollständige Qualifizierung für rc oder stable bleiben separate Schritte.
Omarchy Files nach Datenschutzkorrekturen im Marketplace gelistet
spalencsar reichte das Starter-Widget Omarchy Files über omacom/omarchy-plugin-marketplace#13098 ein. Es startet eine separate Dateimanager-Anwendung. Fehlt diese, bietet es nach Bestätigung eine Installation im Home-Verzeichnis des Benutzers an.
Reviewer HANCORE-linux bestätigte frühere Korrekturen am Ordnerverlauf und an der Auslieferung. Anschließend stellte er fest, dass private Dateinamen und unverarbeitete Fehlermeldungen über Befehlsargumente für Benachrichtigungen offengelegt wurden. Eine spätere Prüfung bestätigte, dass die ausgelieferte Version v0.1.3 diese Befunde behob und die fest hinterlegten Archivprüfsummen übereinstimmten.
github-actions[bot] meldete daraufhin die Veröffentlichung und Verifizierung; die Einreichung wurde geschlossen. Die Verifizierung gilt für den geprüften Stand im Marketplace und ist ausdrücklich kein Sicherheitsaudit.
