Determining the "parent" process of a window on the screen

[Norm Dresner]

Situation:
I've got a bunch of programs running - some of which are proprietary
stuff from external sources that are poorly documented -- and a window with
a diagnostic pops up on the screen. It contains a notification of an error
condition, but does not identify which process/program put that window up.
I could probably start nuke-ing processes one by one until the window
vanishes but there's got to be a more elegant way to do this. Is there a
standard X-Window utility I've missed or a Q&D program I could write to
identify the parent process of a window?

TIA
Norm

[Chuck Dillon]

Post by Norm Dresner
I've got a bunch of programs running - some of which are proprietary
stuff from external sources that are poorly documented -- and a window with
a diagnostic pops up on the screen. It contains a notification of an error
condition, but does not identify which process/program put that window up.
I could probably start nuke-ing processes one by one until the window
vanishes but there's got to be a more elegant way to do this. Is there a
standard X-Window utility I've missed or a Q&D program I could write to
identify the parent process of a window?

Use xprop to look at the properties set on the dialog/alert. The ICCCM
properties might/should give you a hint and might lead you to the app's
main window. For example, I have an xemacs running on a Solaris box.
I edited a buffer and then selected to delete that buffer without
saving. I got an alert asking if I wanted to save the contents blah,
blah....

I went to a dtterm and ran xprop (standard X11 app), which changes the
pointer and lets me click on the window to report on. I click on the
alert and get...

***@xxxx(62)> xprop
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_DT_WORKSPACE_PRESENCE(_DT_WORKSPACE_PRESENCE) = 0xc6
WM_TRANSIENT_FOR(WINDOW): window id # 0x4400037
_MOTIF_WM_MESSAGES(ATOM) = _MOTIF_WM_OFFSET
WM_PROTOCOLS(ATOM): protocols _MOTIF_WM_MESSAGES, WM_DELETE_WINDOW
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x4, 0xffffffff, 0xffffffff, 0x0, 0x69
WM_CLIENT_LEADER(WINDOW): window id # 0x4400012
WM_CLASS(STRING) = "dialog", "Emacs"
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
window id # of group leader: 0x4400037
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified location: 341, 317
program specified size: 549 by 110
program specified minimum size: 549 by 110
window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "xxxx"
WM_NAME(STRING) = "Question"


Note that WM_CLASS gives me a solid hint. Also under WM_HINTS the last
entry shows a "group leader". If I do: xprop -id 0x4400037, I get...

***@xxxx(63)> xprop -id 0x4400037
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x2c00387
_DT_WORKSPACE_PRESENCE(_DT_WORKSPACE_PRESENCE) = 0xc6
_MOTIF_WM_MESSAGES(ATOM) = _MOTIF_WM_OFFSET
WM_PROTOCOLS(ATOM): protocols _MOTIF_WM_MESSAGES, WM_DELETE_WINDOW,
WM_TAKE_FOCUS
WM_CLIENT_LEADER(WINDOW): window id # 0x4400012
WM_CLASS(STRING) = "emacs", "Emacs"
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
bitmap id # to use for icon: 0x4400047
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 663 by 685
program specified minimum size: 103 by 100
program specified resize increment: 8 by 15
program specified base size: 23 by 85
window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "xxxx"
WM_ICON_NAME(STRING) = "culib.c"
WM_NAME(STRING) = "emacs: /usr/local/bin/xemacs [21.1 (patch 13)
\"Crater Lake\" XEmacs Lucid] culib.c"

Which is the top level window of the XEmacs program.

HTH,

-- ced

[Norm Dresner]

Post by Chuck Dillon

Post by Norm Dresner
I've got a bunch of programs running - some of which are proprietary
stuff from external sources that are poorly documented -- and a window with
a diagnostic pops up on the screen. It contains a notification of an error
condition, but does not identify which process/program put that window up.
I could probably start nuke-ing processes one by one until the window
vanishes but there's got to be a more elegant way to do this. Is there a
standard X-Window utility I've missed or a Q&D program I could write to
identify the parent process of a window?

Use xprop to look at the properties set on the dialog/alert. The ICCCM
properties might/should give you a hint and might lead you to the app's
main window. For example, I have an xemacs running on a Solaris box.
I edited a buffer and then selected to delete that buffer without
saving. I got an alert asking if I wanted to save the contents blah,
blah....

Sounds promising. I'll give it a try the next time it happens.

Thanks
Norm

[wbe @ubeblock.psr.com.invalid (Winston)]

... a window with a diagnostic pops up on the screen. It contains a
notification of an error condition, but does not identify which
process/program put that window up.

If the number of candidate parents is small, a simple way that often
works is to use your window manager to iconify the possible parent window.
If it *is* the parent, usually the dialog box will be iconified, too (and
will reappear when you de-iconify the window). If it's not the parent,
try the next candidate.
-WBE

[Norm Dresner]

Post by wbe @ubeblock.psr.com.invalid (Winston)

... a window with a diagnostic pops up on the screen. It contains a
notification of an error condition, but does not identify which
process/program put that window up.

If the number of candidate parents is small, a simple way that often
works is to use your window manager to iconify the possible parent window.
If it *is* the parent, usually the dialog box will be iconified, too (and
will reappear when you de-iconify the window). If it's not the parent,
try the next candidate.
-WBE

I'm beginning to believe that for this particular window the window manager
itself is the "parent" but I'm also interested in finding out how to do it
in general for the future.

I do know that it's not a separate process because the output of `ps aux`
doesn't change when I dismiss the window. I'd love to see something similar
to either that or to `top` for windows.

Thanks
Norm

[Chuck Dillon]

Post by Norm Dresner
I do know that it's not a separate process because the output of `ps aux`
doesn't change when I dismiss the window. I'd love to see something similar
to either that or to `top` for windows.

xlsclients, xlswins and "xwininfo -root -tree" all give snapshots of
info for the screen. You could write a script to some combination of
them in a loop to monitor what's going on. The latter two would
probably require filtering since they are almost surely more verbose
than you need.

One other thought. Look at the man page/doc of your window manager and
see if you can configure it to bring entire window groups to the front
on command. As I indicated in my last post to this thread, by
convention dialogs belong to the "window group" of the application that
spawns them. WMs can be configured to move individual windows in the
stack and/or entire window groups. If your WM will let you do the
latter, when you see the alert/dialog you can select to bring it's
window group to the front and that should make it more clear where the
dialog is coming from.

HTH,

-- ced