request for comments: should the engine support retheming?

David Crawshaw <[email protected]> writes:
> Bad, because now I have to file a bug. And it looks like a pain to fix 
> (Box.java is going to have to keep an array of all templates applied to 
> it).

Yeah, I'm very worried about this one.  I really would rather think of
templates as macro-expansion than superclass/subclasses, because the
latter means we have to keep track of a whole bunch of stuff
(inheritance trees, instanceof information, etc), and that "stuff" has
to be both introspectable and virtualizable (fakeable) since everything
else in XWT is.

I don't want to do that.

Perhaps we could take advantage of the fact that the dummy templates
in xwt/widget/* get applied before the theme-specific ones?  Perhaps
they could have code to "checkpoint", "roll back" and "reapply" the
subtemplates?  It would be really neat if we could push the "retheme"
operation out of the engine and into the widget library...  it never
felt like it belonged there in the first place.

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.

If the engine supported these three operations, we could roll all of
ref7.6 into a "themeable.xwt" and have every xwt/widget/*.xwt preapply
that.  It would add a _retheme trap which would trigger the sequence
of operations in ref7.6.

I'm okay with #1 and #2, but not with #3.  Perhaps an acceptable minor
kludge would be to add xwt.retheme() which simply invokes "box.retheme
= true" for every top-level box.  So the engine only has one or two
lines of code devoted to retheming.

Also, there will have to be some sort of security precautions on
#1... perhaps only traps added to the box *before* its redirect was
set are allowed to un-redirect it.  Or something.


> Good, because it means I have yet to be driven insane by the code. No 
> offence meant against the programming style (I actually like it), it's 
> just Scriptable and different Context's being passed around can really 
> make my head spin.

This is one of the big reasons why I need to write my own damn
javascript interpreter.  There are so many huge opportunities for
massive performance and code-size gains by doing so...  I was really
careful to limit how much of ECMAScript we support in order to make
sure that I can do this later on without breakage.

  - a


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