wmctrlについて

wmctrl（デフォルトではインストールされません）、私たちは窓、自分のID、その幾何学上の情報を得ることができ、彼らは我々はまた、できるなどに属しているのpid 移動やサイズ変更、いくつかのコマンドを使用してWindows。ただし、いくつかの点で、その動作は論理的ではないようです。私の質問は、ウィンドウの移動についてですwmctrl：

情報を教えてもらう

コマンドを実行すると：

wmctrl -lG

下の図のウィンドウに関する次の情報が表示されます（ao）。

0x04200085  0 746  443  468  205  jacob-System-Product-Name Niet-opgeslagen document 1 - gedit

列3-5のジオメトリ情報は、x / y座標と幅/高さを示しています。

ウィンドウの移動/サイズ変更

これらの座標をwmctrlコマンドに入れてウィンドウを移動/サイズ変更すると、座標は変更されないため、何も実行されません。

wmctrl -ir 0x04200085 -e 0,746,443,468,205

偏差

ただし、下の写真はウィンドウが下に移動していることを示しています（正確には28ピクセル）。その理由は、wmctrl ウィンドウ移動コマンドが作業領域（画面からパネルの高さを引いたもの）でwmctrl -lG計算され、コマンドが合計画面サイズで計算されたためだと思いました。それでも4pxは説明されていません（パネルの高さは24px）。

偏差はスクリプトで十分に補正できますが、原因がわからないという事実は満足できるものではないため、問題は次のとおりです。

この逸脱の正確な原因は何ですか？

の出力で正確な座標を使用しwmctrl -lGてウィンドウを移動しても、ウィンドウは移動しませんが、実際には移動します

何が起こっているのかというと、wmctrlは装飾（つまり、タイトルバーと境界線を含まない）内のウィンドウのジオメトリを返しますが、移動にはより大きいウィンドウの位置を使用しています。

（一部のコマンド出力行が削除されました：xdotoolインストールされていない可能性があります）

$ wmctrl -lG
0x04000040  0 702  23   900  950  KMatrix dave@KMatrix: test – Konsole

$ xdotool getwindowgeometry 0x04000040
Window 67108928
  Position: 702,23 (screen: 0)
  Geometry: 900x950

次のコマンドは、対象のウィンドウを要求し、すべての装飾を含み、使用中のウィンドウテーマに応じて異なる親ウィンドウを返します。

$ xdotool selectwindow
25166060

$ xdotool getwindowgeometry 0x18000ec
Window 25166060
  Position: 700,0 (screen: 0)
  Geometry: 904x977

ご覧のとおり、これは別のウィンドウです。X位置は左から2px（702-2）で始まり、右の境界も2pxであるため、合計幅は4px（900 + 2 + 2）大きくなります。Yはより高い（存在する場合は上部の境界線とタイトルバーの上）。すべてに加えて下の境界があるため、高さは大きくなります。

wmctrlは、親ウィンドウを子ウィンドウの目的の[X、Y]位置に移動します。下の「前と後」に示すように、幅と高さが子に正しく適用されます。

$ wmctrl -lG
0x04000040  0 702  23   900  950  KMatrix dave@KMatrix: test – Konsole

$ xdotool getwindowgeometry 0x18000ec   # (PARENT)
Window 25166060
  Position: 700,0 (screen: 0)
  Geometry: 904x977

$ xdotool getwindowgeometry 0x04000040  # (CHILD)
Window 67108928
  Position: 702,23 (screen: 0)
  Geometry: 900x950

$ wmctrl -ir 0x04000040 -e 0,702,23,900,950   # <----- "MOVE/RESIZE" *****

$ wmctrl -lG
0x04000040  0 704  46   900  950  KMatrix dave@KMatrix: test – Konsole

$ xdotool getwindowgeometry 0x18000ec   # (PARENT)
Window 25166060
  Position: 702,23 (screen: 0)    <----- Desired [X,Y] applied to parent
  Geometry: 904x977

$ xdotool getwindowgeometry 0x04000040  # (CHILD)
Window 67108928
  Position: 704,46 (screen: 0)
  Geometry: 900x950               <----- Desired [W,H] applied to child

編集：追加情報。

デスクトップジオメトリ、ビューポート、ワークエリア

$ wmctrl -d    # (KDE)
0  * DG: 1680x1050  VP: 0,0  WA: 0,0 1680x1015  Desktop 1

$ xdotool -v
xdotool version 3.20140217.1

https://github.com/jordansissel/xdotool

Re：コメントの@Sneetsherヒント

$ xprop | grep FRAME
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 23, 4
_NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 23, 4

同じ問題があり、回避策を見つけることができました。

状況

私の状況は、CompizがインストールされたMate 16.04に基づいています（これにより、gtkウィンドウマネージャーがアクティブになります）。

キーバインドに接続されたスクリプトを使用して、事前定義された場所にウィンドウを配置しています。最大化オプションを使用していない場合、このスクリプトは失敗します。

分析

この問題は、設定（compiz）でウィンドウ装飾のオンとオフを切り替えることでオンとオフを切り替えることができます。

回避策

ウィンドウの装飾は、特定のウィンドウのpythonを使用してオンとオフを切り替えることができます（キーバインドを使用すると、アクティブウィンドウを使用すると便利です）。

#!/usr/bin/python
from gtk.gdk import *
import gtk.gdk
import time
import sys

w = gtk.gdk.get_default_root_window().get_screen().get_active_window()
w.set_decorations(0) #use 1 to turn on decorations
window_process_all_updates()
gtk.gdk.flush()

次に、ウィンドウの装飾をオフにして、ウィンドウを移動し、ウィンドウの装飾をオンにします。