Re: [Pan-users] Body pane is wrongly resizing pan's top-level window

[Duncan]

walt posted on Sat, 04 Jul 2015 15:11:13 -0700 as excerpted:

> On Fri, 3 Jul 2015 06:22:05 +0000 (UTC)
> Duncan <address@hidden> wrote:
> 
>> KWin window rules:
>> 
>> Match tab:
>> 
>> Window class: substring match: "pan pan"
>> Window role: exact match: "pan-main-window"
> 
> Just curious how you came up with "pan-main-window" as the string to
> use.  Is there a kde utility that allows you to inspect a window for
> such meta-data?

[The following is for kde4.  Kde5 is out, but still pretty new, and every 
time I've tried it kwin5 has gone into a crash and respawn loop, 
apparently because it doesn't like my standard radeon turks and native 
kernel/mesa/xorg drivers.  Between that and the fact that on gentoo I 
build everything so it's not as simple as installing binaries, along with 
the fact that some files in packages in the broken kde5 and working kde4 
are named identically so cannot coexist, meaning I have to my working kde4 
every time I decide to try kde5 again, I've not gotten very far with 
kde5.  So while kde5 behavior and settings should be similar, I don't 
know how close it is to exactly as described here for kde4.  I need to 
test kde5 again one of these days as it has been a few months and a few 
releases, but...]

Yes.  The window-rule configuration itself.  =:^)

The "detect window properties" button (and related timer) let you click-
select a window, then popup a dialog with this information collected.  
You can then further configure it, in that first popup by checking the 
elements you want to match, then on the main match tab, where you can 
modify the strings and select match strictness type, as necessary.

The titlebar menu also has "quickstart" entries that preset certain 
elements and strictness for you, depending on whether you choose the 
application rule entry (application only, no role set), or the specific 
window rule entry.  Of course if you need to change the presets, you can 
do it from the window rule matching tab, either manually, or by hitting 
that detect button as described above.

>> Window type: normal window Window title: substring match: "Pan"
> 
> Wow, kde (or plasma, or whatever it's called now) has changed a *lot* in
> the last year or so.  (I installed kde/plasma on Arch in a VM so I
> wouldn't have to spend all day compiling dozens of packages.)
> 
> The reason I switched to gnome years ago was the gnome multiload panel
> applet, which allows me to see a graphical display of network traffic,
> cpu usage, memory usage, swap space and hard disk activity, all visible
> continuously in the panel.  I don't understand how anyone can live
> without it.

For sure.  I've obviously taken that to an extreme with my superkaramba 
theme, but there's general plasmoids (aka widgets) that do individual 
functions.

If you don't see a premade widget doing quite what you want, but 
superkaramba looks too complicated to setup, on kde-look.org, there's a 
plasmoid called yasp-scripted -- yet another system-monitor plasmoid, 
scripted.  Both it and superkaramba can be customized to report and/or 
graph literally anything you can get a text terminal output for, but yasp-
scripted is much simpler to setup as it lacks the layout language that 
superkaramba uses.  Instead, there's just a single stack; no horizontal 
configuration, and you configure vertical layout by simple order, so 
whatever you put first shows up on top.  To configure multiple elements 
horizontally, you add more yasp-scripted plasmoids, one for each vertical 
stack.

I was actually running (multiple instances of) yasp-scripted for quite 
some time, switching to it when I switched to kde4 as there wasn't a 
plasmoid replacement for kde3's ksystemon kicker applet, and I needed 
something I could learn fast as I was having to replace a lot of other 
kde3 stuff and learn those replacements too.  One of the screenshots is 
of my layout, and if you install it you'll actually see the setup I 
contributed, complete in its own subdir, titled "duncan". =:^)

But eventually, when I had time to actually learn it, I decided to switch 
to superkaramba as it gave me more positioning control, and I could fit 
more information in the same space.  =:^)  Additionally, superkaramba had 
built-in C++-coded sensors for some of the things I was manually
bash-scripting with yasp-scripted, so idle graphing-only CPU usage went 
down even as added more information to my dashboard. =:^)

Meanwhile, if you eventually decide to setup your own superkaramba theme 
and wish to graph memory and CPU stats as I do, I do have a couple 
patches that expose a couple more statistics as C++-coded sensors.  I 
filed a bug for it and attached the patches years ago, but superkaramba 
is apparently on essentially autopilot at this point, being maintained 
(and I believe ported to kde5 as well) by the plasma folks as there's a 
superkaramba plasmoid type available, but without a proper kde 
maintainer.  So no developer ever even commented on the bug, and it 
remains as I filed it.  Anyway, you can either search the kde bug 
database for it, or get the patches direct from me, if you're 
interested.  They add split cache and buffer stats to the memory sensor, 
and wait stats to the cpu sensor.  Otherwise you'll have to either do 
without those stats or script them, as the builtin sensors don't have 
those stats without those patches.

> Today I saw that kde has introduced equivalent gadgets available for
> installation in its own panel, so I could actually consider switching
> back to kde. I'll play with kde some more and ponder it.
> 
> Alas, I was able to configure kwin to limit the size of pan's main
> window, which worked correctly *until* I viewed one of those hinky jpegs
> and then pan did it's usual thing and resized its own window to larger
> than the screen size in spite of kwin's efforts.  I don't understand how
> this can happen, but it does.

I suspect there's a way around it.  I've never had a window that I 
couldn't make conform to my size and position wishes yet, tho some simply 
don't resize well, the widgets staying the same size and location no 
matter the window size, for instance, but I can definitely force the size.

