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

[D John Anderson]

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. Of course some people may  
not have always followed that rule either because they didn't  
understand it or because there are ambiguities.

>
> These types of separation and improved testing are all things that  
> I think we've wanted to have for a long time, but they aren't going  
> to happen unless we make them a priority and budget the time for them.

I'm concerned that a this could lead to a very large scale  
refactoring project that might take time away from incorporating user  
feedback to improve our design -- and put at risk our goal of getting  
user adoption.