[Cosmo-dev] UI layout and rendering doc

[Jeremy Epstein]

hi matthew-- its going to be a bit longer before I can competently 
respond -- things are pretty busy.  You have a good point, which would 
be to try and hide the viewport beneath more conventional UI mechanisms, 
such as panels, which have position and snap. Simple panels wouldn't be 
too hard to specify, but more complex one could require a lot more 
structure and introduce some dependenies.
For example, lets say we do a three column with two side panels and a 
center. The left and right columns are easy. the center is interesting-- 
it needs to know about the left and right columns (i.e. they must render 
first, regardless of order or hierarchy) 
Are you ok with something like this? effiectively resize would have to 
happen from an ordered display list of some sort. (its the same problem 
you have with floated divs)


Matthew Eernisse wrote:
> Jeremy,
>
> I've had a chance now to sit down and look at the files you sent with 
> the changes to ContentBox and your resizer viewports. Comments inline 
> below ...
>
> Jeremy Epstein wrote:
>> the first is integrated n to the contentbox resize routines to 
>> eliminate circular rendering dpendencies-- there is a hash that 
>> tracks renders-- until the hash is cleared, once an item is rendered 
>> it can't be rendered again. for integration, this will require you to 
>> add a line to the topmost render method or whateer invokes to clear 
>> the hash. 
>
> This is excellent. As the hierarchy gets more complicated, the 
> independence of the various UI widgets will increase the possibility 
> of that kind of circular rendering problem.
>
> A couple of questions:
>
> 1. Is there a specific reason to use a startRender that doesn't know 
> if rendering occurred successfully -- or would it make more sense to 
> use a completedRender method called immediately after renderSelf?
>
> 2. The check for previous rendering happens in the loop that processes 
> the children of a ContentBox, so it looks like it would still be 
> possible (albeit unlikely) to have a situation where a top-level UI 
> widget renders over and and over.
>
> I was imagining something that looks like this:
>
> cosmo.ui.ContentBox.prototype.render = function (h,w,l,t) {
>     if (cosmo.ui.ContentRenderWrangler.hasRendered(ch.id)) {
>         return false;
>     }
>     if (typeof this.renderSelf == 'function') {
>         this.renderSelf();
>     };
>     cosmo.ui.ContentRenderWrangler.completedRender(this.id);
>     var ch = this.children;
>     for (var i = 0; i < ch.length; i++) {
>         ch[i].render(h,w,l,t);
>     }
> };
>
> 3. There's already a hasBeenRendered property used to indicate that 
> the UI widget has rendered at least once (usually for making sure 
> things like appending the DOM structure to the document only happens 
> once). If we implement the ContentRenderWrangler, I think there might 
> be some confusion from naming. ("What's the difference between 
> hasRendered and hasBeenRendered?")
>
> I'm not married to the name hasBeenRendered. It almost represents a 
> rendering initialization phase -- although we'd probably not want to 
> use 'init' because a UI widget can be set up and initialized without 
> ever actually being rendered. I guess we could get a little verbose 
> and call it hasBeenRenderedOnce or hasBeenRenderedTheFirstTime or 
> something. Thoughts?
>
>> the second item in contentbox is another contentbox, (you could think 
>> of it ias a subclass if you are so inclined)
>
> Is there some specific reason to take the mixin approach with 
> ViewportContentBox rather than simply having its prototype inherit 
> directly from the ContentBox?
>
>> that includs a wrapper for viewports. note that the viewport resize 
>> parents are different then the strict DOM hierarchy as they will 
>> almost always resize absolutely based on the first absolutely or 
>> relatively positioned parents coordinate space. this is important-- 
>> an objects logical dom parent may not be absolutely positioned, but a 
>> viewport's render parent must implement the viewport render method 
>> (which requires the render command to pass two arguments: width and 
>> height)
>
> At least in the Cosmo UI code, I'm pretty sure that every element in 
> the DOM hierarchy for the Cosmo layout is either absolute or 
> relatively positioned -- if it's not, it's a bug.
>
> Final thoughts -- one of the things I had in mind when I mentioned the 
> idea of unifying the ContentBox model with the viewports was a way for 
> a developer to create a ViewportContentBox and use the simple 
> sizing/positioning methods (setWidth, setHeight, et al) to set up the 
> min/max values for the content box.
>
> I don't know if this is even possible to do given the conceptual 
> differences between the two, but I can imagine some easy-to-use calls 
> like this:
>
> // 200px wide, full-window height, right-aligned
> // You wouldn't want to use '100%' for height
> // because it would look like you're setting CSS props
> someViewportWidget.setSize(200, 'full');
> someViewportWidget.setPosition('right', 'top');
>
> // full-window width, 200px height, bottom-aligned
> someViewportWidget.setSize('full', 200);
> someViewportWidget.setPosition('left', 'bottom');
>
> It would make it dead simple to set up and use resizer viewports 
> without having to try to fit the different min/max params in your 
> head. It might not even be all that difficult to come up with the set 
> of rules needed to translate from one to the other.
>
> I'll be looking forward to hearing your thoughts on all this.
>
> Thanks again very much for your work. I'm really excited to see this 
> kind of innovation going into the UI code.
>
>
> Matthew
>
>
>
>
>
>