ambassador at fourthworld.com
Wed Jan 20 14:52:51 CST 2010
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
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
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
More information about the use-livecode