https://bugs.kde.org/show_bug.cgi?id=351175

--- Comment #26 from Duncan <1i5t5.dun...@cox.net> ---
Script update: TLDR: Window selection.  Some limitations.

Window selection is the last major piece to figure out before I start putting
it all together in a proper script.

Unfortunately it's also the hardest, with plasmashell making things
particularly difficult as there's way too many windows with the same generic
"Plasma" name and "plasmashell" class and classname/wholeclass.  As I've been
experimenting today I've seen anywhere from 1-2 dozen in the list.  Years ago
there used to be window roles to sort on and panels had distinct if somewhat
generic roles such as (IIRC) panel#1, panel#2, etc, so all you had to do was
detect the role once and then match on it.  But plasma hasn't been filling in
window roles for years now, I'd guess because wayland probably doesn't have a
directly parallel concept.

The other generally characterizing aspect is the window position/size/geometry.
 But I'm getting three matching windows for that, two parents of the window I'm
targeting, too, and size/position/geometry alone isn't a safe enough exclusive
match in any case.

But a combination of the two, window name/class/wholeclass, and window
position/size/geometry, seems to do the trick at least /reasonably/ reliably.

But position/size/geometry will obviously differ by individual config.

So what I'm considering now is asking the user to pick the window so we can get
size/position at setup time, and of course again if they change their panel
position/size, but storing it in a config file so they only have to do it once
unless they do change position/size.

Then I can read the stored size info from the config at startup and fill it in
to do something like this:

xwininfo -tree -root | grep ' "Plasma": ("plasmashell" "plasmashell") *383x50'
| sed -e 's/^ *//' | cut -d' ' -f1

xwininfo -tree -root lists all windows along with their size and position. 
That's piped to grep looking for plasma windows of the specified size (or
adjust it a bit for position or both).  That should spit out the line we need,
but there will be some initial spaces that the sed eliminates, leaving the
window-id as the first space-separated field for cut to select.

After the grep but before the sed and cut the line should look like this
(variable number of initial spaces):

       0x240004d "Plasma": ("plasmashell" "plasmashell")  383x50+0+0 
+7296+2110

After the sed and cut it'll be only the 0x240004d, which is the window-ID to
feed back to xwininfo to check the mapping state to see which way to toggle it,
and then to xdotool window(un)map as described in comment #25.

The kink in this is that panel size (and therefore position) can normally
dynamically grow/shrink within min/max constraints depending on what's shown --
for panels with a systray startup a new app that adds a systray icon, for
instance, and that will often grow the systray and thus the containing panel. 
Similarly for clock displays, weather displays, etc.

The simplest way around that is to configure the panel with the same min-size
and max-size so it can't grow/shrink, which I may require at least for the
initial script posting.  There's ways around that, either finding something
else to match and potentially grepping individual window results for it, or
using something other then grep to fuzzify the size/position matching within
given constraints, but they get complicated pretty fast.

And as you can see sed's a likely dep now too, but as with grep, it's going to
be a core-system package and thus likely already installed for most distros.

Getting close now to putting all the pieces together into a postable script,
tho, even if it's going to be a bit flexibility-limited.  If you want to try
playing around with xwininfo and xdotool, along with xprop if you want a few
more matching options, better matching ideas welcome!  And of course if you
have the skills to do the real code patch and do away with the need for all
this scripting in the first place, you're /more/ than welcome to do it!

(I've not given up hope for a patch here, either, but the chances remain under
50% that I can do it, and it could well take me months of on and off work and
some chance inspiration before it clicks and I can put it all together in a
patch, even if I do ultimately do it.  But a script, while a definitely hacky
and limited workaround, may well be something I can put together, pre-post
test, and post along with instructions for others to try, by the end of the
week.)

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to