是什么导致wmctrl窗口移动命令出现偏差

关于wmctrl

使用wmctrl（默认情况下未安装），我们可以获得有关窗口，其ID，其几何形状，它们所属的pid等信息。我们还可以使用几个命令来移动或调整窗口大小。但是，从某些方面看，它的行为似乎不合逻辑。我的问题是关于通过以下方式移动窗口wmctrl：

获取资讯

当我运行命令时：

wmctrl -lG

我得到以下图片中有关窗口的以下信息：

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

偏差

但是，下面的图片显示了窗口向下移动（准确地说是28px）。我认为原因是wmctrl 窗口移动命令是根据工作区域（屏幕减去面板高度）wmctrl -lG计算的，而命令是根据屏幕总大小计算的。然后仍然无法解释4px（面板高度为24px）。

尽管可以很好地补偿脚本中的偏差，但是我不了解原因并不令人满意，因此问题是：

造成这种偏离的确切原因是什么？

移动输出中具有确切坐标wmctrl -lG的窗口不应移动该窗口，但确实可以

在此处输入图片说明

— 雅各布·弗利姆
source

我的“前卫”解决方案是保存当前坐标，移至那些坐标，获取新坐标，减去保存的坐标以获取差异。然后将差异应用于原始坐标，然后移至调整后的坐标。这比听起来容易。

— WinEunuuchs2Unix

Answers:

发生的情况是，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），并且总宽度增加了4px（900 + 2 + 2），因为右侧边框也是2px。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

回复：@Sneetsher的提示技巧

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

— 达克斯
source

这看起来是一个很好的答案！今晚我将详细研究它。

— Jacob Vlijm

以我的理解，输出xdotool selectwindow是25166060，但是要达到的步骤是什么0x18000ec？我尝试从十六进制进行转换，但事实并非如此。

— Jacob Vlijm 2015年

的输出来自xdotool getwindowgeometry 0x18000ec返回十进制窗口ID 25166060（父级）。我只输入了十六进制值0x18000ec，以表明它不是0x04000040（子级）。顺便说一句，我只是用更简单的数字重新运行了整个测试，希望您没有看。如果您处于中间位置，请参阅以前的编辑修订。

— Daxx 2015年

@JacobVlijm，xprop似乎显示了装饰填充：_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 1, 1, 24, 6和_NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 24, 6。检查可能会有所帮助。

— user.dz 2015年

该xdotool selectwindow命令在KDE和Unity上的行为是否可能有所不同？该xdotool selectwindow命令的输出指向完全相同的窗口（-id），并且（因此）xdotool getwindowgeometry输出与相同的数据wmctrl -lG。xprop但是，正如@Sneetsher所建议的，该命令显示了_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 28, 0，这正是我手动测量的结果，并证明了答案的实质是正确的，并且它是对我的问题的完美答案。你的周到给我留下了深刻的印象。谢谢！

— Jacob Vlijm

我有同样的问题，可以找到解决方法。

情况

我的情况基于安装了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()

然后，您可以关闭窗口装饰，移动窗口并打开窗口装饰。

— 天性
source