Re: [Xswt-developer] Xswt-developer Digest, Vol 2, Issue 5

[David J. O. <dj...@co...>]

Hallvard Tr=E6tteberg wrote:
> David,=20
>
>  =20
>> -----Original Message-----
>> From: "David J. Orme" <dj...@co...>
>> Subject: [Xswt-developer] New task list
>>
>> (I know you won't get this right away, but I'm writing to the=20
>> list for everyone's benefit and as a central place to keep=20
>> these thoughts.)
>>    =20
> I'm back now.
>  =20
Welcome back!
>> I had a chance to look at the new code that just landed. =20
>> Great work! I'm especially impressed with the scripting and style shee=
t=20
>> work.
>>    =20
> :-)
>  =20
>> - Error handling and reporting:
>>
>> a) In addition to pushing line and column information into=20
>> the nodes so that we can just output the tree nodes as you=20
>> suggest, script syntax errors are silently ignored, but the=20
>> layout isn't built either.
>>    =20
> I've now changed the code to using a context object (element) for error
> reporting. The standard element implementation outputs line and column =
for
> the element (should be enough to identify a faulty attribute).
>
> I'll look into the problem of ignored script syntax errors.
>  =20
Excellent.
>> b) There seem to be situations where other syntax errors=20
>> result in a layout not being built, but no error reported either.
>>    =20
> Can you give some hints for when?
>  =20
My recollection is that it often seemed to be related to if there was a=20
syntax error in a style sheet file, but I think I saw some other random=20
cases too.  My second recollection was that I wasn't able to trace it to=20
any specific use-cases.  I guess I didn't leave any explicit test cases=20
in the repository if you're asking.  Sorry, my bad. :-(  If I run into=20
any more cases, I'll make tests and commit them.
>> - Style sheets:
>>
>> a) I didn't attempt to cascade across two or more files, but=20
>> I did try to cascade within a file. i.e: define a style that=20
>> references two other styles in the same file.  That refused=20
>> to build, but also didn't display any error.
>>    =20
>
> I've now included some fixes and a test that cascades styles (in the sa=
me
> sheet file).
>  =20
Cool!  I won't have a chance to test this tonight but I'll try to use=20
this in my presentation if possible... :-)
>> b) I've extended the style sheet test, and added comments=20
>> about additional style sheet things it would be nice to support.
>>    =20
>
> I think I understand what you want the XML to do, but could you anyway =
write
> the test case (java) code to make it clear?
>  =20
OK; but please understand I can't do that tonight (have to get back to=20
work for my client).
>> - Editor / preview view:
>>
>> a) I'm about 95% done migrating the preview code to the new=20
>> editor framework.  Hopefully that will get finished this week=20
>> and we can:
>>    =20
> I understand you had to temporarily stop working on XSWT and work in
> EclipseWorld presentations instead. How far have you come with the edit=
or?
>  =20
Hard to explain without outlining how the editor works.

There are two ways to build a SWT GUI builder that works in the=20
traditional way:

1) Using GEF: build the UI somewhere, grab a bitmap of it, then blit the=20
bitmap into a Draw2d figure and paint on top of it.  Trouble is: a) this=20
is slow; b) it doesn't work reliably across all platforms; c) it's=20
really complicated to get right.

2) Using live SWT widgets: Steve Northover intentionally put a hack into=20
SWT to make this work.  If you someComposite.setEnabled(false), all=20
controls inside someComposite will appear to be enabled, but won't=20
respond to any input.  Further, all input (keystrokes, mouse events) on=20
the contained controls will be delivered to the containing composite,=20
not to the controls themselves.  So you can use this to make the widgets=20
look normal, but intercept their input, resize them, etc.

But we also have data binding tooling in XSWT.  And I've found it so=20
invaluable to be able to interactively play with my data bindings in the=20
XSWT preview's live widgets that I can't imagine writing a traditional=20
GUI builder that lets you look at, but not interact with the UI you are=20
building.  So here's a third way to do it:

3) Build a SWT UI using 100% live widgets, just like we do today in the=20
XSWT preview.  Use Display#addFilter to intercept the events that are=20
sent to the widgets.  Dynamically add and remove paint listeners to the=20
widgets themselves to draw the feedback that folks are used to seeing in=20
a GUI builder.

The XSWT Builder code base was originally designed for #2.  I decided to=20
switch to #3 because I was running into some serious roadblocks that I=20
was convinced would make it impossible to make #2 work for all SWT=20
classes in a reasonable amount of time.  That involved the following:

a) Eliminate the code that inserted the invisible disabled Composite=20
around each control in the UI layout.  This was the source of all the=20
difficulties mentioned above.
b) Make the root editor Composite setEnabled(true).
c) Fix the coordinate hitTest code in the editor so that resizing the=20
layout with the mouse understands the above changes.

So the move is overall to a much simpler architecture that should be=20
much easier to develop and maintain over time since there no longer is=20
any magic that happens in between the XSWT code and the the layout that=20
you see.  What you write in XSWT is now exactly what you get in SWT.

Now I can answer your question. :-)

Everything but (c) above got done.  (c) got partially done.

Other than that, there is basically a whole bunch of packaging grunt=20
work required to make a new release of XSWT including the new editor=20
code base, the pnuts scripting, and so on.

Oh, and we might want to document to the world what we've done so that=20
folks can hopefully appreciate it. ;-)

If you'd like to hack this, I'd be glad to schedule a Skype session to=20
get you up and running with the editor code base on your machine.
>> - See if we can get XSWT brought back into Eclipse in the 3.3=20
>> time frame.  There is some mild interest being expressed by=20
>> the Platform team, and I think we have a shot at it.  This=20
>> would get us quite a bit more exposure.
>>    =20
>
> That would be great!
>  =20
OK.  I'll see what I can do.  In September, that is. :-)


Regards,

Dave Orme