Re: [Pan-users] Multiple displays and preferences dialog

[Duncan]

Jim Henderson posted on Fri, 15 Aug 2014 17:56:23 +0000 as excerpted:

> Running 0.140 git d447f7c built locally.
> 
> I've just upgraded to a new system and have dual monitors - they're
> arranged as follows (output taken from xrandr, unnecessary lines
> removed):
> 
> Screen 0: minimum 320 x 200, current 3840 x 2174, maximum 16384 x 16384
> 
>  DFP5 connected primary 2560x1440+0+0 CRT1 connected 1280x1024+2560+1150
> 
> So my main WHQD display is to the left and slightly above the CRT.
> 
> The preferences window spans both monitors, but because the virtual
> screen is 3840x2174, the bottom of the preferences window is off the
> bottom of the screen, and the OK button appears on the secondary display
> near the bottom of its space.
> 
> This makes the window almost entirely unviewable - it's simply too big
> to use effectively.  The shortcuts end up going past the bottom of the
> left- hand screen, so I can't edit the ones that are at the bottom of
> the list unless I drag the window over to the right-hand monitor, but
> then the top of the window is off the top of the right-hand screen, so I
> have to drag it back and forth.

Welcome to the modern multi-monitor world. =:^)

Two answers here, one pan-specific, one a general observation based on 
long-time multi-monitor experience as I've been running multiple monitors 
on my main machine since back before the turn of the century on MS.  I 
still remember adding in a second one, then a third one, shortly after MS 
Windows 98 first introduced multi-monitor feature support, and in fact 
one of the big deal factors in my switch to Linux back in 2001 was 
figuring out how to get then XFree86 configured not just to support 
multiple monitors on multiple graphics cards but to get the layout the 
way I wanted it -- it wasn't so easy back then and I had a lot of 
learning about manual configuration to do before I got it working.  But I 
did! =:^)

First the pan specific answer.  As I've long had this configured I forgot 
it was a problem and indeed didn't know it still was, but I guess so 
since it seems to be the issue you're dealing with now, and indeed, I 
just adjusted my configuration not to match and got the huge pan-prefs 
once again when I tested, so it does still seem to be a problem.

I'm not sure what desktop environment and window manager you run, but 
here it's kde and kwin, which are of course hugely configurable.  Of 
course kwin's window rules have all sorts of options to limit what's 
matched (a full tab full) to either all windows of a specific app or a 
specific window, and there's even more options (three tabs worth) on what 
behavior to either apply initially or force, for anything that matches.

What I ended up doing is setting up a kwin window rule that exact-matches 
(whole) window class "pan pan", exact-matches window role pan-preferences-
dialog, and exact-matches window title Pan: Preferences.  That limits 
that rule to matching /just/ pan-prefs (I have another for the main pan 
window, FWIW).

The only option my rule actually applies to that window is, size and 
position tab, size, force, 932,800.

Which does what I need it to do. =:^)  Hopefully whatever window manager 
you run is equally configurable.

As I said, I just tried modifying the rule so it wouldn't match (adding 
an x to one of the exact-match criteria), and launching pan prefs gave me 
a *HUGE* window again, so unfortunately I can confirm your problem, as 
you observed, apparently due to the long list of shortcuts in the 
shortcuts tab, but the good news is, assuming your window manager is 
appropriately configurable, there's a confirmed work-around as well -- 
setup a window rule to enforce the behavior you want. =:^)


Meanwhile, here's the more general xorg multi-monitor desktop observation.

In general, I've found things work /much/ better if you have access to 
the full area of the bounding rectangle of your desktop.  It's not 
absolutely necessary, but some windows simply don't behave reasonably and 
try to ignore the window manager and appear partially or fully offscreen.  
While it's certainly possible to setup window rules for each one just as 
I did above, it's generally easier to simply ensure that I can reach all 
areas of the bounded desktop rectangle.

That can be accomplished two ways.  Over a longer term and thus thru 
multiple monitor (and for laptops, full machine since the monitor's built-
in) procurement cycles, the easiest way is to simply purchase monitors 
all of the same resolution in at least one dimension, and either 
logically stack them or line them up side by side (of course with 4+,  
you can also 2x2 them, etc), so that the full desktop bounding area is 
fully displayed.  With the advent of digital displays (plasma/lcd/led) 
TVs and computer monitors are now strongly standardizing on similar 
resolutions and that becomes far easier.

