The Geometry Manager

Geoff Canyon gcanyon at inspiredlogic.com
Sat Nov 27 13:32:56 EST 2004


On Nov 23, 2004, at 7:58 AM, Richard Gaskin wrote:

> One of the complexities in generalizing layout adjustments is, as  
> you've identified in your report, getting the firing order correct:   
> if you have objects that are placed relative to other objects, you  
> need to make sure some objects are adjusted before others.  While the  
> GM does a pretty good job at that most of the time, doing it perfectly  
> for all possible layouts requires something that approaches AI, but  
> with a custom resizeStack handler you retain total control over the  
> order in which things happen.
>
> You can save yourself some typing by reducing the number of lines in a  
> resizeStack handler with something like the handy ObjRect handler  
> described in this link, so at most you'd have only one line per  
> resized object:
> <http://lists.runrev.com/pipermail/use-revolution/2004-January/ 
> 029978.html>

Richard, I've long thought that an inherent weakness in the current  
design of the Geometry Manager is that it doesn't take into account the  
sequence in which things are resized. That's not to say that it isn't  
useful, just that there are inherent limitations. I think your post,  
cited above, makes clear what the more powerful setup would be. It  
seems to me that an interface for specifying a sequence of steps such  
as your method performs would be fairly simple to produce, but also  
largely unnecessary, in that it wouldn't be much easier to  
create/maintain than the simple list of statements you use.

I think what Xavier wants is something else again: a Geometry manager  
that functions sequentially as your method does, but also involves  
conditionals. If item x is less than y pixels wide, hide item x and  
proceed down this different path. That's beyond the scope of either the  
current GM or the simple interface to your sequential method above.

Conditionals are hard to represent graphically. It makes more sense to  
handle them in code. Your (Richard's) method, at one line per element  
resized, is about as compact as possible.

All of which is to say that I think the only reasonable way to handle a  
complex geometry involving showing/hiding objects and conditionally  
resizing others is by code. I can't imagine an interface that would  
clearly and simply allow you to specify that.

regards,

Geoff Canyon
gcanyon at inspiredlogic.com



More information about the use-livecode mailing list