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?
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
On Dec 16, 4:05 pm, Toby <toby.wes...@gmail.com> wrote:
> 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?
> 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
> On Dec 16, 4:05 pm, Toby <toby.wes...@gmail.com> wrote:
> > 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?
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;
> 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
> On Dec 16, 4:05 pm, Toby <toby.wes...@gmail.com> wrote:
> > 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?
> 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?
> 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.
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.
> 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.
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.
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?
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.
On 24/12/2008, Toby <toby.wes...@gmail.com> wrote:
> 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.
> 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?
|
