I am running a game under DOSBox on a Linux desktop. But the window does
not show up in "xlsclients" - even though it does show up everywhere
else as an active window. It is on the task bar and in the Alt/Tab list.

Here is the output of "xlsclients":

$ xlsclients
MyHostName lxsession
MyHostName lxpolkit
MyHostName lxpanel
MyHostName pcmanfm
MyHostName lxterminal
$

Why doesn't the DosBox window show up in the list?

Alternatively, is there any other way to get the WindowID of the DOSBox window? (That's what this is actually about...)

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Snicker

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

-a This option indicates that clients on all screens should be
listed. By default, only those clients on the default screen
are listed.

-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ydwp1muhnf.fsf@UBEblock.psr.com>,
Winston <wbe@UBEBLOCK.psr.com.invalid> wrote:

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

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.

--

First of all, I do not appreciate your playing stupid here at all.

- Thomas 'PointedEars' Lahn -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ydshc9v3yx.fsf@UBEblock.psr.com>,
Winston <wbe@UBEBLOCK.psr.com.invalid> wrote:

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?

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...

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/DanaC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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...)

and later replied:

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.

I then asked:

Does xlsclients -a -l work any better?

gazelle@shell.xmission.com (Kenny McCormack) replied:

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.
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ydo9mxuk4k.fsf@UBEblock.psr.com>,
Winston <wbe@UBEBLOCK.psr.com.invalid> wrote:
...

I've used X, but don't know DOSBox, so can't help there.

Well, maybe you ought to check it out. It might be enlightening if you
could figure out why DOSBox (and/or SDL) windows don't show up in
xlsclients.

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.

Bingo! As it turns out, I was able to get this working, by using xwininfo
with the mouse selection method to get the actual full title of my DOSBox window, then, in my script, I can do:

# In reality, ... needs to be written out in full and it is long and weird.
set -- $(xwininfo -name "DOSBox 0.74 ..." | grep "Window id:")

which puts the window ID into $4. So, as long as the window title doesn't change (and it shouldn't...), I'm OK.

It's kind of a shame that xwininfo doesn't take some kind of wildcard or
"match beginning of string" type syntax. You have to write out the whole
darn thing - complete with spaces and everything else. It is also a shame
that xwininfo doesn't have a "-a" or "-all" option to dump them all, like xlsclients does.

Oh well, live & learn...

--
Atheism:
It's like being the only sober person in the car, and nobody will let you drive.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

WINDOW=
X=
Y=
eval $(xdotool getmouselocation --shell 2>/dev/null)

if [ "X$WINDOW" != X ] ; then
: worked
else
echo "Couldn't find window id!" >&2
exit 1
fi


But it does depend on why you want the window id.


Elijah
------
uses X and Y to optionally edit a mouse pointer into the image

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <slrnp3ijjq.rtv.dave@fly.srk.fer.hr>,
Drazen Kacar <dave@fly.srk.fer.hr> wrote:

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".

It has "Override Redirect State: no", just like all the other 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...

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...

--
This is the GOP's problem. When you're at the beginning of the year
and you've got nine Democrats running for the nomination, maybe one or
two of them are Dennis Kucinich. When you have nine Republicans, seven
or eight of them are Michelle Bachmann.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <slrnp3lils.ohi.dave@fly.srk.fer.hr>,
Drazen Kacar <dave@fly.srk.fer.hr> wrote:

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.

It has both WM_CLASS and WM_NAME. Here are the relevant lines from xprop:

WM_NAME(STRING) = "DOSBox 0.74, ...
WM_CLASS(STRING) = "dosbox", "dosbox"

The WM_NAME is the same full long string that I can feed to xwininfo.

--
Just for a change of pace, this sig is *not* an obscure reference to comp.lang.c...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <eli$1712181354@qz.little-neck.ny.us>,
Eli the Bearded <*@eli.users.panix.com> wrote:

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.

Let me put in a belated plug here for the "wmctrl" program.

I recently discovered the existence of this tool, and "apt-get install"ed
it. This is pretty slick; it does lots of things, including, with the
"-lp" option, listing your windows. It's better than xwininfo because you
can get both the WindowID and the PID. Also, the output is cleaner, so it seems safer to parse with shell tools.

I now use:

MyWindow=($(wmctrl -lp | grep "DOSBox.*MyGame"))

and get:

$MyWindow is the WindowID
and
${MyWindow[2]} is the PID

P.S. As noted, wmctrl does lots of other interesting/useful things, as well.

--
A Catholic woman tells her husband to buy Viagra.

A Jewish woman tells her husband to buy Pfizer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)