Quattro reçoit un correctif audio, une mise à l’échelle indépendante par écran et des gestes par défaut

01Un correctif audio vise les arrêts silencieux d’applications et les coupures de son

emirb a intégré omacom/omarchy#16824 à la branche de développement de Quattro. Le changement installe rtkit sur toutes les plateformes, permet aux clients PipeWire du système hôte de demander directement un ordonnancement temps réel et corrige les sessions en cours avant d’activer le service. La proposition attribue les arrêts silencieux d’applications à un budget de temps réel nul et signale aussi que les threads audio ne respectent pas leurs échéances sous charge.

Le correctif relève les limites existantes lorsqu’elles sont nulles avant l’installation et coordonne les mises à jour simultanées. Le PR ne signale aucun arrêt d’application provoqué par la mise à niveau sur les deux machines physiques testées, et rapporte un passage de 111 et 92 sous-alimentations du tampon audio à zéro lors des tests avec de petits tampons. Ces mesures sont rapportées par la personne ayant contribué au correctif. Les clients Flatpak et WirePlumber conservent des limitations liées aux portails ; cette intégration ne démontre donc pas que tous les cas concernés sont corrigés.

02La mise à l’échelle est mémorisée indépendamment pour chaque écran

dhh a proposé puis intégré omacom/omarchy#16923 à Quattro. La mémorisation au moyen d’un réglage d’échelle commun est remplacée par une règle propre à l’écran qui a le focus. Modifier l’échelle de l’écran d’un ordinateur portable ne devrait donc plus modifier celle d’un écran externe après le rechargement de la configuration.

Dans ses réponses ultérieures, dhh a décrit des écritures atomiques qui préservent les liens symboliques de configuration, ainsi que des protections qui laissent intactes les règles d’écran complexes. dhh a ensuite intégré omacom/omarchy#16950 pour calculer la valeur de GDK_SCALE de toute la session à partir du facteur d’échelle le plus bas parmi les écrans activés. Cela corrige la taille excessive des applications XWayland sur un écran de moindre densité, avec la contrepartie annoncée qu’elles peuvent paraître légèrement petites sur l’écran le plus dense.

03Des gestes par défaut pour le pavé tactile arrivent dans Quattro

dhh a proposé puis intégré omacom/omarchy#16891 à Quattro. Les balayages à trois doigts permettent de changer d’espace de travail, d’afficher ou de masquer la console IA, ou d’ouvrir le menu Omarchy ; ceux à quatre doigts déplacent la fenêtre active entre les espaces de travail ou activent et désactivent le plein écran.

Lors de la migration, les gestes par défaut sont désactivés si des gestes personnalisés existent déjà, afin d’éviter les conflits d’affectation. Au fil des échanges, dhh a étendu la détection aux fichiers de configuration imbriqués et aux liens symboliques, tout en préservant ces liens lors des modifications de configuration. Les utilisateurs peuvent désactiver tous les gestes par défaut ou supprimer une affectation particulière avant de la remplacer.

04Le shell du bureau prend en charge la séquence d’introduction du fond d’écran

dhh a proposé puis intégré omacom/omarchy#16884 à Quattro, transférant la gestion de la séquence d’introduction du fond d’écran des scripts shell au shell du bureau. La séquence conserve l’image sortante jusqu’à ce que sa remplaçante soit prête et coordonne le lien vers le fond d’écran, la lecture de l’introduction et le rechargement ultérieur de Hyprland.

Les réponses ultérieures de dhh décrivent le verrouillage des changements de fond d'écran face aux changements de thème, la vérification de l’activité de l’introduction pendant le maintien du verrou de rechargement, et le recours à une transition ordinaire lorsqu’un ancien shell en cours d’exécution ne dispose pas du nouveau mécanisme de relais. Ces changements visent à éviter les flashs, les transitions interrompues et les conflits entre sélections rapides successives.

05Un économiseur d’écran Wayland natif remplace les fenêtres de terminal

omarchybot a intégré omacom/omarchy#16800 à Quattro. Le nouvel économiseur d’écran affiche une surcouche sur chaque écran et se ferme au moindre mouvement de souris, clic, défilement ou appui sur une touche. Il remplace les fenêtres de terminal qui ne réagissaient pas à la souris.

Le service de gestion de l’inactivité arrête aussi l’économiseur d’écran lorsqu’il détecte une activité que la surcouche ne peut pas recevoir, comme l’utilisation de touches multimédias associées à des raccourcis, et annule le verrouillage prévu au retour de l’utilisateur. Selon la PR, le paquet est disponible sur edge pour les deux architectures ; sa promotion vers rc et stable reste nécessaire pour qu’une version d’Omarchy intégrant ce changement parvienne à ces canaux.

06Les comptes familiaux sélectionnés par mot de passe restent en développement

omarchybot a ouvert omacom/omarchy#16920, une proposition Quattro toujours en cours pour permettre à plusieurs adultes et enfants de partager une même installation. Chaque compte disposerait de son propre emplacement de clé de déverrouillage du disque, le mot de passe saisi déterminant le bureau à ouvrir. Les comptes enfants ajouteraient des restrictions sur les applications, des collections de thèmes, une gestion du temps d’écran et une liste de sites web autorisés.

