Provavelmente não é a resposta que você procurava:
Problemas com a combinação de Unity e wmctrl
A combinação de Unity e wmctrl infelizmente tem algumas peculiaridades, das quais o comportamento que você descreve é um.
Olhando para a sua saída
- O
65,24que você mencionou, é a largura do Iniciador Unity e a altura do seu painel. -
Na linha:
0x03400005 0 0 24 65 1111 janw_VirtualBox unity-launcherna saída de
wmctrl -lG, você pode ver que o Iniciador está posicionado emx=0, y=24, enquanto o tamanho do lançador é65 x 1111. (1111é a altura da sua tela menos a altura do seu painel)
Estritamente, o comando para colocar a janela ativa no canto superior esquerdo deve ser:
wmctrl -r :ACTIVE: -e 0,65,24,1500,550
e não:
wmctrl -r :ACTIVE: -e 0,0,0,1500,550
No entanto, isso não vai resolver o problema, simplesmente é um bug. Ainda haverá a marge que você descreve. O mesmo acontecerá quando usar xdotool (não instalado por padrão):
xdotool windowmove "$(xdotool getactivewindow)" 65 24
ou
xdotool windowmove "$(xdotool getactivewindow)" 0 0
Lendo a saída de wmctrl -dG
Olhando para o 1792x1111 in WA: 65,24 1792x1111 , você pode ver que há uma resolução de monitor de 1857 ( 65 + 1792 ) x 1135 ( 1111 + 24 ).
Nesse caso, ele corresponde exatamente aos valores em DG: 1857x1135 , já que você tem apenas uma viewport (espaço de trabalho): DG representa o tamanho total de sua área de trabalho (todas as viewports).
Resumindo
Tanto wmctrl como xdotool funcionam bem se você definir uma janela maximizada . O efeito que você descreve não ocorrerá. O Moving ou redimensionamento do Windows irá, no entanto, deixar alguns pixels tanto do launcher quanto do painel, como descrito em esta resposta. :
" A janela a ser movida / redimensionada precisa ter pelo menos alguns pixels do iniciador Unity e do painel superior. "
Além do que você descreve, outro problema que você enfrentará se começar a brincar com wmctrl e Unity é o desvio , conforme descrito em este .