xprop not returning some properties

millus · 2021-02-01 13:39:51

xprop on my arch/xfce4 system does not return _NET_WM_USER_TIME. It only shows this when I run it in interactive mode to click on a window, and even then for some windows it shows for others not.
But if I call it from script with xprop -id .... it will never show the property! Any idea how to fix it?

My goal is to make a script that returns focus from currently focussed window to the previously focussed window. Just sending alt+tab with xdotool will not do, because the user might at the same time be holding alt and or ctrl down to execute a key combo of his own, which would collide.
It WOULD be an option if xdotool (or some other thing I could use in a bash script) could somehow query the current shiftkey state, mainly of ALT and CTRL being held down or not, but from googling a lot it seemed to me the answer is always "not possible".

Last edited by millus (2021-02-01 13:56:19)

seth · 2021-02-01 14:29:53

https://specifications.freedesktop.org/ … 2973015584

_NET_WM_USER_TIME
_NET_WM_USER_TIME CARDINAL/32
This property contains the XServer time at which last user activity in this window took place.
Clients should set this property on every new toplevel window (or on the window pointed out by the _NET_WM_USER_TIME_WINDOW property), before mapping the window, to the timestamp of the user interaction that caused the window to appear. A client that only deals with core events, might, for example, use the timestamp of the last KeyPress or ButtonPress event. ButtonRelease and KeyRelease events should not generally be considered to be user interaction, because an application may receive KeyRelease events from global keybindings, and generally release events may have later timestamp than actions that were triggered by the matching press events. Clients can obtain the timestamp that caused its first window to appear from the DESKTOP_STARTUP_ID environment variable, if the app was launched with startup notification. If the client does not know the timestamp of the user interaction that caused the first window to appear (e.g. because it was not launched with startup notification), then it should not set the property for that window. The special value of zero on a newly mapped window can be used to request that the window not be initially focused when it is mapped.
If the client has the active window, it should also update this property on the window whenever there's user activity.
Rationale: This property allows a Window Manager to alter the focus, stacking, and/or placement behavior of windows when they are mapped depending on whether the new window was created by a user action or is a "pop-up" window activated by a timer or some other event.
_NET_WM_USER_TIME_WINDOW

_NET_WM_USER_TIME_WINDOW WINDOW/32
This property contains the XID of a window on which the client sets the _NET_WM_USER_TIME property. Clients should check whether the window manager supports _NET_WM_USER_TIME_WINDOW and fall back to setting the _NET_WM_USER_TIME property on the toplevel window if it doesn't.
Rationale: Storing the frequently changing _NET_WM_USER_TIME property on the toplevel window itself causes every application that is interested in any of the properties of that window to be woken up on every keypress, which is particularly bad for laptops running on battery power.

The optional property does NOT reflect the last time the window had the focus.
You want to track _NET_ACTIVE_WINDOW on the root window (eg. xprop -spy it)

millus · 2021-02-01 15:04:56

Ah thanks, seems the root window is the key. I'm checking the xprop -root now and reverse its NET_CLIENT_LIST_STACKING(WINDOW) which contains the z-order in reverse basically, so I can just iterate through it backwards to find the previously focussed window!
Only thing to watch out for is that I have to skip any window that isn't exclusively on the current workspace (ie that has desktop -1 in wmctrl), such as xfce4-panel. Working fine so far!

Edit:
Arggh darn, xfce4 sometimes messes up and the NET_CLIENT_LIST_STACKING suddenly has wrong z-order that never happened like that. Why is everything so difficult and unreliable -_-

I will try the NET_ACTIVE_TIME specifically next.

Last edited by millus (2021-02-01 15:17:13)

seth · 2021-02-01 15:26:34

The stacking order does NOT reflect the focus chain either - a window can be on top of the stack w/o having the focus and the previously focused window doesn't take the 2nd stack position for sure either (it reflects the z-index of windows)

Arch Linux

#1 2021-02-01 13:39:51

xprop not returning some properties

#2 2021-02-01 14:29:53

Re: xprop not returning some properties

#3 2021-02-01 15:04:56

Re: xprop not returning some properties

#4 2021-02-01 15:26:34

Re: xprop not returning some properties

Board footer