Geometry manager

Ben Rubinstein benr_mc at cogapp.com
Fri Jan 29 13:26:09 EST 2010


On 20/1/10 22:37, Bob Sneidar wrote:
> Just to weigh in, the fact that people can write their own scripts to do this should be some indication that a geometry manager CAN work for most things. Off the top of my head, it seems you would want to set and track the following things:

My view, when I abandoned the GM (which was admittedly many many many years
ago) was that an essential element of any solution is sequence; because
element A may need to be positioned relative to element B, which itself
depends on element C.  While it may be possible to encode this through a
pointy-click approach, it is certainly harder to expose (so you might be able
to set up a reasonable profile, but you can't subsequently inspect and adjust
it).  And while the GM might in principle analyse all the settings to
calculate the best sequence, I seem to recall observing experimentally that it
didn't do so.

I also think some of the issues round the GM were due to user error, which I
would naturally recast as a failure of documentation and explication: that is,
the GM encourages you to think that you could use a pane of the property
inspector on an object in a pointy-clicky way, and then you were done; whereas
in fact as development progressed you probably needed to type some magic
command (revCacheGeometry) into the message box at certain critical moments to
avoid misery.

But most of all I decided (interestingly this is parallel to the objection
many of my colleagues have to HC/Rev generally) that the pointy-clicky GM was
too obscure, and it was too hard to find get an overview of what was going on.
  I make mistakes, and I need to able to go back later, see what I
did, and change it.  Geometry management isn't really about the individual
controls (beyond the simple cases) - so it turns out to be unhelpful to have
to set it, and only be able to inspect it, control by control.


On 20/1/10 19:51, Richard Gaskin wrote:
> PS: a real time-saver for me in writing resizeStack handlers has been
> this SetRect command:

My slightly different approach is a couple of ugly commands adjustObjectPosn
and adjustObjectRect (below), which allow the layout of a bunch of controls to
be described like this:

on resizeCard
   adjustObjectRect "grc", "TabBacker",  "this card", "",     "-,-,R+1,-"
   adjustObjectRect "fld", "Report",     "this card", "",     "-,-,R-20,B-40"
   adjustObjectRect "fld", "FTPlog",     "this card", "",     "-,-,R-20,B-40"
   adjustObjectPosn "grp", "FTPlogCons", "fld", "Report",     "L,B+6,-,-"
   adjustObjectPosn "btn", "ToggleWrap", "fld", "Report",     "-,B+6,R,-"
   adjustObjectRect "fld", "FTPprogFld", "btn", "ToggleWrap", "-,-,L-2,-"
end resizeCard

That is, the commands let you set the position or rectangle of one control,
relative to another control or the card, by specifying new values for any/all
of the four edges those specifications in the form of expressions which
can include the loc (X, Y), dimensions (W, H), or rect (L,T,R,B) of the
reference control.

I'm sure more thought could make this mechanism a bit less ugly!  And the
reference control and set of expressions could be stored as properties of the
subject control - which of course is approximately what the GM does.  In some
ways the GM is more flexible (you can use different reference controls for
different edges, whereas in my model this requires two lines); in others
perhaps less so (only dynamic options is a percentage of the parent
dimension).  But for me the key thing that makes this better is having an
overview of all the layout decisions in one place - and understanding the
sequence of changes.  So in the above example, the field "Report" has its
bottom right corner adjusted relative to the card; then the group "FTPlogCons"
and button "ToggleWrap" are adjusted relative to that field.

Perhaps it's possible that there could be a perfect union: the above could
obviously be represented purely declaratively.  If the Geometry pane of the
Property Inspector wrote it's data, not into a property of the object, but of
the card, in an inspectable format, which also allowed the sequence to be
adjusted, there may be no reason why a single built-in mechanism wouldn't
suffice.  (But I'm not really sure about how we handle placed groups... which
is why at some level you have to say this is a developer product, and
developers need to take control of their work.)

Ben



on adjustObjectPosn tDstType, tDstName, tSrcType, tSrcName, tDeltas
    local tDim, X, Y, W, H, L, R, T, B, tEdge
    if tSrcName <> empty then put space & quote & tSrcName & quote \
after tSrcType -- allow us to use type of this card
    -- set up the variables X, Y, W, H, L, R, T, B
    get 0 -- explicit vars parsing error
    do ("get the loc  of" && tSrcType)
    put item 1 of it into X
    put item 2 of it into Y
    repeat for each word tDim in "Left Top Right Bottom Width Height"
       do ("put the" && tDim && "of" && tSrcType && "into " & char 1 of tDim)
    end repeat
    repeat with i = 1 to 4
       get item i of tDeltas
       if it <> "-" then
          put word i of "left top right bottom" into tEdge
          do ("set the" && tEdge && "of" && tDstType \
&& "tDstName to round(" & it & ")")
       end if
    end repeat
end adjustObjectPosn

on adjustObjectRect tDstType, tDstName, tSrcType, tSrcName, tDeltas
    local tDim, X, Y, W, H, L, R, T, B, tDstRect
    if tSrcName <> empty then put space & quote & tSrcName & quote \
after tSrcType -- allow us to use 'type' of this card
    -- set up the variables X, Y, W, H, L, R, T, B
    get 0 -- explicit vars parsing error
    do ("get the loc  of" && tSrcType)
    put item 1 of it into X
    put item 2 of it into Y
    repeat for each word tDim in "Left Top Right Bottom Width Height"
       do ("put the" && tDim && "of" && tSrcType && "into " & char 1 of tDim)
    end repeat
    do ("put the rect of" && tDstType && "tDstName into tDstRect")
    repeat with i = 1 to 4
       get item i of tDeltas
       if (it <> empty) and (it <> "-") then
          do ("put round(" & it & ") into item i of tDstRect")
       end if
    end repeat
    do ("set the rect of" && tDstType && "tDstName to tDstRect")
end adjustObjectRect






More information about the use-livecode mailing list