The Geometry Manager

[Ken Ray]

On 11/27/04 12:32 PM, "Geoff Canyon" <gcanyon at inspiredlogic.com> wrote:

>> On Nov 23, 2004, at 7:58 AM, Richard Gaskin wrote:
>>
>> 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.

Agreed. One nice thing about code is it has its own inherent sequencing -
you do line 1 first, then 2, etc. until you're done. This way, when you set
up your resizing/adjusting you put it down in the firing order you want. My
method is slightly more compact than Richard's, but it does the same thing.
I'll use conditionals as necessary, especially to restrict the resizing of
an object (for example, if the user is resizing a stack and I want an object
to have a minimum size, I will resize that object first, checking to make
sure it doesn't go below its minimum, and then will resize the other objects
accordingly. 
 
> 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.

The only one I can imagine would be one that laid down steps in a list that
it would follow, but it would just be a more readable version than what
you'd do in code. For example, you might have this in code:

  ObjRect the long id of fld 1, "","",x-200,y-20
  ObjRect the long id of fld 2, the left of fld 1,"",x-20,y-20

but in an interface it might be multicolumn and show:

  OBJECT                     ADJUSTMENTS              RELATIVE TO
  field "FirstField"         Rt: -200, Bot: -20         Stack
  field "SecondField"     Left: Match                   field "FirstField"
  field "SecondField"     Rt: -20, Bot: -20           Stack

But either way, it wouldn't be visual...


Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: kray at sonsothunder.com