0

I tried this:

xprop -id $(gedit & echo $!) -f MY_VAR1 8s -set MY_VAR1 MyCustomVar

Than i tried to xprop and click on the gedit window - MY_VAR1 was not present there.

So i thought maybe i should put sleep in there... i tried:

xprop -id $(gedit & sleep 5 & echo $!) -f MY_VAR1 8s -set MY_VAR1 MyCustomVar

Waited 5 seconds and tried xprop and clicked on the new window.. still nothing

Thanks

  • I'm not in front of an X11 session right now, but I suspect you're on the wrong path by trying to send a PID to xprop -id... – Jeff Schaller Nov 4 '18 at 21:11
  • @JeffSchaller i've been stuck on this for several days. now.... i have to start the program set and get that var in the same time somehow.. I have no idea what else i could do.. Thanks – masky007 Nov 4 '18 at 21:14
  • I get the feeling that you're trying to compress too many things together. Is it right that you want to (1) start gedit, then (2) use xprop on that gedit window? – Jeff Schaller Nov 4 '18 at 21:25
  • @JeffSchaller Yes, that's right! - Looking at my code i think i noticed what's my error... I try to pass the PID to xprop -id instead of the window ID - i might need to add one more nested level to extract that window ID first and pass that from the process ID... ill see if i can make it work right now! – masky007 Nov 4 '18 at 21:31
1

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 _NET_WM_PID and 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 gedit opens, xprop doesn't support wildcard/patterns, and won't match by window class
  • both xwininfo and 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 xdotool, xwit and 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):

#!/bin/bash
gedit  -s "$@" &
_pid=$!
_wid=$(dotool search --sync --onlyvisible --pid $_pid)
xprop -f MY_VAR1 8s -set MY_VAR1 MyCustomVar -id $_wid
# xprop -id $_wid MY_VAR1  ## for testing

This uses 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

Noting:

  • 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 which need 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 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 /proc/PID/environ for 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 function to set arbitrary properties.

  • You are amazing! This is much more than i asked for - i will be coming back to your answer and reread again and again to consume everything carefully – masky007 Nov 6 '18 at 1:18
  • Just out of curiosity - is this easier to do under Windows? – masky007 Nov 6 '18 at 1:20
  • Windows has the same concept, and analogous GetProp()/SetProp() API calls. As to easy, it depends what you use... I understand the "native" scripting tools tend to have limited coverage of the Win API. You might find AutoIT useful to access the API via scripting , though you'll have to import those functions via DllCall() as they're not imported by default in the current version. – mr.spuratic Nov 6 '18 at 16:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.