[PEAK] A quick UI API sketch

[Phillip J. Eby]

This should be somewhat self-explanatory in the light of the previous 
post, but some non-obvious points are added below...

class PreviewScope(ui.Scope):

     currentDate = ...

     def nextDay(self):
         ...

     def previousDay(self):
         ...

     ui.Text[currentDate](
         _(u'Preview Date'), _(u'The day to view in the preview area'),
         ...
     )

     ui.Action[nextDay](
         _(u'Next Day'), _(u'Move forward a day'),
         ...
     )

     ...

     ui.TopMenu['preview_nav'](
           _(u'Navigation'), _(u'Navigation menu for the preview area'),
          items = [previousDay, nextDay, ...],
          ...
     )

This is sketching a scope with a set of scope-defined features and 
presentation options.  Specifically, it's all being done inside the 
original scope class.  For a plugin to extend these features, it 
would need to define an AddOn to attach to the scope.

The idea for object references is to use objects as keys or 
identifies to uniquely designate a feature.  This might be a 
CellProperty or an unbound method (i.e. function linked to a class), 
for example.  Technically, these objects can be *converted* into keys 
of some sort; we won't want to use them directly for various ugly 
reasons relating to inheritance and overriding.  But as long as the 
key can be generated *from* the object, we can use the objects in the 
API.  A plugin can import the scope it wants to extend, for example, 
and refer to e.g. ``PreviewScope.currentDate`` in order to look 
something up by that key.

The idea with the various things like ``ui.Text[foo]`` is that 
feature and CA types can be subscripted by an object to return a 
registration factory for an instance of that type.  You then call the 
factory with whatever arguments are relevant, in order to register 
construction data, that will be used at Scope creation time to add 
the actual feature or CA instances.

There's still a lot to flesh out here, but this seems like a step in 
the right direction.  Notice, by the way, that CA groupings are done 
via a path string key instead of an object key; this makes it 
somewhat more practical to have plugins contribute to a shared menu 
that neither one defined.