J'ai un netbook avec un petit écran au format large (1024×600), ce qui fait que beaucoup de programmes dont les concepteurs n'avaient pas imaginé une telle chose ouvrent des fenêtres qu'on ne peut pas redimensionner et dont les fonds sont obscurcis. Grâce à Ubuntu 10.04, je m'en suis occupé avec une commande xrandr :
xrandr --output LVDS1 --fb 1024x768 --panning 0x768
(notez le 0x) qui a eu pour effet de me donner un bureau virtuel de taille normale qui s'est déroulé verticalement, mais que (d'une manière ou d'une autre) le gestionnaire de fenêtres a ignoré, donc les fenêtres maximisées n'occupaient que l'écran physique. Le résultat était que je n'avais pas besoin de faire un panoramique à moins qu'une grande boîte de dialogue n'apparaisse :sympa.
En 11.04, cela ne fonctionne pas tout à fait. Tout ce que j'ai dit plus haut est vrai, mais les 168 pixels du bas semblent définitivement noircis, si bien que si une grande fenêtre s'y prolonge je ne vois pas ce qu'il y a dedans (cependant, c'est là :les poignées de redimensionnement apparaissent, et sont utiles sur ceux occasions où le redimensionnement est autorisé). J'imagine que c'est lié à Unity. Cela va à l'encontre de l'objectif, alors j'essaie cette commande xrandr :
xrandr --output LVDS1 --fb 1024x768 --panning 1024x768
(notez le 1024x). Hélas, cela ne trompe plus le gestionnaire de fenêtres et les fenêtres maximisées partent toutes du bas. Question :
Comment puis-je configurer les choses pour qu'une fenêtre "maximisée" n'occupe que l'écran physique (ou plus généralement, occupe une partie particulière de l'écran) ?
Une question connexe à laquelle je serais heureux d'avoir répondu à la place est :
Pourquoi la première commande xrandr trompe-t-elle le gestionnaire de fenêtres (le « 0x » signifie, selon la page de manuel, que le panoramique le long de l'axe horizontal est désactivé ; fonctionnellement, cela n'a aucun sens puisque la taille virtuelle est la même que la taille physique) ? Qu'est-ce qui ne va pas avec Unity ?
Notez que l'action "maximiser" est nécessaire, car dans Unity, une fenêtre agrandie est stylisée différemment :sa barre de titre est absorbée dans la barre d'outils en haut de l'écran, ce qui me permet d'économiser de précieux pixels. Redimensionner simplement une fenêtre n'est pas une bonne alternative.
Références :
J'ai trouvé cette question :j'aimerais empêcher l'optimisation de couvrir un tiers de l'écran. J'ai été très déçu quand Compiz Maximumize a semblé ne rien faire du tout (il y a un bug du Launchpad :https://bugs.launchpad.net/ubuntu/+source/compiz-fusion-plugins-extra/+bug/462158).
J'ai également trouvé la même question sur superuser :https://superuser.com/questions/269966/id-like-to-prevent-maximize-from-covering-one-third-of-the-screen, qui propose deux alternatives. Le plugin Compiz Grid n'aide pas car il ne maximise pas, comme je l'ai décrit ci-dessus. Je n'ai pas essayé l'organisateur de fenêtre Python, mais il ressemble à Grid. En général, je ne m'attends pas à ce que des scripts intelligents aident, car la signification de "maximiser" est contrôlée par le gestionnaire de fenêtres lui-même, et donc la solution devrait être une solution Compiz. Y en a-t-il un ?
Réponse acceptée :
Permettez-moi de répondre à ma propre question; la réponse est bizarrement impliquée. L'astuce est que le comportement de bureau souhaité (qui existait dans la version 10.04) est désormais (dans la version 11.04) contrôlé par Compiz, qui a une notion de "sorties", c'est-à-dire des écrans sur lesquels dessiner. Ceux-ci sont configurés dans le CompizConfig Settings Manager (package compizconfig-backend-gconf ou -kconfig ), dans le menu "options générales", sous l'onglet "Paramètres d'affichage".
Cette chose a trois paramètres, qui sont tous importants. Le plus important est "Détecter les sorties" :cela doit être décoché, car le but est que je souhaite créer une configuration d'écran non physique, alors que la détection automatique ne prendra que la taille de mon écran.
Le deuxième plus important est la case "Sorties", qui est une liste de résolutions. À première vue, vous pouvez vous attendre à ce que la chose à mettre ici soit "1024 × 768", mais c'est faux :il indique à Compiz d'utiliser tout l'écran virtuel, de sorte que les fenêtres maximisées couleront vers le bas ; c'est le mauvais comportement. Mais écrire « 1024×600 » ne fonctionne pas non plus, puisque cela dira à Compiz de prétendre que l'écran ne fait que 600 pixels de haut; le résultat contre-intuitif est donc qu'il décide de s'étirer chaque fenêtre. C'est moche et non fonctionnel, provoquant des problèmes graphiques incroyables et, mystérieusement, déplaçant les boutons de l'endroit où vous devez cliquer pour les activer. Pas bon.
Une bien meilleure option consiste à écrire « 1024×600+0-168 », ce qui indique à Compiz qu'il y a en fait 168 pixels inutilisés en bas :cela reproduit le comportement de « barre noire » dont je me plaignais. C'est bien de savoir d'où ça vient, mais je n'en veux toujours pas. Mais cela me dit ce que cela signifie :cela signifie que Compiz ignore simplement ces pixels :il n'y dessinera pas de fenêtres. Ma souris va toujours là, cependant, parce que ce comportement est contrôlé par X, qui vient avant Compiz. Il semble que la chose à faire est en quelque sorte de dire à Compiz de dessiner là (pour que Windows peut y aller) mais aussi de ne pas y dessiner (pour qu'ils ne veuillent pas pour y aller).
La solution tout à fait correcte est donc de décrire deux périphériques de sortie vers Compiz :un "1024 × 600 + 0-168" et un "1024 × 768", indiquant ainsi à Compiz de dessiner et de ne pas dessiner sur ces pixels du bas, en même temps. Mais comment s'assurer qu'il sait lequel « vouloir » ? C'est la première option de cet onglet :"Gestionnaire de sortie superposée". Réglez-le sur "Préférer une sortie plus petite", ce qui est exactement ce que j'ai dit en mots là-haut.
Donc la réponse :lancez xrandr --mode 1024x700 --fb 1024x768 --panning 0x768; allez dans les options d'affichage de Compiz et mettez deux sorties "1024×600+0-168" et "1024×768" ; décochez "Détecter les sorties" ; et faites en sorte que "Overlapping Output Handler" préfère les sorties plus petites. Ouf.