walt posted on Sat, 04 Jul 2015 15:11:13 -0700 as excerpted: > On Fri, 3 Jul 2015 06:22:05 +0000 (UTC) > Duncan <1i5t5.dun...@cox.net> 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
