On Sun, Sep 14, 2014 at 02:58:36PM +0100, Thomas Adam wrote: > On Sat, Sep 13, 2014 at 10:00:56PM +0100, Dominik Vogt wrote: > > Ah, now I know what's broken. FScreenParseGeometry returns the > > geometry relative to the global screen. When you have judt one > > screen and have +0-0@0, that translates to x=0, y=-0, YNegative > > set. When you have multiple screens, the original value is > > relative to the given screen 0. I.e. -0@0 ist identical to > > -(y -(highest_y_of_global - highest_y_of_screen_0))@g > > > > with > > > > y = 0 > > highest_y_of_global = height of the gloal screen > > highest_y_of_screen_0 = (y + height) of screen 0 > > > > That's what the code in fvwm does, but not in mvwm. > > I've just pushed a fix for this to master---please can you check this > does the right thing? It seems to for me when trying: > > Geometry 513x59+0-0 > Geometry 513x59+0-0@SCREEN_NAME
The fix works and looks good. Just two minor things: * Is there a reason why you use so many blank lines? Personally, I'd remove all of them except after the declarations and before the return. * It's not necessary to fetch the global monitor if it's not used later. I'll add a test for this. I've also pushed two more fixes, including another screen related crash fix. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
