On Thu, Sep 11, 2014 at 11:30:40PM +0100, Dominik Vogt wrote:
> On Thu, Sep 11, 2014 at 11:10:38PM +0100, Thomas Adam wrote:
> > On Thu, Sep 11, 2014 at 11:07:57PM +0100, Dominik Vogt wrote:
> > > On Thu, Sep 11, 2014 at 12:48:50PM +0100, Thomas Adam wrote:
> > > > On Thu, Sep 11, 2014 at 01:14:54PM +0200, Dominik Vogt wrote:
> > > > > 3) Expansion of variables does not work as expected:
> > > > >
> > > > > All (MvwmButtons) $[w.x] $[w.y] $[w.desk]
> > > > >
> > > > > yields x=0, y=4 and desk=1024 which is all nonsense.
> > > >
> > > > Indeed. I've a fix for this, will push it shortly.
> > >
> > > If you have a fix, please push it as soon as possible. It makes no
> > > sense for me to debug my new-parser branch without that fix, and I
> > > already know that I've broken some things.
> >
> > Literally just pushed a fix for this: 19b835676
> >
> > Please check this; it should solve the weird expansion problems you've
> > been having.
>
> Yes, this looks good now. With that fix I can now debug the
> buttons placement problem. It turns out that the module window
> ends up at y = -61 instead of y = screen height - 61. That sounds
> like with the XRandR patch, negative coordinates are now taken
> literally. Coordinates actually schould mean:
>
> x/+x -> 0 + x
> +-x -> 0 - x
> -x/-+x -> screen size - window size - x
> --x -> screen size - window size + x
>
> Since the Move command works fine, it's possibly caused by
> MvwmButtons' parsing of the geometry option.
Are you looking into this, or would you like me to? ISTR that
MvwmButtons will try calling libs/FScreen.c:FScreenParseGeometry() --
it's entirely possible that's returning a slightly different value now.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