Dans ses réponses ultérieures, omarchybot fait état de correctifs concernant l’accès depuis un autre compte aux résolveurs DNS des enfants, les interruptions du transfert de responsabilité du mot de passe de root et la création de comptes lorsque sudo exige un mot de passe. Il s’agit de correctifs apportés à la branche proposée, et non de fonctionnalités déjà intégrées.

La proposition précise les limites du contrôle parental : un enfant déterminé peut modifier sa session, et la connaissance d’un mot de passe du disque permet de lire celui-ci depuis une clé USB live. Sur Apple Silicon, la prise en charge par les paquets de démarrage est également nécessaire avant de pouvoir accepter l’emplacement de clé d’une autre personne.

07La discussion sur les priorités de mise s’oriente vers une désactivation explicite

omarchybot a ouvert omacom/omarchy#16881 au sujet des outils par défaut de mise prévus pour une installation à la demande : bien que non installés, ils prennent le pas sur des commandes installées séparément. Dans une réponse publiée plus tôt dans la journée, omarchybot avait relayé la préférence d’un mainteneur : seuls les outils par défaut non installés devaient passer après les autres installations.

cobrakoral a ensuite rapporté des tests montrant que les agencements proposés du PATH pouvaient contourner les versions explicitement définies par les projets ou échouer lors d’une exécution via mise. cobrakoral a également distingué une amélioration de l’affichage des informations en amont du choix de l’exécutable : indiquer qu’un outil est installé à la demande ne change pas le binaire exécuté.

En réponse à ces constats, jdx a indiqué que la solution devait être une désactivation explicite et a demandé de ne pas poursuivre la piste d’un repli automatique dans mise ou Omarchy. jdx a recommandé disable_tools pour les commandes individuelles ou Remove > Preinstalls pour les outils par défaut d’Omarchy. Le ticket reste ouvert ; la discussion fournie établit cette recommandation, et non un changement de priorité déjà intégré à Omarchy.

08Une proposition pour l’installateur réduit la concurrence d’accès à la clé USB au démarrage

hegjon a ouvert omacom/omarchy-iso#355, qui reste en cours. Cette proposition attribue aux services de vérification une comptabilisation distincte des entrées-sorties, évite des traitements inutiles du shell au démarrage et prépare à l’avance les polices de la console. Elle vise à afficher plus rapidement l’écran d’accueil de l’installateur tout en conservant la vérification du support.

Après de premières mesures en machine virtuelle, hegjon a rapporté un test sur un ThinkPad X200 physique avec la même clé USB : le délai entre le démarrage du noyau et l’écran d’accueil est passé de 25.5 à 20.5 secondes, puis une installation complète a réussi. Ces mesures proviennent de l’auteur de la proposition. Ce retour précise le gain à attendre sur cette machine, où la phase initramfs, inchangée, restait la principale source de délai.

09Les réglages par défaut du chargeur pour l’affichage et le GPU du M3 Max arrivent sur edge

ryanrhughes a intégré à master la PR omacom/omarchy-pkgs#1707 de chriskearney. Le paquet du chargeur active par défaut les mécanismes existants de passage de relais pour l’affichage et le GPU sur le J516C M3 Max de 16 pouces, sous réserve des contrôles d’admissibilité. Il inclut aussi un passage de relais de la mémoire dont dépend la prise en charge des écrans externes du T6030.

Lors de son approbation, maralcbr a exigé que le noyau et Mesa correspondants soient livrés avant le chargeur, afin qu’edge ne l’associe pas à l’ancien noyau. github-actions[bot] a ensuite signalé la publication réussie de m1n1-aurora 1.6.1.aurora22-1 sur edge pour aarch64.

La PR distingue les tests matériels antérieurs de la qualification de cet assemblage précis de composants. Les installations existantes doivent reconstruire boot.bin puis démarrer avec celui-ci pour utiliser le nouveau Stage2. La reconstruction des installateurs et la qualification complète pour rc ou stable restent des étapes distinctes.

10Omarchy Files rejoint la marketplace après des correctifs de confidentialité

spalencsar a soumis le widget de lancement Omarchy Files via omacom/omarchy-plugin-marketplace#13098. Il ouvre une application de gestion de fichiers distincte et, si elle est absente, propose de l’installer dans le répertoire personnel de l’utilisateur après confirmation.

Lors de sa revue, HANCORE-linux a confirmé les correctifs précédents concernant l’historique des dossiers et la livraison, puis a relevé que des noms de fichiers privés et des erreurs brutes étaient exposés dans les arguments des commandes de notification. Une revue ultérieure a confirmé que la livraison de la v0.1.3 corrigeait ces problèmes et que les sommes de contrôle des archives figées correspondaient.

github-actions[bot] a ensuite signalé la publication et la vérification, puis la soumission a été clôturée. Cette vérification porte sur l’instantané de la marketplace qui a été examiné et ne constitue explicitement pas un audit de sécurité.