Geometry manager

[Richard Gaskin]

stephen barncard wrote:
> Isn't that kind of lame that it's offered in the IDE, but the unspoken rumor
> is that it doesn't work, and we're not supposed to use it, yet no-one has
> ever given an exact reason why? What if it has been fixed, yet the
> impression persists?

One man's lame is another man's affordance.  For simple layouts the GM 
seems to work well.  Any issues folks have had with it are an 
understandable byproduct of attempting to abstractify dynamic layout 
geometry in such a generalized way.

The old THINK Class Library (how old am I that I remember that? <g>) 
included a class for managing layout geometry, and with similar results. 
It's a hard task to pull off.

Given the nearly infinite variety of ways people can arrange their 
objects, compounded by the interdependencies between them as some 
objects may be relative to others which are relative to others which are 
relative to the card bounds, building a universal tool which is always 
reliable is somewhere between too complex to be worth it and impossible.

Being a gadgeteer myself I started down that road once.  Halfway into 
that dark forest of possibilities I turned back, and have been enamored 
of the relative ease and absolute control of using resizeStack handlers 
ever since.

RunRev was more ambitious than I, and their tool does a reasonably good 
job on some types of layouts.  But since it - or any generalized tool - 
won't be able to handle every possible case I can throw at it, I think 
it's useful for people to know they have options.


> This is one aspect of programming that I would like to not hassle with.

It's not so bad:  once you get into a habit of writing resizeStack 
handlers it becomes second-nature, and takes only a minute or so for 
most layouts.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv