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
