SWT Drivers

[Toby]

Hello,

Just starting to browse the source after Nat piqued my interest at
XPDay... I was wondering about SWT/JFace support, am I right in
thinking it doesn't yet support it? Would that be of interest to the
wider audience do you think?

Thanks,
Toby

[Nat Pryce]

Hi. You're right, we have not added any support for SWT. I'm sure
people would be interested, though.

You should be able to build an SWT prober by extending the
UnsynchronizedProber in the Windowlicker Core API, and writing Tracker
classes to guide the mouse pointer into SWT components. All I know of
SWT is that the event loop is not hidden away in a background thread
as it is with Swing, so you might need a way to spawn a thread from
the test to run the application under test, and close down that thread
in a reliable manner.

--Nat

[Toby]

Thanks for the reply, sounds good. I started playing around and will
see where it goes...

What's the best way to get feedback if I get anywhere? Should I post
patches here?

Cheers ears,
Toby

[Toby]

Hello,

I've posted a bit of a spike experimenting with an SWT driver, it can
be found at

http://groups.google.com/group/windowlicker-users/web/window-licker-swt-spike.patch


I'm not proposing it go into the source or anything but would be
really interested in peoples thoughts. Most of it is a blatant cut and
paste from the Swing part but with minor adaptations for SWT. In
particular, have a look at the following classes

SwtCalculator and SwtBasicArithmeticTests (both unfinished but
demonstrate the idea)
TextDriverTest
UIThread (tries to make more explicit the creation of the UI thread)

The jist of it all is that we have to create a UI thread to run the
SWT stuff from within the test without blocking the actual tests. The
solution I came up with means that any application that wants to use
the framework would need to change slightly but I can't see a way to
avoid this.

The change is kind of minor and when I think about it, actually makes
good sense for SWT apps. It means that rather than like most SWT apps
that start the event dispatching loop from within the main thread, you
should code your app to *optionally* start the event loop (which is
how JFace do it with the ApplicationWindow class). The UIThread class
tries to help here and test code is free to use it to make more
explicit the creation of the UI thread. The tests will then run in the
main thread. Anyway, hopefully the code explains it better than I do!

oh, the other thing is that the patch doesn't include the SWT/JFace
jars that you'll need to actually run it. You can download these from;

http://code.google.com/p/gibble/source/browse/trunk/gibble/lib/jface
http://code.google.com/p/gibble/source/browse/trunk/gibble/lib/swt

All the best,

Toby

On Dec 16, 4:56 pm, Nat Pryce <nat.pr...@gmail.com> wrote:

[Nat Pryce]

2008/12/22 Toby <toby....@gmail.com>:

> The
> solution I came up with means that any application that wants to use
> the framework would need to change slightly but I can't see a way to
> avoid this.
>
> The change is kind of minor and when I think about it, actually makes
> good sense for SWT apps. It means that rather than like most SWT apps
> that start the event dispatching loop from within the main thread, you
> should code your app to *optionally* start the event loop (which is
> how JFace do it with the ApplicationWindow class). The UIThread class
> tries to help here and test code is free to use it to make more
> explicit the creation of the UI thread. The tests will then run in the
> main thread.

Can you not spawn a thread in the test to run the app's main method
and then call Display.findDisplay(thread) to find the app's display?

--Nat

[Toby]

On Dec 23, 8:25 am, "Nat Pryce" <nat.pr...@gmail.com> wrote:
> 2008/12/22 Toby <toby.wes...@gmail.com>:

>
> Can you not spawn a thread in the test to run the app's main method
> and then call Display.findDisplay(thread) to find the app's display?
>
> --Nat

hmmm, not sure. The test does spawn a thread for the main and in the
run of that thread starts the annoying SWT event loop business. So
that sets up the UI and its off ready to handle UI events. The main
thread is then off to run the actual tests. The problem was that one
of the threads has to get into the event loop and essentially block
and that can't happen in the apps main (at least when under test) else
the test blocks.

I'll have a look and see if I can figure out something with
findDisplay. Right now it enforces that everything happends of the
default display so we can call Display.getDefault() to interact with
it. findDisplay might be more sensibe though.

Not sure if that answers your question!

Cheers,
Toby

[Nat Pryce]

The event loop should not block the test thread because it runs on the
GUI thread that the test thread spawned, unless I've missed something
about how swt behaves.

www.natpryce.com

[Toby]

On Dec 23, 5:34 pm, Nat Pryce <nat.pr...@gmail.com> wrote:
> The event loop should not block the test thread because it runs on the  
> GUI thread that the test thread spawned, unless I've missed something  
> about how swt behaves.
>
> www.natpryce.com
>

That sounds about right, I probably wasn't very clear when I said
'block' before. You're right, the event loop doesn't block the test
thread once its been spawned in its own thread. The biggest problem I
had with the spike was spawning that thread.

What did you think of that as an approach, using the UIThread from
within the test etc?

[nat....@gmail.com]

Having a class that performs all the drudgery of spawning and
interacting with the display thread sounds like the best approach. I
can imagine it having overloaded constructors or subclasses that know
how to run an application's main method or show a single widget for
unit testing custom controls.

Cheers,
Nat.

--
http://www.natpryce.com

[Toby]

So just for reference, a discussion of the UIThread class can be found
here http://pequenoperro.blogspot.com/2008/12/be-explicit-about-ui-thread-in-swt.html
and a more refined version here
http://code.google.com/p/gibble/source/browse/trunk/gibble/src/test-end-to-end/java/net/chazzwazzer/gibble/gui/UIThread.java

Cheers

[Nat Pryce]

Good stuff. Thanks for the links.

--Nat

2009/1/24 Toby <toby....@gmail.com>:

--
http://www.natpryce.com