Re: One Last Description

> Reading through the widget audit, I can see how you've designed with
> the layers:

> theme < theme dependent < theme independent

> But I honestly can't see why a lot of the 'theme dependent' stuff can't
> be part of the 'theme independent' stuff, and the rest of the dependent
> stuff be made a default implementation. It just doesn't seem like a
> necessary layer to me.

The widget audit was designed with the goal in mind to give a very clean and 
very easy to use widget implementation.  Easy to use and clean from an app 
designer point of view, a widget designer point of view, and a theme designer 
point of view.

Things are split off for a reason.  Charlie has made it abundantly clear (to 
me) why things are split off in the manner that they are.

You keep stating that it doesn't have to be.  Can you give me a specific 
example of what you're talking about above?  A specific widget, and the 
specific functions or code in that widget.  What did they make theme 
dependant that you feel should be theme independant?  You talk about it in 
theoreticals all the time and I have a hard time translating that to concrete 
examples of where what Charlie and Rod have done fail.

I feel that both Charlie and Rod have been _very_ careful in the 
implementation.  Early on in there was the option of doing things the quick 
and dirty way, or the clean way.  I asked them to take their time and do the 
widgets the clean and proper way.  If there's an extra preapply or some code 
that makes things more flexible, then they went that route.  I fully agree 
with that and stand behind their decisions.

I got good and goddamned frustrated with the orignal XWT widget set having 50% 
of widgets working one way, 30% another, 15% yet another and the remaining 5% 
in a way that I had no idea how it fit in.  using _Keypress instead of 
_keypressed because I needed to work around focusable.  Using _Press1 for the 
same reason.

That is not an attack at you, but rather the lack of you (i.e. a busy widget 
czar) -- life gets in the way of computers and that's how it will aways be 
until such a time as someone can make a fulltime living out of being an XWT 
widget czar.  The original XWT widget set is why my beard looks so nasty -- I 
was pulling it out trying to figure out how to write an app that used more 
than button, edit and checkbox.

Honestly, what's so wrong about an extra directory?  It keeps things cleaner, 
more modular and easier to work with.  I don't want xwt.theme to have a theme 
in it -- I want xwt.theme to have the theme code stubs and documentation that 
any theme needs to implement to be considered a complete theme.  No theme.  
None, nada, zilco, zippo, zero.  Keep it clean, keep it modular.  an extra 
500 microseconds to scan another preapply is not going to be noticed, and 
that time is only going to get shorter.

> But I'm over this, really. I have tried to argue the points, I've tried
> to argue the implementation. Hell, I tried compromising, and that was
> the worst mess of the lot.

I am sorry that you feel this way.  I really am.  I have tried to keep an open 
mind and read through the what, 100 messages in the past week on this list 
about the goddamned widget implementation and to be honest, I cannot see any 
advantage to what you're proposing.  Charlie's mail client not threading 
properly is really causing me grief in trying to follow this too, but that's 
a side-point.  The main point is that other than an extra directory and some 
extra files, what we essentially have now is no harder to read or use by 
anyone -- not widget designers, theme designers and certainly not app 
writers.

I do not see your plan as being any clearer, nor do I see it as being more 
modular.  I see less files and more tightly integrated code, and in my 
opinion that is a bad thing, not a good thing, because if FunkyWidget or 
FunkyTheme needs to do something odd, there is a lot of code copy/paste which 
leads to wailing and gnashing of teeth on the maintenance end of things.

In my mind the idea is not to create the most compact code.  We're using XML 
for Christ's sake -- The idea is to create a modular and expandable framework 
that we can toss at any web monkey and have them writing applications in XWT.

xwt.theme - documentation and stubs for THEME APIs
x.t.abstract - common behaviour code and box structures for THEMES

xwt.widget - documentation and stubs/preapplies for WIDGET APIs

xwt.lib - code for widgets (i.e. x.t.a theme-independent stuff)
x.l.abstract - code for behaviours (x.t.a theme-independent stuff)

xwt.standard is the standard (bare-bones) theme

99% of theme widgets will preapply the xwt.widget template of the same name.  
i.e. monopoly.button will preapply xwt.widget.button.  If you have a theme 
that wants to do something really weird for a button, you don't use the code 
found in xwt.widget -- weirdtheme.button would preapply xwt.theme.button or, 
if it's really weird, would preapply any code needed directly from xwt.lib.

Taking a simple button:

xwt.standard.button:
<xwt>
    <preappy name="xwt.widget.button"/>

    <template>
        container = $container;

// traps which alter the visible boxes
        _focused = function(f) { }
        _hover = function(h) { }
        _active = function(a) { }
        ...

// visible boxes that make up the standard button
        <bevel>
            <focusborder>
                <box id="container"/>
            </focusborder>
        </bevel>
    </template>
</xwt>


xwt.widget.button.xwt:
<xwt>
    <preappy name="xwt.theme.button"/>
    <preappy name="xwt.theme.abstract.clickable"/>
    <preappy name="xwt.theme.abstract.focusable"/>
</xwt>


xwt.theme.button:
<xwt>
// There's not much common theme code for a button

    <template>
        _container = function(c) { redirect = c; }
    </template>
</xwt>


xwt.theme.abstract.clickable:
- gives you _action, _hover, _active, etc.

xwt.theme.abstract.focusable:
- gives you _keypress, _keyrelease, _focused, etc.


Now that's a lot to digest, and I am not sure I got it right (Rod's been 
helping me write that) but what happens if I want to make funkytheme?

funkytheme.button:
<xwt>
    <preappy name="xwt.widget.button"/>

    <template>
        container = $container;

// traps which alter the visible boxes
        _focused = function(f) { }
        _hover = function(h) { do_sparkle() }
        _active = function(a) { make_button_dance() }
        ...

// visible boxes that make up the standard button
        <box id="container">
            <box image="someimage"/>
            <scrollbar/>
        </box>
    </template>
</xwt>

-- i.e. if all I want is a different look/feel, that's all I put in.

> My new plan is to give up. I will not vote on what this library is to
> look like, nor will I attempt to design any more widgets or submit any
> more patches. I will definitely not manage a changeover.

Again, I am sorry that you feel this way.  I honestly don't see what advantage 
your proposed layout has, other than it's smaller in terms of number of 
files.  Perhaps it's just because I've been working beside Rod and Charlie 
for so long, but what they've got make absolute perfectly clear sense to me.  
We _went_ through issues where theming caused the engine to barf because it 
went into an infinite loop.  We _went_ though discussions on where things 
should be split off and reorganized.

I'm not against some reorganization.  When you're trying to change the basic 
tenets of how the widget set works and operates though, I have to say that I 
need to see some clear advantages to a new system before I feel justified in 
jumping to it.  I simply have not seen that.

Regards,
Andrew

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