The Geometry Manager

[MisterX]

Actually my idea of the ideal GM was a turing machine like contraption!

The script was never written but its design was
pretty close to RunRevs. The GUI too but had a bit more detail. and some
missing features... 

The script was never done since I got RunRev just as I finished the GUI.
Their design is pretty good apart from a "stuut" as they say in Brussels.

There's a GUI for it in the ControlsBrowser on MonsieurX.
It's a hidden tab in the lower part of the palette. Just add
a tab named "Geometry" to the content button's and then do the
right swaps to get it in view. (It might have moved a bit off
in relation to the splitter bar due to GM problems and not being 
readjusted lately - minor priority.)

X

> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of 
> Geoff Canyon
> Sent: Saturday, November 27, 2004 19:33
> To: How to use Revolution
> Subject: The Geometry Manager
> 
> 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
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>