From frgo at me.com Tue May 19 20:19:04 2009 From: frgo at me.com (Frank Goenninger) Date: Tue, 19 May 2009 22:19:04 +0200 Subject: [cello-devel] Cello: defmd geometry-node ... Message-ID: <150A99D0-7E03-42A0-A24C-B7088788D462@me.com> 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 ;-) Thanks again. Frank -- Frank Goenninger Cell: +49 175 4321058 E-Mail: frgo at me.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2227 bytes Desc: not available URL: From kentilton at gmail.com Wed May 20 04:23:13 2009 From: kentilton at gmail.com (Kenneth Tilton) Date: Wed, 20 May 2009 00:23:13 -0400 Subject: [cello-devel] Cello: defmd geometry-node ... In-Reply-To: <150A99D0-7E03-42A0-A24C-B7088788D462@me.com> References: <150A99D0-7E03-42A0-A24C-B7088788D462@me.com> Message-ID: <4A1385B1.3050401@gmail.com> 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) )) 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 From frgo at me.com Wed May 20 05:31:15 2009 From: frgo at me.com (Frank Goenninger) Date: Wed, 20 May 2009 07:31:15 +0200 Subject: [cello-devel] Cello: defmd geometry-node ... In-Reply-To: <4A1385B1.3050401@gmail.com> References: <150A99D0-7E03-42A0-A24C-B7088788D462@me.com> <4A1385B1.3050401@gmail.com> Message-ID: <3C086F3E-E1C3-4319-B5B5-1AE3010BC3BD@me.com> Am 20.05.2009 um 06:23 schrieb Kenneth Tilton: > Understood. Those diagrams obviously took a lot of work, I felt bad > raining on the parade. But here I go again: Please keep going! Thanks for insisting here on the points below ... > > 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), Which was exactly the one thing I also got worried about. So: > but I also see things like all three of lL, lR, and lWidth. I have > done that as well and regretted it. Aha! Now I see the reasoning behind the current code base. > 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). Ah - also something I did different in the past: I always worked from 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) )) > > 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. Oh - I was precisely looking for this kind of feedback - I am not too eager to make that experience again. I had to remind myself that I started this "let's do it again" just because I did not see why there are no default rules, why there is e.g. no width and height parameter for a control, why things like l-box are not always updated. Now I know ;-) Lot's of effort, I know, but now I am *a lot* more clear about what and when and why. Thanks so much! And now going back to coding and just strip down the code to the same conceptual logic as Cello had it from the beginning. One design goal of course is to have minimal impact on existing Cello- based apps. Cheers Frank -- Frank Goenninger Cell: +49 175 4321058 E-Mail: frgo at me.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2227 bytes Desc: not available URL: