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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 > [EMAIL PROTECTED] > > _______________________________________________ > use-revolution mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