For particularly obstinate windows, try size and position tab, ignore 
requested geometry (checked, force, yes), and/or obey geometry 
restrictions (checked, force, no).  The difference between them wasn't 
originally clear to me, but on a recent enough kde4, if you hover over 
the options, you should get a tooltip describing what each one does.  In 
general, geometry restrictions deal with requested height/width ratios, 
while requested geometry deals with size/position.  (Think of a media 
player window.  It might request a size to match the playing video, or 
perhaps double-size it, for instance.  That's requested geometry.  It may 
also ask the window manager to keep it the appropriate ratio for the 
video in question, so if you resize say vertically, it automatically 
resizes horizontally as well, to keep the video aspect ratio.  That's 
geometry restrictions.)

For this particular case, you may also want to try playing with the 
maximum size option, setting it to the resolution of your screen, tho 
it's the requested geometry and geometry restrictions options that seem 
to work for me, when forcing a size/position doesn't otherwise work.



Meanwhile, in addition to kwin's window rules, I use a number of (non-kde) 
command-line and thus scriptable tools.  While kwin's window rules work 
well if you ALWAYS want a window to behave as configured, scripting is 
nice if you want a particular behavior sometimes but not always.  You 
simply setup the script to do what you want, and then either invoke it 
manually, or setup a hotkey or the like to invoke it.  Of course, you can 
also call the script from other scripts, so you can have a script that 
quickly sets up a bunch of windows in a desired layout, by calling a 
bunch of individual scripts that setup just one window or all the windows 
for a particular app, a piece.

xwininfo: This is an xorg utility, but probably packaged separately as 
few will use it.  Its various options allow you to print out (to STDOUT, 
so run it in a terminal window to see the printout) all sorts of window 
information about a particular window.  Without a window specifier it'll 
let you select one using point and click.

xprop: Another xorg utility, this one letting you set/remove properties 
as well as view them.

wmctrl: A third party utility that lets you do all sorts of window-
manager control type stuff from the commandline.  This one's pretty easy 
to work with since it defaults to using window title matching, avoiding 
having to get the window-id using some other method first.  Or specify 
the active window, or point and click window selection works too.  You 
can move and resize windows, send them to a different desktop, close or 
minimize them, etc.  This one's much easier to script than some tools.

xdotool: This one was originally designed by a window-manager author as a 
utility to compliment his window manager.  As such, in addition to the 
usual window actions, you can set "behave" parameters that trigger on 
window entry, exit, focus, blur, etc, in which case it stays running, 
waiting for that event to trigger.  It can also be used to inject 
keyboard and mouse events using the xtest extension, and even to execute 
other commands.  It's more powerful than many tools, but of course that 
makes it more complex, as well.

sxhkd: "Simple X hotkey daemon".  This one is mostly for managing input, 
listening for one event and either converting it into another, or 
triggering some other action, much as you'd expect a hotkey daemon to 
do.  My primary use for it here is to listen for "high" mouse button 
events, basically buttons 9-20, which my xorg touchpad driver emits in 
response to various gestures (4-finger-swipe-down, or two-finger rotate, 
for instance), and convert them to something useful.


I've used the above in quite a complex of scripts, allowing me to for 
instance use the touchpad 3-finger-swipe-down triggered "mouse 
button" (button 8) to in turn trigger sxhkd, which is configured to run a 
script that checks the active window (using xprop to get its properties 
and bash code to match them against a known string), and if it is for 
instance firefox, it will run xdotool, telling it to emit the ctrl+plus 
keys, which in firefox, activates the zoom-in function.  So if I'm in 
firefox, a three-finger-swipe-down gesture zooms in whatever web page 
firefox is displaying at the moment.  If I'm in gwenview, xdotool emits a 
different key sequence, which in gwenview, returns to the start-page.  If 
I'm in a particular game, xdotool emits a whole string of keys, which in 
that game recalls a saved game and advances a turn, over and over, until 
something with a rather small percentage chance of happening, happens.  
That's actually all the apps I've setup for a particular action triggered 
by a three-finger-swipe-down at this time, but now that I have the 
scripts setup, it's easy to add more.


In the case at hand, meanwhile, you could use wmctrl, in combination with 
xprop if you wanted to test more properties and thus be sure it's the pan 
window, not just something that happens to have pan in the name, to reset 
pan to an appropriate size.

Once you had the basic script setup, you could either configure a hotkey 
to run it, thereby returning pan to a reasonable size with just a hotkey, 
whenever necessary, or setup a pan wrapper script, that started your pan 
resizing script in the background before starting pan.  In that case, 
you'd modify the resizing script to loop, sleeping for say 5 or 10 
seconds, then issuing the wmctrl command to resize pan.  If it's already 
at the target size, nothing would appear to occur.  If it's not, you'd 
only have to wait a maximum of the sleep-time, before the resizer would 
return it to the proper size.  When pan closed, the wmctrl resizer 
command would error out, and you could test for that and exit the loop 
and thus the backgrounded resizer script, when pan wasn't around to 
resize any longer.


Of course doing the resizer script thing is more work than simply setting 
kwin's window rules, but you don't have to be running kwin to use it.  In 
fact, once you have it working, it should continue to "just work", pretty 
much no matter what window manager you use, as long as it conforms to 
established window-manager standards well enough to respond to wmctrl's 
requests.

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