The $%$#%#$%# Rev Geometry

[Richard Gaskin]

stephen barncard wrote:

> Ok I've been a Rev user since 2001, and many times I've tried to use the
> geometry manager and it will work for a while, then BLAM, add or change
> something (like add a new card) , then everything to the right gets wider -
> a major mess. This happens sooner or later on EVERY stack I try to use
> geometry.
> 
> Once in a while someone will mention rev geometry on this list,  and the
> pundits will invariably say... "Geometry -- no big deal, just do it yourself
> - it's easy. Don't use Rev geometry. "
> 
> But the Rev interface has such an intuitive interface to RevGeometry, I
> really want to use it. If it's broken, how is it used? If it's in there, why
> can't I just use it?

You can, but only when it does what you want.

If you've ever set out to make a tool like the Geometry Manager, or even 
just stayed up late thinking about how you would make one, it wouldn't 
be long before you'd stumble into the reasons why such a thing can only 
be used on a subset of possible layouts.

And while it's never been prohibitively onerous to write one's own 
resizeStack handlers, with Rev 3.5 this got radically simpler:

Groups now get a resizeControl message *whenever* their rect is changes, 
*even by script*.

If a layout is complete enough to be cumbersome to write a resizeStack 
handler for, chances are some or even most of those controls exist 
within groups which act as either custom controls or panes.

With v3.5 all you need to do now is have your resizeStack handler set 
the rect for each group, and then you can write the code that adjusts 
controls within the group in the group's script itself, keeping the 
logic simple and the code portable should you decide to use that group 
elsewhere.

Sure, I like the idea of the Geometry Manager as much as the next fella, 
and it may be possible to craft a UI and supporting code that would work 
in all possible circumstances some day.  But while we wait for that 
perfect solution, when the Geometry Manaager does what you need by all 
means use it, but if you bump into one of its wall you can still move 
your work forward with the confidence that you can get optimal 
performance and precise control over every aspect of your layout in just 
a few minutes by typing a resizeStack handler.

It may seem like more work, and perhaps may be in some cases, but maybe 
it really just illustrates the differences between point-and-click 
authoring systems like IconAuthor and scripting-based systems like Rev.

Like Bill Appleton (who wrote one of the first icon-based systems, 
CourseBuilder, and later went on to write SuperCard), said of 
point-and-click authoring systems and why he abandoned CourseBuilder to 
make SuperCard, "It's just hard to be as expressive as you can be with a 
scripting language."

How much more work is it to type rather than click anyway? Consider this 
example I posted in response to David Epstein's question on the 9th 
about multi-pane UIs:

<http://fourthworldlabs.com/rev/splitter-experiment.rev>

All it does it resize four groups using two buttons as splitters. 
Simple stuff.

How long would it take to figure out how to use the GM for that?
It took only a minute or two to script.

The GM is handy for many things, but it's also good to know you can also 
handle the resizeStack message directly yourself when you need to.

Use whatever works.

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