As Jeff noted, PID and Window ID are different things, and there isn't always an easy way to map one to another — some processes have no window, some processes share a window, and others still have many windows (at least they do at the X level, even if you only see a single window).
When I start
gedit I have one visible window, but 3 discrete X Windows (
xwininfo -root -tree -all) with name or class "gedit", one of which is a window manager window (I use fvwm2, yours may differ), and one of which is the "client leader", along with up to 20 other anonymous "windows" which are really parts of the user interface (depending on
gedit version, number of tabs, and GTK+).
To partly solve that coordination problem you can use properties
WM_CLIENT_LEADER, these should hold the PID of the owning process, and leader ID where there are multiple windows (though the latter is really for session management, it might be helpful here). Now, there may some problems with
_NET_WM_PID, it requires that processes and the window manager behave correctly, but in general, on a modern desktop, this should be reliable (with the exception of a few old programs like
rxvt). Think of properties like environment variables, it should be set to the PID, but nothing enforces this, though some WMs are more proactive than others about this I believe.
Ordinarily, for this type of problem, you would write a short script that would enumerate the windows for
gedit, query the
_NET_WM_PID property in a loop for the PID of the process you just started, then set the property. However, everything will conspire against you:
- there is no X property with the Window ID in it
xprop oddly lacks the ability to output the ID of a window that you query
- the window name changes depending on what
xprop doesn't support wildcard/patterns, and won't match by window class
xprop only output the first window that matches (e.g. by
-name) rather than all of them, and neither make it easy to parse the output
- the number of X "windows" can exceed the number of visible windows by a factor of 50
gedit runs by default as a single process, so if you start a second
gedit that process exits as soon as it has made contact with the main process. However, on recent versions, you can use
gedit -s to run independent processes/windows.
This is the reason that utilities like
wmctl exist ;-) Unfortunately, not even any of those do exactly this without help.
If you are running standalone instances, this will do the trick, as a shell script so it's understandable (and supports filename arguments):
gedit -s "$@" &
_wid=$(xdotool search --sync --onlyvisible --pid $_pid)
xprop -f MY_VAR1 8s -set MY_VAR1 MyCustomVar -id $_wid
# xprop -id $_wid MY_VAR1 ## for testing
xdotool to do the heavy lifting, in "sync" mode to give the window time to start up and set properties, and with
gedit -s so the process is standalone and long-lived and doesn't just hand over to an existing instance and then disappear (leaving
xdotool hanging around).
Or an equivalent one-liner:
gedit -s & xdotool search --sync --onlyvisible --pid $! |
xargs -r xprop -f MY_VAR1 8s -set MY_VAR1 MyCustomVar -id
xdotool can search by PID, it can also set a few properties by name, but cannot set arbitrary property names as required
xprop has poor search and output options
xdotool outputs decimal windows IDs,
xprop accepts either decimal or hex
- there's not much error handling
You could do this without
xdotool, but you'd likely end up with a convoluted mess that needs to list every window on the system and process each one in turn. I tried, it's just too ugly to paste here :-)
For an alternative approach: a standard GTK+ client allows you to set properties via command-line options, even if the application doesn't document them (
gedit --help-gtk). Sadly not arbitrary properties, but you can set the "Class" to any arbitrary string. Since the class is a multi-valued property each window will still have the "gedit" class (so settings/resources will still apply to it, if selected that way, but it can prevent "Gedit" settings being applied, though that can be an advantage too).
$ gedit --class MyCustomVar
$ xprop -notype -name gedit WM_CLASS _NET_WM_PID
WM_CLASS = "gedit", "MyCustomVar"
_NET_WM_PID = 1517
WM_NAME = "gedit"
There are a couple of other options for window/process mapping (ferreting in
WINDOWID, though this only works for processes started by terminal emulator that observes that convention; or possibly write a
gedit plugin ) but neither is appealing. See also https://stackoverflow.com/questions/151407/how-to-get-an-x11-window-from-a-process-id - one of the more interesting answers there has a link for an
LD_PRELOAD hack to wrap
XCreateWindow() and a couple of other API functions to set arbitrary properties.