[cello-devel] Cello: defmd geometry-node ...

[Kenneth Tilton]

Frank Goenninger wrote:
> Hi Kenny,
> 
> I now have a conceptual model of a geometry-capable "view" that matches 
> the concepts of page 4 in my PPT:
> 
> (defmd geometry-node (cello-base)
> 
>   px
>   py
>   pz
> 
>   width
>   height
> 
>   ll
>   lt
>   lr
>   lb
>   lh
>   lw
>   l-box
> 
>   border-width
> 
>   inset-delta-left
>   inset-delta-right
>   inset-delta-top
>   inset-delta-bottom
> 
>   viewport/clipping-ll
>   viewport/clipping-lr
>   viewport/clipping-lt
>   viewport/clipping-lb
> 
>   outset-delta-h
>   outset-delta-v
> 
>   kid-spacing-h
>   kid-spacing-v
> 
>   ;; Default values
> 
>   :md-name (gensym "CELLO-GEOMETRY-NODE-")
> 
>   :px (c-in 0)
>   :py (c-in 0)
>   :pz (c-in 0)
> 
>   :border-width (c-in 0)
> 
>   :inset-delta-left       (c-in 1) ;; Should be at least 1 pixel to stay 
> away
>   :inset-delta-right     (c-in 1) ;; from border ...
>   :inset-delta-top       (c-in 1) ;; ...
>   :inset-delta-bottom (c-in 1) ;; ...
> 
>   ;; Values calculated for ordinary geometry-node, but most likely
>   ;; be assigned rules for specific kid handling (like justifying)
> 
>   :ll (c? (+ (^px)
>              (^border-width)
>              (^inset-delta-left)))
>   :lt (c? (+ (^py)
>              (^height)
>              (- (^border-width))
>              (- (^inset-delta-top))))
>   :lr (c? (+ (^px)
>              (^width)
>              (- (^border-width))
>              (- (^inset-delta-right))))
>   :lb (c? (+ (^py)
>              (^border-width)
>              (^inset-delta-bottom)))
> 
>   ;; Calculated values
> 
>   :lh (c? (l-height self))
>   :lw (c? (l-width self))
> 
>   :viewport/clipping-ll (c? (+ (^px)
>                                (^border-width)
>                                (^inset-delta-left)))
> 
>   :viewport/clipping-lr (c? (+ (^px)
>                                (^width)
>                                (- (^border-width))
>                                (- (^inset-delta-right))))
> 
>   :viewport/clipping-lt (c? (+ (^py)
>                                (^height)
>                                (- (^border-width))
>                                (- (^inset-delta-top))))
> 
>   :viewport/clipping-lb (c? (+ (^py)
>                                (^border-width)
>                                (^inset-delta-bottom)))
> 
>   :l-box (c? (make-lbox (^ll) (^lr) (^lt) (^lb)))
> 
>   )
> 
> The default way is to give px, py, width, height to a make-instance call 
> and the view is establish with all boundaries in place. It is possible 
> to specify a border width which affects the inner area in which the 
> contents may be drawn. The default cells rules are specified to move the 
> content drawing origin as soon as a border width change occurs.
> 
> The viewport/clipping stuff establishes the rectangle that is the 
> remaining drawing area (no drawing outside of this area allowed).
> 
> Inset-delta-... let's one specify distances between border and content 
> that must be kept even if the content is "growing" or changes its 
> drawing origin.
> 
> As we have cells rules in all those places any subclass is free to 
> change these rules to match container of kids, justification and 
> dynamically sized controls based on kids etc.
> 
> On to Outset - strictly according to the master's voice ;-)
> 
> BTW on page 4 of the PPT there is a poing P4 which is a non-zero ll / lb 
> control content.
> 
> As for diagramming ... I'm a bit lazy currently - as it keeps me 
> creating paper and not code.... Not that I might not do a further 
> diagram and ask for feedback ;-)

Understood. Those diagrams obviously took a lot of work, I felt bad 
raining on the parade. But here I go again:

I learned the hard way not to do seemingly plausible default rules. Now 
some of the ones I see above are tautological and might be OK (except 
for the runtime cost), but I also see things like all three of lL, lR, 
and lWidth. I have done that as well and regretted it.

With the default rules I found they would do the wrong thing and I would 
forget they were there and it would take me forever to figure out 
exactly where my geometry was going wrong. If instead I defaulted to nil 
I would quickly crash and burn if I neglected to specify a value (tho 
even there I ended up adding some debugging code to figure out exactly 
which of the six geo params was causing the "can't do arithmetic with 
nil" error. What I also saw was that it was not all that hard to specify 
all six, esp. since I rarely specify px/py (it's all stacks and rows for 
me, and those take care of px/py). Other widgets get their bounds from 
their class definitions (like a text label automatically sized to font 
and string content).

As for having lr, ll, and lwidth, the redundancy got in the way 
sometimes and if I wanted to specify a width I just said:

    :lR (c? (+ (^lL) <the width I want>))

Final thought: all those rules will be running all the time, needed or not.

Of course you have all that code there so go for it, maybe just watch 
out for these issues and cut your losses if you start to run into them 
yourself.

kt