Why RationalRects for floating windows?

Hi folks, I'm wondering whether anybody can enlighten me why the geometry of a floating window is stored as a RationalRect relative to the screen size. I can see one advantage to this approach: a centered window is centered on every screen. Apart from that, I see only disadvantages to this approach, as it means that windows get resized when workspaces shift between screens of different sizes. If at least the aspect ratios of all screens are the same, this may be acceptable, though not ideal. My newest setup combines two portrait screens (1080x1920) with two landscape screens (1920x1080). A window that has a reasonable geometry on one of the landscape screens now gets long and skinny on the portrait screens. I'd also appreciate any ideas on how to work around this issue, as I think changing the way xmonad stores information about floating windows would just break too many modules and thus isn't an option. Thanks, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Quoting Norbert Zeh
I'm wondering whether anybody can enlighten me why the geometry of a floating window is stored as a RationalRect relative to the screen size. I
I expect this is so that various functions can choose rectangles without knowing the size of your screen. e.g. you don't need to know the screen is 1024x768 to make a fullscreen window. I also suppose there's probably times when you want to deal with a RationalRect and times when you want to deal with a more concrete, screen-based rectangle, and that the only right solution will involve keeping both representations (and making sure they're in synch). ~d

wagnerdm@seas.upenn.edu [2012.01.04 1322 -0500]:
Quoting Norbert Zeh
: I'm wondering whether anybody can enlighten me why the geometry of a floating window is stored as a RationalRect relative to the screen size. I
I expect this is so that various functions can choose rectangles without knowing the size of your screen. e.g. you don't need to know the screen is 1024x768 to make a fullscreen window.
I also suppose there's probably times when you want to deal with a RationalRect and times when you want to deal with a more concrete, screen-based rectangle, and that the only right solution will involve keeping both representations (and making sure they're in synch).
Thanks, Daniel. That's a good point. I was toying with your idea of keeping both representations and using only the one you want when you need it. I liked it above all because it wouldn't break any existing stuff - it simply wouldn't use the physical rectangles that now also get stored. The main problem I still wasn't able to overcome (and I'm not sure it can be overcome without changing some behaviour while not changing the interface) is which of the two pieces of information has precedence when I move floating windows between screens of different sizes. When this happens, we would either have to assume the RationalRect is correct and update the absolute rectangle accordingly (in which case there is no point in storing the latter in the first place), or we have to do the opposite (in which case there really isn't any point in storing the former). Note that storing an absolute rectangle wouldn't really remove the ability to specify RationalRects in, say, ManageHooks because they are used only when the window is created, at which point we could do a one-time conversion to absolute coordinates. I still don't like breaking behaviour that users may have come to rely on. I think I'll for now tinker with implementing a log hook that updates the stored RationalRect according to some user-specified rules when the windows moves between screens. Cheers, Norbert
~d
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

On 01/05/2012 08:11 AM, Norbert Zeh wrote:
I think I'll for now tinker with implementing a log hook that updates the stored RationalRect according to some user-specified rules when the windows moves between screens.
+1... :) Something that feels similar to the managehook selectors would be familiar... It's certainly a subject of cognitive dissonance to have to resize over and over again. - Allen S. Rout

Allen S. Rout [2012.01.05 1245 -0500]:
On 01/05/2012 08:11 AM, Norbert Zeh wrote:
I think I'll for now tinker with implementing a log hook that updates the stored RationalRect according to some user-specified rules when the windows moves between screens.
+1... :)
Something that feels similar to the managehook selectors would be familiar...
Indeed.
It's certainly a subject of cognitive dissonance to have to resize over and over again.
Well, I always tell people that a mouse (or tablet) is that dust-covered thing at the edge of my desk to be used for drawing. For everything else there's the keyboard. Having layout issues taken care of for us by the window manager is the main reason we use xmonad. So manually resizing windows when they shift to a different workspace is simply not an option at all. My current workaround for my scratchpads is to use them only on screens where their aspect ratio is right, but that's really only a workaround. N.
participants (3)
-
Allen S. Rout
-
Norbert Zeh
-
wagnerdm@seas.upenn.edu