On 2010-03-18, at 15:50, Henry Minsky wrote: > I need a Venn diagram to figure out what is shared logic. Here's an > approximation. I can try to > factor out each of the common operations into a common method. > > The only thing that > worries me is that the order in which the "setrecheight" calculations gets > done is slightly > different in the $lzc$set_height and in updateSize. In $lzc$set_height , > the "this.height" is set first, > and then the resource stretching code gets run, whereas it's the opposite in > updateHeight. Oh well... > > > ================================================================ > LzView $lzc$set_height: > ================================================================ > > [A] decides whether to set hassetheight
We all agree this only occurs for `<view>/$lzc$set_height` > [B] set this.height Seems to me this should come after C, since it's a no-op if the value has not changed. > [C] check if cached height has changed, updates cached height I think it is more accurate to describe this step as: if the height has not changed, just send the event and return now, otherwise, continue. I believe the primary purpose of this is to avoid the redundant overhead of running the whole update algorithm if this input has not changed. [A separate question is whether we should be sending the event, since our policy elsewhere is to _not_ send an event when the value does not change.] > [D] if null height value passed in, does some calculation to set view size > based on resource height and the 'stretches' flag. I believe this to be: `null` implies size to my contents. Then there are the following subcases: My only content is a resource: size to the resource I have contents and no resource: size to the contents I have both, and the resource is set to stretch: size to the contents stretch the resource to that size. > [E] if pixellock, compute integer value > > [F] if "_setrescheight" does some other calculation on resource. (What > does "_setrescheight" actually stand for? It seems to be indicate that > "stretches" is set, why aren't we just looking at the value of > 'stretches'?) In this case, we know we have a fixed size already (not case D). `_setrescheight` appears to be a cache for stretches being either "both" or "height". So, we have to stretch the resource to the (new) fixed height. > [G] call sprite.setHeight This call makes sense for `<view>/$lzc$set_height` (the user asked for it), or `<view>/updateHeight` (this is an auto-sizing view whose children have changed in size). In both cases, we need to tell the sprite what this new size is. For your new third purpose of the kernel informing the LFC of a size change, this should only be necessary if pixel-lock changes the size -- otherwise it is just a wasted call, since the kernel already knows the size. > [H] call parent.checkHeight Just to clarify, we only call this if the parent is listening (is one of those cases above where it should size to its children). > [I] send 'onheight' event I see your point about this happening in a different order in updateHeight. Most likely this makes no difference, since if any of this is happening due to a constraint firing, we know the event will just be queued up to be processed. I think this order makes the most sense -- not to send the event until after all the internal processing has settled. (In effect checkHeight is an implicit/optimized constraint on `onheight` that only happens internally.) > ================================================================ > LzView.updateHeight: > ================================================================ > [D or F?] Does some calculation on stretched resources, which ought to be > equivalent to what the $lzc$set_height does, but I'm not sure This has to be D. `updateHeight` is called only if the view wants to size to it's children. In fact, I think your analysis reveals that `<view>/$lzc$set_height` should just be calling `<view>/updateHeight` if its argument is `null`. > IF view is autosizing (hassetheight==false) then: Ok, I am confused. Maybe we need a sub-diagram here. My understanding up until now was that updateHeight only needed to be called when your height was null. But we seem to have 3 flags that might control this: `hassetheight`, `__LZcheckHeight`, and `_setrescheight`. It's not clear to me that all combinations are possible. If updateHeight is only called because your children changed size, then it is only meaningful if you have `hassetheight == null`. So, why are we checking that again here? > [B] set this.height Seems like a bug to me that this is missing [C] and [E] > [G] call sprite.setHeight > [I] send 'onheight' event > > [H] call parent.checkHeight > > > ================================================================ > LzText.installHeight: > ================================================================ > [B] set this.height > > [C] check if cached height has changed, updates cached height > > [E] if pixellock, compute integer value Unless <text> cannot have a resource, it seems like a bug that you don't have the [D] and [F] clauses here. > > [G] call sprite.setHeight > > [H] call parent.checkHeight > > [I] send 'onheight' event This is a very useful analysis. I think with this we ought to be able to solve the problem simply and efficiently!
