Re: Clarification of layout proposal

You seem to ignore the fact that xwt.theme() / xwt.overlay() can't overlay
(without being unecessarily intelligent) the 'theme independent' code
because you'll have a perpetuation:

mytheme.button preapplies xwt.theme.button
xwt.overlay() overlays xwt.theme to mytheme
mytheme.button preapplies xwt.theme.button
etc
xwt crashes

Why make xwt.theme/xwt.overlay intelligent when you don't have to?


-----Original Message-----
From: David Crawshaw [mailto:[email protected]]
Sent: 03 April 2003 11:28
To: [email protected]
Subject: Re: [xwt-dev] Clarification of layout proposal



On Thursday, April 3, 2003, at 08:34  PM, Charles Goodwin wrote:
> I thought the whole purpose of xwt.theme was to have code / docs to 
> simplify
> and document theme creation.
>
> Now you're saying make an inverted dir structure lib[.theme] where 
> things in
> lib.theme preapply things in lib?  And then things in theme preapply
> lib.theme?

Sure, why not? I had never really formalised how the theme-independent 
code would sit in xwt.lib, I just sorta defined it as xwt.lib: "theme 
independent code goes here". I really don't care what preapply 
structure happens in there. Hell, there might be ten different 
focusable templates for whatever screwed up reason.

There is however, one other way of doing it (that's a little simpler), 
but you won't like it. :-)

If xwt.theme actually was a basic theme, then you could have an 
implementation in xwt.theme.focusable. And it could be the 
implementation used by 90% of themes. Then, to use it, a theme simply 
would not provide a focusable template.

Of course, you'd still want to abstract most of the functionality into 
xwt.lib.focusable, in case a theme does have to replace 
xwt.theme.focusable. That way there's no code redundancy.

d


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