Re: RFC: should the engine support retheming?

Adam Megacz wrote on Apr 13, 2003:
> Looking through ref7.6, it seems that we would only need:
>
>     1. A way to un-redirect a box
>
>     2. A way to enumerate the traps on a box (so that we know which
>        traps were added by the theme and which ones were added after
>        the theme was applied).
>
>     3. A way to enumerate all the top-level boxes.

I really like the idea of moving retheming out of the engine. Let me 
see if I can follow the idea through:

- First off, we could have the concept of a 'global property'. Any 
property defined in under xwt.* (ie. xwt.theme) can be trapped by boxes 
anywhere. That way, xwt.theme.themeable contains a trap:

xwt._theme = function() { ... }

These global properties  would have to use immutable traps to stop 
chaos.

- The global property xwt.theme can be passed a string, or an array of 
strings. These are the namespace(s) to be applied. The namespace(s) 
being applied is stored in a reference inside the themeable.xwt.

- the theming function in themeable.xwt performs step 3 from the 
reference, which is remove and save the children.

- the theming function then uses a new feature, 
Box.unapply(<template>), on all the templates from the old namespace in 
reverse order. This removes all the nasty traps, and any redirect this 
box may have applied. This way, we don't have to let people mess with 
redirect dynamically.

- the themeing function runs steps 5, 6, 7, 8.

- the themeing function overrides the old list of namespaces it has 
perminantly stored with the new list.

It involves storing a couple of string references in every template, 
but it does add weird features like rethemeing *some* of your instanced 
boxes (for bob knows what reason).

Do we need a version of the preserve to be implemented? If so, then 
themeable.xwt could be given an array of strings that are names of the 
properties, and the preserve can happen just before we run the old step 
3, and step 9 can be added straight after the old step 8 is done.

If we had Box.unapply(), I can't see a need for feature 2 or 3 in your 
list Adam.

This also keeps the widget library design exactly the same as it is 
now, with only one extra template (xwt.theme.themeable). It also has 
the cool new feature, that xwt.theme.text is applied to a box, then 
org.xwt.theme.monopoly.text. So if we could ever think of something 
that *needs* to be in all themes, we can put it in xwt.theme. I can't 
think of anything yet.

Does this sound right? This description may be a little confusing, as 
xwt.theme is sometimes a namespace, and sometimes a global property. :-S

d


_______________________________________________
http://lists.xwt.org/listinfo/dev