Alternatively, is there any other way to get the WindowID of the DOSBox window?
(That's what this is actually about...)
Alternatively, is there any other way to get the WindowID of the
DOSBox window? (That's what this is actually about...)
xwininfo and click on the window in question?
Yes, that works - which deepens the mystery as to why xlsclients
doesn't work!
But, note that in my actual use case, using xwininfo would defeat the purpose, since the goal is to figure out the WinID programmatically,
without any user interaction.
xlsclients with the -l option does that - in most case, just not for DOSbox.
gazelle@shell.xmission.com (Kenny McCormack) asked:
Alternatively, is there any other way to get the WindowID of the
DOSBox window? (That's what this is actually about...)
xwininfo and click on the window in question?
-WBE
gazelle@shell.xmission.com (Kenny McCormack) asked:
Alternatively, is there any other way to get the WindowID of the
DOSBox window? (That's what this is actually about...)
to which I replied:
xwininfo and click on the window in question?
gazelle@shell.xmission.com (Kenny McCormack) replied:
Yes, that works - which deepens the mystery as to why xlsclients
doesn't work!
But, note that in my actual use case, using xwininfo would defeat the
purpose, since the goal is to figure out the WinID programmatically,
without any user interaction.
xlsclients with the -l option does that - in most case, just not for DOSbox.
Does xlsclients -a -l work any better?
Alternatively, is there any other way to get the WindowID of the
DOSBox window? (That's what this is actually about...)
But, note that in my actual use case, using xwininfo would defeat
the purpose, since the goal is to figure out the WinID
programmatically, without any user interaction.
xlsclients with the -l option does that - in most case, just not for
DOSbox.
Does xlsclients -a -l work any better?
Nope. Tried that.
Note, BTW, that what this is probably going to boil down to is that
DOSBox is an SDL window and that, for whatever and sundry reason(s),
SDL windows aren't like normal windows (and thus for whatever reason,
don't show up in xlsclients). I'm pretty sure that that's what's
going to come out of this...
I've used X, but don't know DOSBox, so can't help there.
The only other suggestion that comes to mind is to compare the output of >xwininfo for the DOSBox window with the output for the other windows and
see if any differences help explain what's happening.
But, note that in my actual use case, using xwininfo would defeat the purpose, since the goal is to figure out the WinID programmatically,
without any user interaction.
Note, BTW, that what this is probably going to boil down to is that DOSBox
is an SDL window and that, for whatever and sundry reason(s), SDL windows
aren't like normal windows
(and thus for whatever reason, don't show up in
xlsclients). I'm pretty sure that that's what's going to come out of this...
Kenny McCormack wrote:
Note, BTW, that what this is probably going to boil down to is that DOSBox >> is an SDL window and that, for whatever and sundry reason(s), SDL windows >> aren't like normal windows
They might be override redirect windows. If you have window id, then >"xwininfo -id <id>" will tell you this under "Override Redirect State".
(and thus for whatever reason, don't show up in
xlsclients). I'm pretty sure that that's what's going to come out of this...
But, shouldn't "xwininfo -root -tree" display those windows as well?
Kenny McCormack wrote:
In article <slrnp3ijjq.rtv.dave@fly.srk.fer.hr>,
Drazen Kacar <dave@fly.srk.fer.hr> wrote:
But, shouldn't "xwininfo -root -tree" display those windows as well?
Yes, that works! That seems to be the "-a" or "-all" option I had
longed for earlier. So, yeah, parsing the output of that command should
work as well. Still leaves open the question of why "xlsclients" doesn't >> do it...
Maybe xlsclients displays an item only if it has WM_CLASS and/or WM_NAME >property. So start xprop, click on your SDL window and check the
properties on the window.
In article <slrnp3ijjq.rtv.dave@fly.srk.fer.hr>,
Drazen Kacar <dave@fly.srk.fer.hr> wrote:
But, shouldn't "xwininfo -root -tree" display those windows as well?
Yes, that works! That seems to be the "-a" or "-all" option I had
longed for earlier. So, yeah, parsing the output of that command should
work as well. Still leaves open the question of why "xlsclients" doesn't
do it...
In comp.windows.x, Kenny McCormack <gazelle@shell.xmission.com> wrote:
But, note that in my actual use case, using xwininfo would defeat the
purpose, since the goal is to figure out the WinID programmatically,
without any user interaction.
I note you have solved it using a complex pipeline, but another option
that may work is using something like xdotool to find the window under
the mouse pointer. I've done this in a screenshoting tool, so I can feed
in the window id to xwd and not have the mouse click.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 335 |
Nodes: | 16 (2 / 14) |
Uptime: | 150:00:05 |
Calls: | 7,411 |
Calls today: | 1 |
Files: | 12,670 |
Messages: | 5,613,273 |