This is what I've done here.  Three monitors, all standard full-HD 
1920x1080 resolution, in logically stacked config.  Two of them are 
actually a pair of same-model 42-inch (1067 mm) TVs since at that size, 
the magic of market dynamics prices TVs under monitors-only, despite the 
additional electronics included.  These are my main monitors, mounted on 
the wall in front of me, one over the other, basically sized as big as I 
could fit on that wall.

The third monitor is a 21-inch (533 mm) monitor from my previous 
generation.  Originally I simply replaced the pair of 21-inch with the 
pair of 42-inch, but since my graphics card has a third output and I 
still had the older generation monitor, I decided to buy an appropriate 
cable (display-port to DVI) and attach it too.  It's actually mounted on 
the side wall beside me, but in ordered to fully display my bounding 
rectangle, I have it configured as logically stacked on top of the 
others.  Since it's much smaller than the others and mainly serves as my 
full-monitor system status dashboard[1], such that I don't normally 
interact with anything on that monitor, the fact that it's logically 
stacked but physically to the side isn't a big disruption and is actually 
easier to deal with than would be a bounding rectangle with a missing 
quadrant, even if I configured panning.


Which brings me to full bounding rectangle coverage method #2, panning, 
which works even without same-size monitors.  If you operate at a single 
primary resolution and don't switch resolutions much, what seems to work 
best here is constraining panning to one dimension either vertically or 
horizontally, while making the other a fixed size.  In your case, a 
primarily horizontal layout, you'd make that fixed size and constrain 
panning to vertical.

As a special case of single-dimension panning you can set the desktop's 
bounding rectangle panned dimension (vertical in this case) to the same 
size as the largest monitor, so only the lower resolution ones pan.  If 
you would otherwise prefer no panning and are only using it to get full 
desktop bounding rectangle access, this works reasonably well even for 
people that find full panning uncomfortable (like motion sickness) and I 
used it myself for some time.

If you want a larger virtual desktop bounding rectangle and don't find 
full panning uncomfortable or nausea inducing as I used to, of course you 
can remove the one-dimension restraint and make the desktop as big as you 
want in both directions, with full panning in each.  If you like, you can 
still constrain the viewports to be "glued together" so they are next to 
each other in one dimension, or not.

While I don't use it with the 42-inch monitors[2], back when I had only 
the two 21-inch monitors setup, I had xrandr-based zoom-and-panning 
configured as well.  I setup a script and configured hotkeys for it so I 
could switch to for instance 960x540 per-monitor half-resolution instead 
of the full 1920x1080, while keeping the 1920x2160 full desktop 
resolution.  Panning was configured such that they panned together 
vertically, but I could pan them separately horizontally, so while they 
were always one above the other in the vertical plane, horizontally, they 
could be one on top of the other as if a single viewport, or on opposite 
sides of the desktop.

Anyway, if you'd like to compare xrandr panning notes or would like a 
copy of my xrandr script to hack on (some values are still hard-coded and 
would thus need hacked, which is why I don't use it at all these days as 
I don't really need it so it hasn't been worth the trouble worrying 
about, and I already scripted it once so I know how to do it and there's 
not the challenge of the first time, either), ask, and I can post the 
script and/or compare notes on the panning stuff as necessary.

---
[1] Full-monitor system-status dashboard, superkaramba:  Here's a 
screenshot of the full 1920x3240 desktop, showing the superkaramba 
dashboard on top, pan on the middle monitor, claws-mail feeds instance 
and firefox/aurora on the bottom, with translucent windows, etc...

http://wstaw.org/m/2013/05/11/duncan-fullscreen.png

(I had a full description of each graph in my first draft, but decided 
that was too much, too far OT.  If someone's interested tho, I can post 
it.)

[2] Don't use:  While I no longer use xrandr based resolution-zooming and 
panning, kwin has a similar opengl-based zoom/pan feature which I still 
use.  With the smaller monitors I'd use either kwin/opengl zooming or 
xrandr/resolution zooming depending on the situation, as resolution 
zooming wasn't quite as CPU/graphics intensive but of course resulted in 
larger logical pixels so could look blocky, while opengl based zooming 
eliminated the blockiness but used more CPU/GPU and could blur.  But Mesa/
OpenGL and the in-kernel radeon drm drivers have progressed since then so 
the CPU/GPU usage isn't a big issue any more, and with the bigger 
monitors at the same resolution, blockiness is a bigger problem, so 
kwin's opengl-based zooming tends to be the better option now, and I 
pretty much only use native resolution these days, only switching to non-
native when experimenting or to verify functionality for a post.

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