Re: widgets plan proposal

> > You have a really good point here.  Behaviors logically belong in
> > xwt.lib, yet they should be themeable as well!

> I don't actually understand this. xwt.lib is code that is theme
> independent, right? In which case, behaviors still belong in xwt.theme.

Take button.  All buttons I can think of want to be able to provide some kind 
of trap when clicked.  Almost all change their form physically when clicked.  
I can't think of a single one that you don't want to hit from a keyboard.  A 
lot of themes change the form (highlight, sparkle, whatever) when hovered.  
These are all common behaviours -- why put the code that does foo to a button 
when it's hovered or clicked or disabled or whatever in each theme?  Put it 
in a common behaviour template and the theme just changes the look.  

THAT, IMO is what a theme is all about.  Most themes will do the same damned 
thing to the same widgets, only looking different, so if you can put all the 
common code in one place, do so.  xwt.theme.* should only contain the 
differences between the different themes, not all the behaviour code too.  
(unless there is a radically different way a widget works in a different 
theme, in which case yes, that's where the code goes.

> The question is do behaviors belong in xwt.theme.<behavior>, or just in
> plain xwt.theme.

yuck.  90% of all the theme templates have the same core behaviour.  Why 
repeat that code in every theme?

> This seems like a complicated way to do things, just so we can
> reference xwt.lib.<behavior> instead of xwt.theme.<behavior>.  Why not
> just keep it like the rest  and have xwt.theme.<behavior> preapply
> xwt.lib.<behavior> if it wants to.

That's what we're doing with xwt.standard.widgets.  The themes themselves have 
very little code in them since they're just tying together the blocks that 
are already there to make the widget "move" how it's supposed to for that 
theme.

> Also, seeing as xwt.theme doesn't actually have a theme in it, I think
> its documentation should focus on the specific API themes have to
> implement. ie, where traps/variables have to be, and what they have to
> do. A theme should follow this explicitly so the preapply's in
> xwt.widget work well, and so a heavyweight developer can use xwt.theme
> directly and get a uniform interface.

Whoa... I think I'm missing something... what's xwt.theme?  Is it literally 
xwt.theme or xwt.[theme_name_here]?

I suppose what it comes down to is "what is a theme or an overlay?"  If you 
put the code in xwt.theme.* then you have to try and manage the API the same 
across all themes.  That is a ROYAL pain in the arse, as that is pretty much 
how it was before the audit.  What Charlie and Rod did was to pull all the 
common stuff out (and make common stuff where there wasn't any) and give you 
a base library to work from.

ALL widgets across ALL themes have _action which gets called when the user 
activates the widget and it is not disabled.  Not _click or _checked or 
_selected.  ALL (relevant) widgets across ALL themes have _hover or _keypress 
or _disabled.  There's no question whether to use _KeyPressed or _keypressed.  
It was a hairy-ass royal mess before because everyone kind of did their own 
thing.  I can't tell you how frustrated I was before.

There was a table widget but it was in the aqua theme.  So I'd pull the code 
out of the aqua theme and try and monopolize it.  Ack, that didn't work 
because the traps that aqua used were vaguely similar to those that monop 
used, but neither were really spot-on so you ended up with kludges and hacks 
and it never worked 100%.  That is _gone_ now, and I don't want to give that 
up for anything.

An app designer should almost never use _Keypress or _Click or really any of 
the core interactive traps -- they use the postprocessed traps given by the 
base widget library.  You don't ever ever use _Keypress because it doesn't 
take focusable into account, type of thing.

Changing themes shouldn't mean changing code.  Ever.  If I were in charge of 
the widget set I would not allow a widget into a theme unless it was properly 
split up so that all themes could take advantage of it.  I don't care if aqua 
had table and nothing else did, but you better believe that the code for 
table would be split up properly and all someone who wanted table for monoply 
would do would be to provide the graphics and tie in the code to the 
graphics.  That's it.

The widget set we have now (well simple and monopoly) is very close to that 
goal.  I can change the xwt.theme statement and have a totally different look 
and feel but not change any other line of code.  The sales app in 
com.benshaw.apps is a good test case because it's quite large and makes 
heavy, heavy use of widgets.  You only get that level of stability and 
flexibility from having as much as possible common, which is why the widget 
set tries its hardest to keep code the hell out of the themes.

Regards,
Andrew

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