
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