How do I get lost windows back?

[Duncan]

René J.V. Bertin posted on Fri, 23 Feb 2024 15:16:20 +0100 as excerpted:

> On Thursday February 22 2024 17:56:17 Richard Troy wrote:
> 
> Hi,
> 
>>I got it that to unmap I'd need to write a C program using Xlib and call
>>XUnmapSubwindows(Display *display, Window w); Not having written an
>>Xlib-using program before - or at least not in maybe 30 years! - and not
>>feeling a need to get deep into it, is / are there a presumption(s) of
>>which window / display is/are the target if they're directly associated
>>with the code that's running the unmap call? Same goes for calling
>>XMapWindow?
> 
> Sorry, I don't get your question?
> 
> I'm having difficulties recalling in which context I have encountered
> unmap actions in existing applications. Most likely in a window manager
> I used or tested at some point, but which...
> 
> Either way, with X you need to open the correct display first (a priori
> just using the value of the DISPLAY env. variable). For the window
> things can get a bit tricky because the window manager and/or the
> xwininfo command can (apparently) hide the fact that the actual window
> you're interested in has been reparented by the window manager. You can
> see that easily by using xwininfo without arguments (and click on a
> window of interest to see what data that returns) and then look up the
> returned window id in the output of `xwininfo -root -tree -all`.
> 
> On my system, I'm seeing something like if 0x6800026 is my window of
> interest:
> 
> xwininfo: Window id: 0xf6 (the root window) (has no name)
>   Root window id: 0xf6 (the root window) (has no name)
>   Parent window id: 0x0 (none)
>      209 children:
> SNIP
>      0x2200054 (has no name): ()  832x768+0+0  +0+0
>         1 child:
>         0x2200055 (has no name): ()  832x742+0+26  +0+26
>            1 child:
>            0x6800026 "XXX — Konsole": ("konsole" "konsole")  832x742+0+0
>             +0+26
> 
> As you can see my konsole window has a grandparent that's just a bit
> higher: this is the window that includes the titlebar. The intermediate
> (parent) is probably there to allow for kwin's fancy rendering through
> the compositor but that's just a guess.
> 
> I am also guessing that you are thinking of writing a utility that works
> more or less like xkill, except that it does an unmap? If so, I'd get
> the source for xkill, make those changes and then see what the effect
> is. In principle the window manager should react appropriately to
> unmap/iconify/etc actions on the client window because the client could
> invoke those actions itself.

For X there's actually a number of comandline utilities that allow one to  
see and/or change various window properties, show/hide/move/resize/switch-
desktop/etc a window around, etc.  I routinely used them in various 
scripts I have, and while I now use wayland with its tighter security such 
that only the compositor normally has the window information and control 
now, I still use these tools and X (via xwayland) in a more limited scope 
for some things and on my remaining X apps.

Note that while the functionality of some of these tools overlap (many 
tools can be used to find and close a specific window, for instance), each 
one has unique functionality and/or is easier to work with in some 
contexts so I use them all.

Among these tools:

xwininfo: As RJVB mentioned, this can be used to find certain information 
about a window.  Tho the info this exposes I don't tend to use so much so 
I don't use this one that much.

xwinprop: Much like xwininfo this lists certain window info, but info 
that's useful in different contexts.  I'm actually more familiar with this 
than xwininfo as it gives me easier access to window class, role and 
title, which are very useful to match against when trying to find specific 
windows (maybe an app has multiple windows and you only want to deal with 
say the main window, or only certain dialog windows, or you want to be 
sure and match all firefox windows but not the text editor window where 
you're editing a firefox.txt file, so it happens to have firefox in the 
title).

xrandr: Useful for scripted changes to the desktop and/or individual 
screen sizes and positioning.

wmctrl: Often used to manage specific window sizes, mapping/unmapping 
(showing/hiding), sending windows to different desktops, etc.  Typically 
one would write a script that finds windows matching specific properties 
using xprop, then moves/sizes/shows/hides/kills/sends-to-another-desktop 
those windows.

xdotool: Similar to wmctrl in some ways but handles things a bit 
differently and can be more useful in different contexts.  In particular, 
I tend to use it to fake keyboard events and thus "type" into windows.  (I 
run an old '90s-era DOS game in DOSBox, and have a script that will send a 
particular key sequence 50 times, thus automating a game restore, advance 
a turn and try to get a 1% chance event to happen, if it doesn't try 
again... sequence.)

xshkd: "X simple hotkey daemon".  Designed to run in the background (put 
it in your autostart list so it starts with your kde/plasma session), 
listen for and trigger on specific events (hotkeys...), and then do things 
based on them.  Very useful as a hotkey "launcher", to trigger wmctrl 
scripts to move windows around, etc.  In combination with xwinprop it can 
for example test what window is active and use xdotool to send that game 
restore, turn advance sequence if it's that game, trigger the hotkeys that 
zoom in an image if it's my image-viewer or zoom the page if it's 
firefox... using the same hotkey trigger but doing something app-specific 
with it depending on what's active...

xev: Can be run from a terminal (konsole) to report what keys X actually 
sees (to then use as xshkd hotkeys for instance) when you press those 
exotic "extra" keys many keyboards have today.

evrouter: Sometimes there's no exact keyboard match for whatever keyboard 
you have, so some of its keys send events that the configured X keyboard 
doesn't actually have registered as sending any corresponding X keys.  
This can be used to listen for these unmapped events and remap them to 
something X knows about, which xshkd can in turn listen for and use as a 
hotkey...


In a non-X context but does similar things with PIDs insead of X WIDs and 
thus useful in similar scripts (find the PID of an app launched with a 
specific commandline as opposed to the same app launched with another, 
kill one while not the other, or send it some non-kill signal):

pgrep/pkill/pidwait:   Same app, callable by different names to do 
different things with the found PIDs.  Conceptually it's calling ps, 
piping the output to grep, then using that result in a call to kill, but  
doing it all with one call to one app.

killall: Somewhat less flexible than pgrep/pkill/pidwait (generally kills 
or sends signals to all instances of an app, IIRC doesn't have the option 
to search against the whole commandline not just the name), but more 
commonly already installed.  WARNING!  The BSDs apparently have a killall 
that works differently and is MUCH more destructive.

lsof/fuser:  Two different apps that can be used to find the processes 
that are holding specific files or filesystems open.  Useful for example 
when you're trying to unmount a filesystem and getting an EBUSY error 
because something's still using it -- these tools can be used to find what 
that "something" is.

(Conceptually what these tools do is grep /proc, finding the pids listed 
as having the searched command name or commandline, or holding the 
searched file(system) open, so it's possible to do the same thing 
"manually" with a properly constructed grep of /proc if you're determined 
to do it yourself.  But from a CLI/scripted perspective that's the hard 
way.  These tools make things /so/ much simpler.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman