If the former, when you have time, would you mind writing up a short guided tour of gui-geometry? Even if it was just to explain what all the abbreviations like :lx, :ly etc meant. Did you base it on some other framework and I could look up the docs for that? I am pretty busy, so here goes (and i will start by saying my approach translates (haha, pun unintended) nicely to OpenGLs view of coordinates, but that doc wont help). No big deal, the idea could not be simpler:
I will describe an OpenGL-like geometry in which up is positive and negative is down, the opposite of most GUIs (so be careful!). I /do/ have some support in gui-geometry for the idea that the signs for up and down may vary -- look for macros like down and up that take care of using the right sign given some global parameter I forget.
Every geometer (widget) has its own coordinate system defined by a local bounding rectangle, left top right and bottom. The word "local" gives us the "l", the individual bounds give us another l for left then r, t, and b for an end result of ll, lt, lr, and lb. We allow ll and lb to be specified because sometimes it is useful to specify negative values. ie, the origin (0 0) would not be at the bottom left corner. As an aside, i have never tried making those positive such that the origin would lie outside the bounding box, but that should be OK.
In hierachies of geometers, their geometries nest. (px py) tell us where in our parent our origin falls.
That's it!
The OpenGL tie in, by the way, is that all drawing is done relative to an abstract origin. In OpenGL I will create a chunk of code to draw the wheel of a car, standing on edge, hubcap to right, with the center of the axis running through the the hub as (0 0 0). My caller can then use glTranslate and glRotate to draw four wheels around a car, all hubcaps facing out, and even have then spinning. Likewise, all my drawing in GUIs using gui-geometry is done relative to an origin. kt