[PEAK] A layout and styling framework for UI components

[niki]

Phillip J. Eby wrote:

> Requirements
> ------------
> 
> One of the biggest complications involved is that GUI components must 
> typically be initialized in a top-down fashion, beginning with a parent 
> frame followed by its child controls.  However, in writing programs, it 
> is much easier and clearer to specify objects in a bottom-up form, e.g.:
> 
>     Frame(children=[Control1(), Control2(), ...])
> 
> (Notice that an expression like this actually creates the parent *after* 
> its children.)

Small note. wx can handle such creation order by using 2 phase
construction (designed for loading from XRC)

	f = PreFrame(children=[PreControl1() ... ])

the second pass is:
	f.Create(parent, ....)
	for c in f.children:
		c.Create(f, ...)

> 
> 
> "Renderer" Objects
> ------------------
> 
> A renderer is a relatively simple object that exists to hold the state 
> for, and co-ordinate the process of, rendering the presentation for an 
> object.  It performs widget construction and pre/per/post-child 
> processing, after first being "configured" for the object(s) being 
> rendered.  It also holds references to the target object, the resulting 
> rendering, and a parent renderer if any.  Renderers will also be able to 
> "manage" context managers, such that the rendering process can be 
> wrapped by context managers (such as the application of nested style 
> sheets).

Why not call them Builder objects? Don't they implement this pattern?

> Rules and Cascading
> -------------------
> [...]
> example, if you have this hierarchy:
> 
>      class Foo(object): pass
>      class Bar(Foo): pass
> 
>      class MyStyles(rendering.DefaultStyles): pass
> 
> Then the order of rule precedence for a Bar instance is:
> 
>     * Rules defined in DefaultStyles[object]
>     * Rules defined in MyStyles[object]
>     * Rules defined in DefaultStyles[Foo]
>     * Rules defined in MyStyles[Foo]
>     * Rules defined in DefaultStyles[Bar]
>     * Rules defined in MyStyles[Bar]
> 
> Note that more-specific rules are executed *later*, which thus gives 
> them the opportunity to override things that are set up by a 
> less-specific rule.  (Note: a given stylesheet may contain only one rule 
> for a given target type, and once defined, it cannot be changed.  Among 
> other things, this allows for caching.)

This way overriding is not possible. Or an override should find and
change all side effects from previous rules? There are examples of using
CSS for styling wx, aren't they enough?

> 
> What's Left
> -----------
> 
> This post doesn't actually cover how layouts will work, although it can 
> be taken as a given that most layout requirements can be met through 
> simple hierarchical construction and specifying of options on 
> renderers.  I will probably post again at a later time regarding more 
> sophisticated layout possibilities, but it will likely be after work on 
> how to "hint" or "tag" interaction components (such as commands, fields, 
> etc.) for use in rendering menus, toolbars, dialogs, and such.

Automatic layout can be very ugly. Simple task to align text in label
and edit control is impossible to do unless baseline property is
handled. Nice UI should account for whitespace balance etc. Best example
is photoshop and by chance it's layout (EVE) is open source as part of
Adobe Source Libraries. http://sourceforge.net/projects/adobe-source/


regards,

Niki Spahiev