[Chandler-dev] What is next for Chandler desktop?

[Phillip J. Eby]

At 08:48 AM 9/6/2007 -0700, D John Anderson wrote:
>On Sep 5, 2007, at 6:53 PM, Phillip J. Eby wrote:
>>Right, we need to distinguish between access transparency and
>>schema transparency.  Access transparency is a good thing.
>>
>>On the other hand, it's pretty well established at this point that
>>schema transparency tends to run counter to our goals at certain
>>points; we use EIM for sharing and dump/reload specifically to
>>*break* schema transparency, because it's better for us to have an
>>explicit delineation between internal objects and external schemas.
>>
>>In the context of the UI, the issue is more about separating those
>>characteristics of a UI component that should be persistent (such
>>as what item is selected or what collection is being displayed)
>>from the objects used to produce a visual representation of them.
>>In other words, some things that are part of blocks now could move
>>to being part of the widgets (or are already there), leaving behind
>>only the parts that truly need to be persistent.  The remaining
>>portions would then also be directly scriptable for testing
>>purposes in a headless environment.
>
>The design we current have puts the persistent information in the
>block and the display logic in the widget.

We're not quite on the same page here.  I'm saying that blocks have a 
significant amount of data (even in the Block base class) that should 
not be persistent, either because it's constant, or because it deals 
exclusively with visual presentation characteristics (like the 
co-ordinate data in RectangularChild).