Re: widgets plan proposal

>    xwt.widgets -- each template is simply an empty template which
>                   preapplies the appropriate xwt.impl template and any
>                   relevant "adjectives" (focusable, etc).  A <doc/>
>                   element should specify the contract between
>                   implementations of that widget and its users.  You
>                   shouldn't overlay other templates on top of
>                   xwt.widgets.

Agree.
Does this mean that xwt.standard is going away?

>    xwt.impl    -- individual templates in xwt.widgets pre/post apply
>                   these; new themes should overlay xwt.impl with the
>                   theme-specific templates.  In general, xwt.impl
>                   templates should not apply "adjective" templates.

Agree.
As Charlie and Rod have it now, the xwt.standard.widgets and shared 
directories contain "behaviour" code, and x.s.w.lib and x.s.s.lib contain 
common code that is usually postapplied in x.s.w and x.s.s.  

Since the behaviour of most buttons, pulldowns, sliders, etc. are almost 
identical, most themes just preapply the code located in x.s.w (proposed 
x.s.impl) and add boxes for look and code to handle the new boxes or 
different behaviours.

Is this similar to what you're proposing here?

>                   The "default" implementation (ie the actual xwt.impl
>                   templates, not the stuff overlaid on top of it)
>                   should be super-simple and hideously ugly (sorta
>                   like the Xaw widgets).

Disagree, but only because I have a few questions. (how's that for boolean!?)

What direction is xwt heading toward -- will there ALWAYS be an xwt.theme() (I 
think there was talk of moving this to an xwt.overlay() call instead) 
statement?  If so, why make it optional?  Is there something inherently wrong 
with putting code something like this in a trap?

_themeChanged = function(newtheme) {
    xwt.theme("xwt.standard", newtheme);
}

??

The second question ties in with the previous point -- at least in what Rod 
and Charlie have done now, what is proposed to be impl doesn't actually have 
a theme -- it's the bare minimum to achieve the desired behaviours that 99% 
of the themes will use anyway.  The button for example, has the boxes and the 
code to handle hovers, presses and whatnot, but does not have the boxes which 
have the dotted border of monopoly focused widgets, or the bevel that goes 
away when pressed.

>    xwt.lib     -- templates containing only code; intended to be
>                   preapplied/postapplied to other templates in order
>                   to import commonly used functionality.  You should
>                   not overlay other templates on top of xwt.lib.

Agree.

> Import the mixdown cvs tree as the 'audit' branch on cvs.xwt.org.
> Andrew and Charles are given sole authority over this branch; they may
> delegate it as they see fit.  I will not meddle with this branch.
> Just to be 100% clear, you DO NOT have to ask me for commit approval
> unless you're patching the engine.

Agree.
Do you have any issues with me pointing my cron job over to cvs.xwt.org to do 
cvs exports to provide daily CVS snapshots?  I would assume not but I just 
want to make sure.

> Andrew/Charles, at some point David will ask you for a 48-hour "cease
> development" synchronization point (you should negotiate when this
> will happen).  Before that point, check in all your work-in-progress,
> and then cease development for 48 hours.  During this time, David will
> complete the merge over to the HEAD branch.

That's fine.  What I am asking for is that we get what we have now completed.  
We're pretty much there (I am estimating over 75%, the only widgets left to 
do are table, tree and menu unless I'm missing something major) -- Charlie 
would be able to give you a better heads-up as to the completion date there.

Once those are done, cvs.mixdown.ca isn't needed anymore.  There's no need for 
the history there, and I can import what we've got to cvs.xwt.org as an 
'initially_working' tag or something, and David can work the magic he does 
and import the HEAD tag.   I would really like to have the working-as-it-is 
version in cvs.xwt.org, if for nothing else than a reference.

> The people remaining in the commit_widgets group (andrew, charlie,
> david, megacz [later: rod?]) divide responsibility for the widgets by
> consensus.

Rod is a co-op student working for me (Benshaw) -- His term with us is up at 
the end of April, but I have it on good authority that he will continue to 
work for us part-time, and I believe that both Charlie and I have 
sufficiently brainwashed him into believing that XWT is the only true way for 
him.  I know I have convinced his co-op coordinator into taking a very hard 
look at it for all of their work at the University of Waterloo, so he may 
have some teaching work there when he gets back.  :-)

It is my very sincere hope that he continues his activity with the XWT 
community.

> Architectural changes (ie xwt.widgets.*) should be agreed upon by
> consensus before checkin; anything else is commit-at-will if you've
> taken responsibility for the widget in question.

Agreed, but with some comments:
I would rather have the same strict policy you have set out for the engine.  
Once the widget tree is declared happy, any changes to that widget tree 
should be cleared by consensus before commit.  This is the tree that people 
will be downloading and using, and it should just plain old work, just as the 
engine should just plain old work.

Having said that, HEAD will be a little unstable, but the same policy that 
kde.org has should be in effect: don't commit code unless what you're trying 
to change is working or you have permission to upload broken code.

> I recommend that you all watch the [email protected] mailing list -- it's a
> neat way to keep an eye on what other people are doing.

I'll take a look at it.  What software are you using to generate thse reports?

Regards,
Andrew

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