Would welcome hints and tips on following; I have script that grabs the WindowID and sends it vdesk. It's activated from my window ops list in twm and sends the client window over to the selected virtual desktop. winid=$(xdotool click 1 | xwininfo | ggrep -oP '(?<=id:).*?(?=")'); vdesk 1 $winid if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } Over on Arch it works a treat. On OpenBSD only some xorg apps work? (xcalc, xmag, xclipboard, xv, xfig, xpaint) but other client's windows don't. I have added a line in my script to output winid to a log file which remains empty when it doesn't work yet has the right winid when it does. Using xwininfo manually works on all windows. How would I figure out what's happening? Tnx!

Script n00b advice

cpcnw

Would welcome hints and tips on following; I have script that grabs the WindowID and sends it vdesk. It's activated from my window ops list in twm and sends the client window over to the selected virtual desktop.

winid=$(xdotool click 1 | xwininfo | ggrep -oP '(?<=id:).*?(?=")');
vdesk 1 $winid

Over on Arch it works a treat. On OpenBSD only some xorg apps work?

(xcalc, xmag, xclipboard, xv, xfig, xpaint)

but other client's windows don't. I have added a line in my script to output winid to a log file which remains empty when it doesn't work yet has the right winid when it does.

Using xwininfo manually works on all windows.

How would I figure out what's happening?

Tnx!

rvp

cpcnw Try introducing a delay; otherwise, bothxdotool and xwininfo could race trying to grab the mouse:

$ xdotool click 1 | xwininfo | awk '/id: / { print $4 }'
xwininfo: error: Can't grab the mouse.

$ xdotool sleep .5 click 1 & xwininfo | awk '/id: / { print $4 }'
0xe0000c

$

kc9udx

I'm no expert but I've played with xdotool a bit.

I may be missing something, but why not use getactivewindow?

cpcnw

First reason was that the conversion to hex added to the complexity. After that I can't remember but in any case it works so well under Arch. But only sometimes under OpenBSD.... so... why?

And yeah, I know - I could use vtwm or ctwm or fluxbox or... 🙂

It's not so much about the arrival and more about the journey 🙂

pfr

cpcnw It's not so much about the arrival and more about the journey 🙂

words to live by!

rvp I have some slight skills, yes.

That's what I call a modest understatement.

kc9udx

All I'm suggesting is that you're relying on what might be an undocumented feature. It's not obvious to me that xdotool click 1 should return the window ID.

What do you get if you do this:
xdotool click 1 xdotool getactivewindow

cpcnw

kc9udx

It's not obvious to me that xdotool click 1 should return the window ID

It doesn't on its own you are right. I am using it to provide a single click to be piped into xwininfo then using grep to extract the window ID

cpcnw

rvp funnily enough I already tried delays of up to 2 seconds with xdotool's own delay feature with no result. I can try sleep next though. Thanks for the idea. What's getting to me is that xterm and some of the older xorg apps work fine...

rvp

cpcnw I am using it to provide a single click to be piped into xwininfo [...]

You can't pipe the click to xwininfo (it just happens) and also xwininfo doesn't read stdin.

cpcnw What's getting to me is that xterm and some of the older xorg apps work fine...

Your command-line is racy, mate. And, you can't also assume that the shell will start the commands in a pipeline in strictly left to right order.

cpcnw

rvp OK I'll accept the fact that I am n00b and in school everyday. That doesn't change the fact that this does actually work. xdotool provides 1 click - xwininfo accepts it as a click - and grep gets the window ID sometimes

Sure I reckon there are better ways of doing it, and I will likely get there, but this question was more about why it only works in some cases on OpenBSD yet works all the time over in Arch? Trying to debug often results in learning other stuff too.

kc9udx

So am I correct to assume that you're using xwininfo because xdotool getactivewindow gives a decimal result in stead of hexadecimal? Surely you could use fprint to convert it, no?

Or maybe I'm not understanding the whole picture here. Why are you using xwininfo and vdesk, when all these things can be done through xdotool?

It seems to me that what you are doing could be done this simply:
xdotool set_desktop_for_window 'xdotool getactivewindow' 1
(you'll have to convert those single-quotes to back-quotes, I can't figure out how to put a back-quote in a post here)

cpcnw

kc9udx the isn't so much in the method used to get the window ID - more a case of why it only works sometimes with some windows and not others? Maybe it's me who has over complicated the method and there could well be more elegant ways of doing the same thing. That said, it does work perfectly and for a long time on Arch, just only sometimes under OpenBSD.

kc9udx

Like I tried to say earlier, I think you should be wondering why it always works in arch rather than why it doesn't always work in OpenBSD. It likely has something to do with the way xwininfo gets the window ID. There are several ways it could do this, and some of them aren't reliable.

I'm pretty sure that what you are doing is a job well suited for xdotool. I recommend to abandon trying to use those other commands. There are many ways to skin a cat. But skinning a rhinoceros and a thylacine don't have to be part of it.

cpcnw

It's all coming back to me now...

obsd$ xdotool getactivewindow
Your windowmanager claims not to support _NET_ACTIVE_WINDOW, so the attempt to query the active window aborted.
xdo_get_active_window reported an error

abandoning GNU Grep and using native awk as in rvp's example fixes the issue completely.

So, thanks for that rvp (and kc9udx 🙂 )

rvp

cpcnw abandoning GNU Grep and using native awk as in rvp's example fixes the issue completely.

I doubt if if using awk instead of GNU grep was what's responsible. As I said before, your original pipeline had races. There is really a strict ordering required here: xwininfo has to run first; then xdotool has to provide the click to select the window. This is what I've done by first starting xdotool with a delay in the background. The shell then starts the xwininfo pipeline immediately afterwards, and this whole thing then waits for xdotool to provide the click.

Just try your original pipeline repeatedly on its own to see it failing some of the time:

$ xdotool click 1 | xwininfo | awk '/id: / { print $4 }'
0xe0000c
$ xdotool click 1 | xwininfo | awk '/id: / { print $4 }'
0xe0000c
$ xdotool click 1 | xwininfo | awk '/id: / { print $4 }'
xwininfo: error: Can't grab the mouse.

In any case, this method of selecting windows is quite silly (and still potentially racy--on very slow machines). Hacking twm to provide

f.exec "cmd args %w"

to substitute the window-ID for %w shouldn't be that hard methinks.

kc9udx

I wonder why xdotool reported an error. I tried without a window manager, with ctwm, and with kde4, and all attempts worked. Granted I'm using NetBSD but that shouldn't matter, I wouldn't think.

cpcnw

kc9udx I have suspicion that twm doesn't comply with a lot of things lol!

kc9udx

cpcnw well that's it. Surprisingly though, twm supports the less recommended getwindowfocus. However, set_desktop_for_window fails. So I guess you have good reason to use the extra tools.

cpcnw

Works every time here but I get what you are saying.

Hacking twm ... shouldn't be that hard methinks

If you have the skills / experience?

Also "silly" <- you read the title of the thread right?

Thanks for you input though.

rvp

cpcnw Also "silly" <- you read the title of the thread right?

"Silly" as in: "It's terrible that there's no non-klugey way to get a window-ID in twm" , and, "Really, there should've been a %w for this right from the start".

cpcnw If you have the skills / experience?

I have some slight skills, yes.