swtbot-users — SWTBot users mailing list

Re: [SWTBot-users] "Background" Execution?

[Ketan P. <ket...@gm...>]

Phil Quitslund wrote:
> As I said, I do think we can track a "virtually" active shell but I'd like to 
> drive the spike with some tests.  What's the best way for me to get 
> contributions to you?  Do you have a sandbox I can commit into?

There's no sandbox. I suspect you may not really need any of the swtbot 
source code for doing the spikes we're discussing here.

If you sign up at bitbucket.org you can pull in the svn repository from 
https://www.bitbucket.org/ketan/swtbot/ and then follow step 2 onwards 
on 
http://www.selenic.com/mercurial/wiki/index.cgi/SubversionToMercurialHowto 
you'll be able to keep up with the 2.0 branch.

> We've all got this problem.  *sigh*  You're probably right that this will be 
> considered a bit low on the SWT priority list.  Still, might not hurt to ask. 
> Perhaps once the migration to eclipse.org is complete.  Will you be at 
> EclipseCon?  I bet if we ply those guys with beer we could engage in a little 
> brainstorming.

I'm myself awaiting for this, my travel to eclipsecon would depend on 
whether my talk is accepted.

> All good points.  I'd be happy if we could get some traction in win32 and 
> macosx.  I'm guessing that if we succeed in that we can recruit some linux folks 
> to pitch in.

Let's see how your spikes would progress and we could target the native 
stuff for a 2.1/2.2 timeframe. For now I'm just putting my head and 
getting 2.0 out the door.

-- Ketan

Re: [SWTBot-users] "Background" Execution?

[Phil Q. <phi...@in...>]

> The case of the cursor caret not moving because the generated events not 
> being 'real events' is one case in point. Display.post makes an event a 
> real event, which is why for e.g. it was possible to tab between 
> controls, sending widget.notify would not tab.
> 
> The reason for this, I believe is that certain things are handled by the 
> windowing system. Tabbing, accessors for menus and controls, using arrow 
> keys to navigate through trees and lists are examples of such cases. 
> Widget.notifyListeners may not always work for such cases.

I suspect you're right about this.  That said, it really seems like we ought to 
be able to capture what the app gets back from the OS and simulate it (albeit at 
the native level).  Of course, this may very well be hard and quite likely 
OS-relative.

>>> I do have some ideas about internally maintain some information about 
>>> the active shell:
>>> 1. Add a display filter (or listener) that keeps track of the active shell.
>>> 2. Have the user *explicitly* declare the active shell whenever the user 
>>> expects the shell to change, e.g. after clicking finish on some dialog.
>>>
>>> There could be more to this list.
>> I have some ideas on this too...  Do you have any test cases committed?  If not, 
>> would you be interested in collaborating on some?
> 
> I do not have any code or tests around these, I never got around 
> implementing them because it's a problem whose solution I do not know.
> 
> Also it's a more fundamental problem: should users have to declare what 
> active shell to use ? will that make tests unreadable ? What if some 
> users are explicitly doing stuff based on paint events, which may never 
> get triggered because the paint never happened? yeah there are a lot of 
> people who do that, and that's the only way for e.g. to paint on table 
> cells.

Right.  This is sticky.  I think we can probably track a virtual active shell 
but I'm less confident about the paint events (having just not thought hard 
enough about it).  Is this fundamentally more tricky than the other kinds of 
events you synthesize?  That is, do you think creating fake paint events is not 
a tenable approach?

> I'd be happy to pitch in if you have any concrete ideas that solve this 
> problem.

As I said, I do think we can track a "virtually" active shell but I'd like to 
drive the spike with some tests.  What's the best way for me to get 
contributions to you?  Do you have a sandbox I can commit into?

>>> However the one thing that does get into the way of checking emails 
>>> while running tests is the fact that new swt windows always open up in 
>>> the foreground, and there's no way for SWTBot to open them up in a 
>>> 'minimized' state.
>> This is an interesting point.  I wonder how this is done and whether we can 
>> intercept and override this default behavior.  I'll poke around --- ultimately 
>> this may be a question for the SWT gurus.  (Have you talked to them about this BTW?)
> 
> I would definitely want to make this a bigger conversation and get the 
> SWT team involved, but I hear there are more SWT platforms, than there 
> are people on the SWT team :( There are still a lot of SWT issues 
> pending that I've filed as part of SWTBot(along with patches), which are 
> yet to be resolved. I don't particularly see issues being resolved by 
> the SWT team unless there's a lot of weight put behind it.

We've all got this problem.  *sigh*  You're probably right that this will be 
considered a bit low on the SWT priority list.  Still, might not hurt to ask. 
Perhaps once the migration to eclipse.org is complete.  Will you be at 
EclipseCon?  I bet if we ply those guys with beer we could engage in a little 
brainstorming.

>>> Reg being able to send events using display.post and 
>>> widget.notifyListeners, I think something like Simon Stewart's Webdriver 
>>> (http://code.google.com/p/webdriver/) might be of help.
>>>
>>> Webdriver is slated to become selenium 2.0, and does a lot of ground 
>>> breaking stuff. It uses specific implementations for a particular os, 
>>> and browser implementation. This allows drivers to do something 
>>> different with each browser/os implementation. I feel this is one way 
>>> that SWTBot could take in order to do stuff across platforms, since that 
>>> is the only other way to go about things.
>> +1.  A library of native eclipse drivers would be a great boon.  Is this 
>> something anyone is actively researching?
> 
> We had investigated this as part of an alternative to selenium and 
> webdriver, and used SWT's OS class to go native, it was dropped in favor 
> of webdriver.
> 
> However this is easier said than done! I know how this is done in Cocoa, 
> using apple script. I also know that this is possible on windows using 
> c++ (yuck, I'd hate to write that again) or .NET automation API. There's 
> also a project called white(http://codeplex.com/white), by a fellow 
> ThoughtWorker, which SWTBot can leverage on windows.
> 
> This basically only covers windows, and macosx, and leaves a lot of 
> linux users out of the party, since I've not found anything for linuxes. 
> I believe some API for accessibility would be the only thing that'd be 
> useful here.

All good points.  I'd be happy if we could get some traction in win32 and 
macosx.  I'm guessing that if we succeed in that we can recruit some linux folks 
to pitch in.


-phil

Re: [SWTBot-users] "Background" Execution?

[Ketan P. <ket...@gm...>]

>> There's two issues in the new feature request that you mention here:
>> 1. maintaining state about the active window.
>> 2. being able to send events using display.post for certain types of 
>> events and widget.notifyListeners for some other types of listeners.
> 
> Do you know offhand which events require special casing?  (And are there tests?)

The case of the cursor caret not moving because the generated events not 
being 'real events' is one case in point. Display.post makes an event a 
real event, which is why for e.g. it was possible to tab between 
controls, sending widget.notify would not tab.

The reason for this, I believe is that certain things are handled by the 
windowing system. Tabbing, accessors for menus and controls, using arrow 
keys to navigate through trees and lists are examples of such cases. 
Widget.notifyListeners may not always work for such cases.

>> I do have some ideas about internally maintain some information about 
>> the active shell:
>> 1. Add a display filter (or listener) that keeps track of the active shell.
>> 2. Have the user *explicitly* declare the active shell whenever the user 
>> expects the shell to change, e.g. after clicking finish on some dialog.
>>
>> There could be more to this list.
> 
> I have some ideas on this too...  Do you have any test cases committed?  If not, 
> would you be interested in collaborating on some?

I do not have any code or tests around these, I never got around 
implementing them because it's a problem whose solution I do not know.

Also it's a more fundamental problem: should users have to declare what 
active shell to use ? will that make tests unreadable ? What if some 
users are explicitly doing stuff based on paint events, which may never 
get triggered because the paint never happened? yeah there are a lot of 
people who do that, and that's the only way for e.g. to paint on table 
cells.

I'd be happy to pitch in if you have any concrete ideas that solve this 
problem.

>> However the one thing that does get into the way of checking emails 
>> while running tests is the fact that new swt windows always open up in 
>> the foreground, and there's no way for SWTBot to open them up in a 
>> 'minimized' state.
> 
> This is an interesting point.  I wonder how this is done and whether we can 
> intercept and override this default behavior.  I'll poke around --- ultimately 
> this may be a question for the SWT gurus.  (Have you talked to them about this BTW?)

I would definitely want to make this a bigger conversation and get the 
SWT team involved, but I hear there are more SWT platforms, than there 
are people on the SWT team :( There are still a lot of SWT issues 
pending that I've filed as part of SWTBot(along with patches), which are 
yet to be resolved. I don't particularly see issues being resolved by 
the SWT team unless there's a lot of weight put behind it.

>> Reg being able to send events using display.post and 
>> widget.notifyListeners, I think something like Simon Stewart's Webdriver 
>> (http://code.google.com/p/webdriver/) might be of help.
>>
>> Webdriver is slated to become selenium 2.0, and does a lot of ground 
>> breaking stuff. It uses specific implementations for a particular os, 
>> and browser implementation. This allows drivers to do something 
>> different with each browser/os implementation. I feel this is one way 
>> that SWTBot could take in order to do stuff across platforms, since that 
>> is the only other way to go about things.
> 
> +1.  A library of native eclipse drivers would be a great boon.  Is this 
> something anyone is actively researching?

We had investigated this as part of an alternative to selenium and 
webdriver, and used SWT's OS class to go native, it was dropped in favor 
of webdriver.

However this is easier said than done! I know how this is done in Cocoa, 
using apple script. I also know that this is possible on windows using 
c++ (yuck, I'd hate to write that again) or .NET automation API. There's 
also a project called white(http://codeplex.com/white), by a fellow 
ThoughtWorker, which SWTBot can leverage on windows.

This basically only covers windows, and macosx, and leaves a lot of 
linux users out of the party, since I've not found anything for linuxes. 
I believe some API for accessibility would be the only thing that'd be 
useful here.

And there's still the more exotic OSes like solaris, HPUX, and AIX 
(which, to be honest I don't care about much)

-- Ketan

Re: [SWTBot-users] question about SWTBotText.notifyKeyboardEvent(..)

[Hans S. <han...@ya...>]

I think there should be two modes for setting text. The simple one is to use the setText(...) method directly (inside SWTBot of course).

The other one are keypress events for each letter which needs to be set as text.

A commercial tool had a recording option to either record all the keypress events when text is input or to use the much simpler setText(...) command.



--- On Sat, 11/15/08, Phil Quitslund <phi...@in...> wrote:
From: Phil Quitslund <phi...@in...>
Subject: Re: [SWTBot-users] question about SWTBotText.notifyKeyboardEvent(..)
To: swt...@li...
Date: Saturday, November 15, 2008, 10:57 PM

Hey Ketan,

Thanks for this.  On the surface it does work but it has (for me) the 
unfortunate side effect that my running test needs to have keyboard focus. 
Ideally, I'd like not to have to require this.  Since this is really part
of a 
bigger theme, I've picked up on it in a separate thread (re: Background 
Exceution).  I look forward to your thoughts!


-phil



Ketan Padegaonkar wrote:
> Hi Phil,
> 
> This snippet perhaps? It worked on macosx for me.
> 
> private void traverse(Display d) {
> 	// tab ten times
> 	for (int i = 0; i < 10; i++) {
> 		d.post(tabDown());
> 		d.post(tabUp());
> 		try {
> 			Thread.sleep(100);
> 		} catch (InterruptedException niceTry) {
> 		}
> 	}
> }
> 
> private Event tabDown() {
> 	Event event = new Event();
> 	event.type = SWT.KeyDown;
> 	event.keyCode = SWT.TAB;
> 	event.character = SWT.TAB;
> 	return event;
> }
> 
> private Event tabUp() {
> 	Event event = new Event();
> 	event.type = SWT.KeyUp;
> 	event.keyCode = SWT.TAB;
> 	event.character = SWT.TAB;
> 	return event;
> }
> 
> -- Ketan
> 
> 
> Phil Quitslund wrote:
>> Hey all,
>>
>> Looking at SWTBotText.notifyKeyboardEvent(int, char, int), I notice
that after 
>> key down and up events are posted a setText(..) is called.  Is there
no other 
>> way?   (Programmatic setting of text values doesn't feel quite
right and 
>> generates behavior that's a bit different than the "real
thing" --- notably the 
>> cursor does not advance...)  I tried removing it and, unsurprisingly,
the 
>> desired text was not entered/typed.  My next thought was to fill in
more of the 
>> event details. Specifically by synthesizing and posting the
VerifyEvent and 
>> ModifyEvent that occur between the key down and up but nothing doing.
>>
>> Any thoughts?
>>
>> Thanks!
>>
>>
>> -phil
>>
>>
>>
-------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
>> Build the coolest Linux based applications with Moblin SDK & win
great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> SWTBot-users mailing list
>> SWT...@li...
>> https://lists.sourceforge.net/lists/listinfo/swtbot-users
>> http://swtbot.org/ - a functional testing tool for SWT/Eclipse
>>
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SWTBot-users mailing list
> SWT...@li...
> https://lists.sourceforge.net/lists/listinfo/swtbot-users
> http://swtbot.org/ - a functional testing tool for SWT/Eclipse
> 
> 

-- 
Phil Quitslund
Instantiations, Inc.
http://www.instantiations.com

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SWTBot-users mailing list
SWT...@li...
https://lists.sourceforge.net/lists/listinfo/swtbot-users
http://swtbot.org/ - a functional testing tool for SWT/Eclipse




      

Re: [SWTBot-users] "Background" Execution?

[Phil Q. <phi...@in...>]

Hey Ketan,

 > +1.

Glad you share the interest!

> There's two issues in the new feature request that you mention here:
> 1. maintaining state about the active window.
> 2. being able to send events using display.post for certain types of 
> events and widget.notifyListeners for some other types of listeners.

Do you know offhand which events require special casing?  (And are there tests?)

> I do have some ideas about internally maintain some information about 
> the active shell:
> 1. Add a display filter (or listener) that keeps track of the active shell.
> 2. Have the user *explicitly* declare the active shell whenever the user 
> expects the shell to change, e.g. after clicking finish on some dialog.
> 
> There could be more to this list.

I have some ideas on this too...  Do you have any test cases committed?  If not, 
would you be interested in collaborating on some?

> However the one thing that does get into the way of checking emails 
> while running tests is the fact that new swt windows always open up in 
> the foreground, and there's no way for SWTBot to open them up in a 
> 'minimized' state.

This is an interesting point.  I wonder how this is done and whether we can 
intercept and override this default behavior.  I'll poke around --- ultimately 
this may be a question for the SWT gurus.  (Have you talked to them about this BTW?)

> Reg being able to send events using display.post and 
> widget.notifyListeners, I think something like Simon Stewart's Webdriver 
> (http://code.google.com/p/webdriver/) might be of help.
> 
> Webdriver is slated to become selenium 2.0, and does a lot of ground 
> breaking stuff. It uses specific implementations for a particular os, 
> and browser implementation. This allows drivers to do something 
> different with each browser/os implementation. I feel this is one way 
> that SWTBot could take in order to do stuff across platforms, since that 
> is the only other way to go about things.

+1.  A library of native eclipse drivers would be a great boon.  Is this 
something anyone is actively researching?


Thanks!


-phil

Re: [SWTBot-users] "Background" Execution?

[Ketan P. <ket...@gm...>]

+1. I would love to have this background execution feature, in SWTBot.
In addition to what you mention, it would also allow you to parallelize
tests, which is a *big* win.

Your assessment of the problem is also correct, the notion of 'active
shell' is what is keeping SWTBot back. SWTBot always looks up widgets in
the active shell.

There's two issues in the new feature request that you mention here:
1. maintaining state about the active window.
2. being able to send events using display.post for certain types of
events and widget.notifyListeners for some other types of listeners.

I do have some ideas about internally maintain some information about
the active shell:
1. Add a display filter (or listener) that keeps track of the active shell.
2. Have the user *explicitly* declare the active shell whenever the user
expects the shell to change, e.g. after clicking finish on some dialog.

There could be more to this list.

However the one thing that does get into the way of checking emails
while running tests is the fact that new swt windows always open up in
the foreground, and there's no way for SWTBot to open them up in a
'minimized' state.


Reg being able to send events using display.post and
widget.notifyListeners, I think something like Simon Stewart's Webdriver
(http://code.google.com/p/webdriver/) might be of help.

Webdriver is slated to become selenium 2.0, and does a lot of ground
breaking stuff. It uses specific implementations for a particular os,
and browser implementation. This allows drivers to do something
different with each browser/os implementation.

Here's an implementation for safari on macosx
http://code.google.com/p/webdriver/source/browse/trunk/safari/src/java/org/openqa/selenium/safari/SafariWebElement.java

public void sendKeys(CharSequence... value) {
     StringBuilder builder = new StringBuilder();
     for (CharSequence seq : value)
         builder.append(seq);

     appleScript.executeJavascript(locator + ".focus()");
     appleScript.executeApplescript(
                     "tell application \"System Events\"\r" +
                     "    keystroke (\"" + builder.toString() + "\")\r" +
                     "end tell");
     appleScript.executeJavascript(locator + ".blur()");
}

And and yet another implementation for ie on windows that goes native
(http://code.google.com/p/webdriver/source/browse/trunk/jobbie/src/java/org/openqa/selenium/ie/InternetExplorerElement.java)
private native void doSendKeys(String string);

The

-- Ketan

Phil Quitslund wrote:
> Hey all,
> 
> A bit of a question about philosophy.  One of the things that really interested 
> me when I saw that SWTBot dispatches events directly to the widgets themselves 
> (vs. the Display) is the idea that perhaps tests could be run in the 
> "background" --- which is to say without requiring keyboard focus or control of 
> the mouse.  This is a perk since it means one can run tests while continuing to 
> code, check mail, etc.  Is this a desired property?  In practice, I'm seeing 
> some things in the implementation (notably how the "active shell" is derived) 
> that pull against this idea so I wonder if I was just under a mistaken 
> impression.  Anyway, I'm curious if this is a feature that is even on the radar. 
>   Do other folks think this would be valuable?  General thoughts?
> 
> Thanks!
> 
> 
> -phil
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SWTBot-users mailing list
> SWT...@li...
> https://lists.sourceforge.net/lists/listinfo/swtbot-users
> http://swtbot.org/ - a functional testing tool for SWT/Eclipse
> 

Re: [SWTBot-users] "Background" Execution?

[Ketan P. <ket...@gm...>]

+1. I would love to have this background execution feature, in SWTBot. 
In addition to what you mention, it would also allow you to parallelize 
tests, which is a *big* win.

Your assessment of the problem is also correct, the notion of 'active 
shell' is what is keeping SWTBot back. SWTBot always looks up widgets in 
the active shell.

There's two issues in the new feature request that you mention here:
1. maintaining state about the active window.
2. being able to send events using display.post for certain types of 
events and widget.notifyListeners for some other types of listeners.

I do have some ideas about internally maintain some information about 
the active shell:
1. Add a display filter (or listener) that keeps track of the active shell.
2. Have the user *explicitly* declare the active shell whenever the user 
expects the shell to change, e.g. after clicking finish on some dialog.

There could be more to this list.

However the one thing that does get into the way of checking emails 
while running tests is the fact that new swt windows always open up in 
the foreground, and there's no way for SWTBot to open them up in a 
'minimized' state.


Reg being able to send events using display.post and 
widget.notifyListeners, I think something like Simon Stewart's Webdriver 
(http://code.google.com/p/webdriver/) might be of help.

Webdriver is slated to become selenium 2.0, and does a lot of ground 
breaking stuff. It uses specific implementations for a particular os, 
and browser implementation. This allows drivers to do something 
different with each browser/os implementation. I feel this is one way 
that SWTBot could take in order to do stuff across platforms, since that 
is the only other way to go about things.

Here's an implementation for safari on macosx 
http://code.google.com/p/webdriver/source/browse/trunk/safari/src/java/org/openqa/selenium/safari/SafariWebElement.java

public void sendKeys(CharSequence... value) {
     StringBuilder builder = new StringBuilder();
     for (CharSequence seq : value)
         builder.append(seq);

     appleScript.executeJavascript(locator + ".focus()");
     appleScript.executeApplescript(
                     "tell application \"System Events\"\r" +
                     "    keystroke (\"" + builder.toString() + "\")\r" +
                     "end tell");
     appleScript.executeJavascript(locator + ".blur()");
}

And and yet another implementation for ie on windows that goes native 
(http://code.google.com/p/webdriver/source/browse/trunk/jobbie/src/java/org/openqa/selenium/ie/InternetExplorerElement.java)
private native void doSendKeys(String string);

-- Ketan

Phil Quitslund wrote:
> Hey all,
> 
> A bit of a question about philosophy.  One of the things that really interested 
> me when I saw that SWTBot dispatches events directly to the widgets themselves 
> (vs. the Display) is the idea that perhaps tests could be run in the 
> "background" --- which is to say without requiring keyboard focus or control of 
> the mouse.  This is a perk since it means one can run tests while continuing to 
> code, check mail, etc.  Is this a desired property?  In practice, I'm seeing 
> some things in the implementation (notably how the "active shell" is derived) 
> that pull against this idea so I wonder if I was just under a mistaken 
> impression.  Anyway, I'm curious if this is a feature that is even on the radar. 
>   Do other folks think this would be valuable?  General thoughts?
> 
> Thanks!
> 
> 
> -phil
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SWTBot-users mailing list
> SWT...@li...
> https://lists.sourceforge.net/lists/listinfo/swtbot-users
> http://swtbot.org/ - a functional testing tool for SWT/Eclipse
> 

Re: [SWTBot-users] question about SWTBotText.notifyKeyboardEvent(..)

[Phil Q. <phi...@in...>]

Hey Ketan,

Thanks for this.  On the surface it does work but it has (for me) the 
unfortunate side effect that my running test needs to have keyboard focus. 
Ideally, I'd like not to have to require this.  Since this is really part of a 
bigger theme, I've picked up on it in a separate thread (re: Background 
Exceution).  I look forward to your thoughts!


-phil



Ketan Padegaonkar wrote:
> Hi Phil,
> 
> This snippet perhaps? It worked on macosx for me.
> 
> private void traverse(Display d) {
> 	// tab ten times
> 	for (int i = 0; i < 10; i++) {
> 		d.post(tabDown());
> 		d.post(tabUp());
> 		try {
> 			Thread.sleep(100);
> 		} catch (InterruptedException niceTry) {
> 		}
> 	}
> }
> 
> private Event tabDown() {
> 	Event event = new Event();
> 	event.type = SWT.KeyDown;
> 	event.keyCode = SWT.TAB;
> 	event.character = SWT.TAB;
> 	return event;
> }
> 
> private Event tabUp() {
> 	Event event = new Event();
> 	event.type = SWT.KeyUp;
> 	event.keyCode = SWT.TAB;
> 	event.character = SWT.TAB;
> 	return event;
> }
> 
> -- Ketan
> 
> 
> Phil Quitslund wrote:
>> Hey all,
>>
>> Looking at SWTBotText.notifyKeyboardEvent(int, char, int), I notice that after 
>> key down and up events are posted a setText(..) is called.  Is there no other 
>> way?   (Programmatic setting of text values doesn't feel quite right and 
>> generates behavior that's a bit different than the "real thing" --- notably the 
>> cursor does not advance...)  I tried removing it and, unsurprisingly, the 
>> desired text was not entered/typed.  My next thought was to fill in more of the 
>> event details. Specifically by synthesizing and posting the VerifyEvent and 
>> ModifyEvent that occur between the key down and up but nothing doing.
>>
>> Any thoughts?
>>
>> Thanks!
>>
>>
>> -phil
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> SWTBot-users mailing list
>> SWT...@li...
>> https://lists.sourceforge.net/lists/listinfo/swtbot-users
>> http://swtbot.org/ - a functional testing tool for SWT/Eclipse
>>
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SWTBot-users mailing list
> SWT...@li...
> https://lists.sourceforge.net/lists/listinfo/swtbot-users
> http://swtbot.org/ - a functional testing tool for SWT/Eclipse
> 
> 

-- 
Phil Quitslund
Instantiations, Inc.
http://www.instantiations.com

[SWTBot-users] "Background" Execution?

[Phil Q. <phi...@in...>]

Hey all,

A bit of a question about philosophy.  One of the things that really interested 
me when I saw that SWTBot dispatches events directly to the widgets themselves 
(vs. the Display) is the idea that perhaps tests could be run in the 
"background" --- which is to say without requiring keyboard focus or control of 
the mouse.  This is a perk since it means one can run tests while continuing to 
code, check mail, etc.  Is this a desired property?  In practice, I'm seeing 
some things in the implementation (notably how the "active shell" is derived) 
that pull against this idea so I wonder if I was just under a mistaken 
impression.  Anyway, I'm curious if this is a feature that is even on the radar. 
  Do other folks think this would be valuable?  General thoughts?

Thanks!


-phil

Re: [SWTBot-users] question about SWTBotText.notifyKeyboardEvent(..)

[Ketan P. <ket...@gm...>]

Hi Phil,

This snippet perhaps? It worked on macosx for me.

private void traverse(Display d) {
	// tab ten times
	for (int i = 0; i < 10; i++) {
		d.post(tabDown());
		d.post(tabUp());
		try {
			Thread.sleep(100);
		} catch (InterruptedException niceTry) {
		}
	}
}

private Event tabDown() {
	Event event = new Event();
	event.type = SWT.KeyDown;
	event.keyCode = SWT.TAB;
	event.character = SWT.TAB;
	return event;
}

private Event tabUp() {
	Event event = new Event();
	event.type = SWT.KeyUp;
	event.keyCode = SWT.TAB;
	event.character = SWT.TAB;
	return event;
}

-- Ketan


Phil Quitslund wrote:
> Hey all,
> 
> Looking at SWTBotText.notifyKeyboardEvent(int, char, int), I notice that after 
> key down and up events are posted a setText(..) is called.  Is there no other 
> way?   (Programmatic setting of text values doesn't feel quite right and 
> generates behavior that's a bit different than the "real thing" --- notably the 
> cursor does not advance...)  I tried removing it and, unsurprisingly, the 
> desired text was not entered/typed.  My next thought was to fill in more of the 
> event details. Specifically by synthesizing and posting the VerifyEvent and 
> ModifyEvent that occur between the key down and up but nothing doing.
> 
> Any thoughts?
> 
> Thanks!
> 
> 
> -phil
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SWTBot-users mailing list
> SWT...@li...
> https://lists.sourceforge.net/lists/listinfo/swtbot-users
> http://swtbot.org/ - a functional testing tool for SWT/Eclipse
> 

[SWTBot-users] question about SWTBotText.notifyKeyboardEvent(..)

[Phil Q. <phi...@in...>]

Hey all,

Looking at SWTBotText.notifyKeyboardEvent(int, char, int), I notice that after 
key down and up events are posted a setText(..) is called.  Is there no other 
way?   (Programmatic setting of text values doesn't feel quite right and 
generates behavior that's a bit different than the "real thing" --- notably the 
cursor does not advance...)  I tried removing it and, unsurprisingly, the 
desired text was not entered/typed.  My next thought was to fill in more of the 
event details. Specifically by synthesizing and posting the VerifyEvent and 
ModifyEvent that occur between the key down and up but nothing doing.

Any thoughts?

Thanks!


-phil

Re: [SWTBot-users] [Fwd: SWTBot Creation Review]

[Hans S. <han...@ya...>]

Great news! Congratulations. 

FYI:

The SWTBot project creation review was completed, and the project will 
be provisioned in the next few days.

-- Ketan



      

Re: [SWTBot-users] Dependency Injection and Inversion of Control

[Ketan P. <ket...@gm...>]

Jain, Ankit wrote:
> Hi Ketan,
> 
> You said it right way to extend SWTBot functionality, Even I am also
> doing the same. But I have concern with the existing API.
> Let's take an example of SWTBotTable. Here the method getTableItem() is
> private. So Again one has to write the same method in Extending
> class(e.g MySWTBotTable extends SWTBotTable). I think these method
> should be made protected so that code reusability remains. 

Making methods protected would mean additional API that needs to be 
maintained. Also the getTableItem() is actually public api. What version 
of SWTBot are you using ?

> Almost all classes in SWTBot I have extended, and I am copying many
> private methods to the extended class, which is not good.

Doing this may not work in the long run, esp as SWTBot api evolves. I'd 
recommend asking on the mailing list, and perhaps filing a bug.
-- Ketan

Re: [SWTBot-users] Dependency Injection and Inversion of Control

[Jain, A. <ank...@ca...>]

Hi Ketan,

You said it right way to extend SWTBot functionality, Even I am also
doing the same. But I have concern with the existing API.
Let's take an example of SWTBotTable. Here the method getTableItem() is
private. So Again one has to write the same method in Extending
class(e.g MySWTBotTable extends SWTBotTable). I think these method
should be made protected so that code reusability remains. 

Almost all classes in SWTBot I have extended, and I am copying many
private methods to the extended class, which is not good.

Ankit

-----Original Message-----
From: Ketan Padegaonkar [mailto:ket...@gm...] 
Sent: Tuesday, November 11, 2008 10:26 PM
To: swt...@li...
Subject: Re: [SWTBot-users] Dependency Injection and Inversion of
Control

Hi Hans,

Providing an implementation of widgets using the way you recommend seems

to be an overkill and potential problems for the following reasons:
1. If there is a new api in the interface, then your implementation of 
the interface will break. Which happens very often.
2. Creates unnecessary complications in the code where classes are 
instantiated via reflection, and the actual widget is constructor 
injected into your implementation.

The other alternative which we're doing is to override SWTBotTestCase 
and provide another implementation of the "bot" instance:

public abstract class MySWTBotTestCase extends SWTBotTestCase {
   protected MySWTBot bot = new MySWTBot();
}

Your test cases could extend from MySWTBotTestCase instead.

Also if you need to provide an alternative implementation for say table,

you'd override the table api to return MySWTBotTable instead of
SWTBotTable

MySWTBotTable could extend from SWTBotTable, to override API that is 
broken, or you wish to provide an alternative implementation.

It's a bit of a workaround, but is not very difficult to implement once 
you have the basic infrastructure in place.

Alternatively you could provide a patch for another implementation of 
SWTBot, that's completely API compatible with the existing one, and 
users could use either implementations.

-- Ketan

Hans Schwaebli wrote:
> Hi Ketan,
> 
> here is one idea which I think about for a while.
> 
> It is not so easy to modify SWTBot's behavior by not changing SWTBot 
> code itself.
> 
> Sometimes I might need a different behavior, like a different matching

> strategy. Or I'd like to use a own implementation of SWTBotTreeItem
(or 
> extending the original and just overwriting one method).
> 
> The solution would be to use dependency injection and inversion of 
> control. I haven't worked awful lot with this concept, but it adds a
lot 
> of flexibility without code change of 3rd party components.
> 
> This would mean that for example SWTBotTable would be an interface and

> there would be a SWTBotTableImpl concrete class. People could change
the 
> class used by SWTBot by setting it with bot.setTableImpl(new 
> MySWTBotTableImpl()) for instance.
> 
> It would also provide a good workaround until a bug has been solved in

> SWTBot or so.
> 


------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SWTBot-users mailing list
SWT...@li...
https://lists.sourceforge.net/lists/listinfo/swtbot-users
http://swtbot.org/ - a functional testing tool for SWT/Eclipse

[SWTBot-users] [Fwd: SWTBot Creation Review]

[Ketan P. <ket...@gm...>]

FYI:

The SWTBot project creation review was completed, and the project will 
be provisioned in the next few days.

-- Ketan

-------- Original Message --------
Subject: SWTBot Creation Review
Date: Tue, 11 Nov 2008 16:50:17 +0000 (UTC)
From: Anne Jacko
Organization: Eclipse
Newsgroups: eclipse.swtbot

Hello all,

Since there has not been a request from a member of the Eclipse community
to hold this Review on a conference call, there will be no Review Call
tomorrow, Wednesday, November 12.

The EMO has declared this review to be successful based on the review
docuware and on community feedback. Congratulations to the SWTBot team on
their successful Creation Review.

Please contact em...@ec... with any questions. Thanks.

Re: [SWTBot-users] Dependency Injection and Inversion of Control

[Ketan P. <ket...@gm...>]

Hi Hans,

Providing an implementation of widgets using the way you recommend seems 
to be an overkill and potential problems for the following reasons:
1. If there is a new api in the interface, then your implementation of 
the interface will break. Which happens very often.
2. Creates unnecessary complications in the code where classes are 
instantiated via reflection, and the actual widget is constructor 
injected into your implementation.

The other alternative which we're doing is to override SWTBotTestCase 
and provide another implementation of the "bot" instance:

public abstract class MySWTBotTestCase extends SWTBotTestCase {
   protected MySWTBot bot = new MySWTBot();
}

Your test cases could extend from MySWTBotTestCase instead.

Also if you need to provide an alternative implementation for say table, 
you'd override the table api to return MySWTBotTable instead of SWTBotTable

MySWTBotTable could extend from SWTBotTable, to override API that is 
broken, or you wish to provide an alternative implementation.

It's a bit of a workaround, but is not very difficult to implement once 
you have the basic infrastructure in place.

Alternatively you could provide a patch for another implementation of 
SWTBot, that's completely API compatible with the existing one, and 
users could use either implementations.

-- Ketan

Hans Schwaebli wrote:
> Hi Ketan,
> 
> here is one idea which I think about for a while.
> 
> It is not so easy to modify SWTBot's behavior by not changing SWTBot 
> code itself.
> 
> Sometimes I might need a different behavior, like a different matching 
> strategy. Or I'd like to use a own implementation of SWTBotTreeItem (or 
> extending the original and just overwriting one method).
> 
> The solution would be to use dependency injection and inversion of 
> control. I haven't worked awful lot with this concept, but it adds a lot 
> of flexibility without code change of 3rd party components.
> 
> This would mean that for example SWTBotTable would be an interface and 
> there would be a SWTBotTableImpl concrete class. People could change the 
> class used by SWTBot by setting it with bot.setTableImpl(new 
> MySWTBotTableImpl()) for instance.
> 
> It would also provide a good workaround until a bug has been solved in 
> SWTBot or so.
> 

[SWTBot-users] Dependency Injection and Inversion of Control

[Hans S. <han...@ya...>]

Hi Ketan,

here is one idea which I think about for a while.

It is not so easy to modify SWTBot's behavior by not changing SWTBot code itself.

Sometimes I might need a different behavior, like a different matching strategy. Or I'd like to use a own implementation of SWTBotTreeItem (or extending the original and just overwriting one method).

The solution would be to use dependency injection and inversion of control. I haven't worked awful lot with this concept, but it adds a lot of flexibility without code change of 3rd party components.

This would mean that for example SWTBotTable would be an interface and there would be a SWTBotTableImpl concrete class. People could change the class used by SWTBot by setting it with bot.setTableImpl(new MySWTBotTableImpl()) for instance.

It would also provide a good workaround until a bug has been solved in SWTBot or so.



      

Re: [SWTBot-users] Nebula: DateChooserCombo and FormattedText

[Ketan P. <ket...@gm...>]

Great to know that someone is starting off with nebula.

Hans Schwaebli wrote:
> I may have to add SWTBot support for two Nebula widgets soon: 
> DateChooserCombo and FormattedText.
> 
> Currently I am estimating the effort.
> 
> I think two new classes would need to be added: SWTBotDateChooserCombo 
> and SWTBotFormattedText.

That is correct.

> Do you want to add methods in SWTBot class for them? Or a bot class just 
> for Nebula widgets ("SWTNebulaBot")? Do you want a new plugin and test 
> plugin for Nebula? What are your plans and ideas?

SWTBot 2.0 takes a different approach to this problem. It generates, yes 
generates the SWTBot class based on annotations provided on the 
individual widgets.

See the annotations on SWTBotButton and SWTBotCheckBox for examples on 
how these are used.

SWTBotGeneratorMain generates the SWTBot class based on the types 
provided in a widgets.xml file.

> Of course we also need test cases for them. Nebula provides an example 
> plugin, which can be used for these tests. Is it okay to use it?

For the sake of nebula, I'd suggest a separate net.sf.swtbot.nebula and 
a corresponding .test plugin. This would help avoid a nebula dependency 
on the net.sf.swtbot.finder project, and keep the footprint small.

In case you need to write a matcher for a nebula widget, you'll need to 
generate a WidgetMatcherFactory using MatcherGeneratorMain.

-- Ketan

[SWTBot-users] Nebula: DateChooserCombo and FormattedText

[Hans S. <han...@ya...>]

I may have to add SWTBot support for two Nebula widgets soon: DateChooserCombo and FormattedText.

Currently I am estimating the effort.

I think two new classes would need to be added: SWTBotDateChooserCombo and SWTBotFormattedText.

Do you want to add methods in SWTBot class for them? Or a bot class just for Nebula widgets ("SWTNebulaBot")? Do you want a new plugin and test plugin for Nebula? What are your plans and ideas?

Of course we also need test cases for them. Nebula provides an example plugin, which can be used for these tests. Is it okay to use it?

I need to know this in order to write a patch the way you agree with. 



      

Re: [SWTBot-users] Performance optimization for SWTBot

[Hans S. <han...@ya...>]

Yes, that would be good. Performance is one advantage. The other advantage is logging output. It was confusing for me to see that SWTBot searched after it already found a matching widget. Thats how I knew that it continues searching.

Now a bit of something else, which has nothing to do with this topic. A bit of design philosophy.

I am not yet familiar with all the patterns used in SWTBot. The logic jumps across different methods and classes in different hierarchies. Thats good usage of design patterns but sometimes harder to understand than a method (or a few of them, mostly in the same class) where all the logic is implemented.

In a former project some co-workers were in my mind too fascinated of design patterns and for example used a state pattern where a simple if-else-if-else-if-else would have been sufficient and more easy to understand, document (UML and Javadoc), debug etc.

Well its not yet too difficult to understand what happens inside SWTBot. But I just mean this as a kind of personal opinion that sometimes design patterns can be overused (which is not yet the case here I think).


--- On Fri, 11/7/08, Ketan Padegaonkar <ket...@gm...> wrote:
From: Ketan Padegaonkar <ket...@gm...>
Subject: Re: [SWTBot-users] Performance optimization for SWTBot
To: swt...@li...
Date: Friday, November 7, 2008, 1:43 PM


Hans Schwaebli wrote:
> I have a suggestion for improving performance.
> 
> I have seen that finding widgets by label collects all widgets it can 
> find and then it returns the widget by index. Often the index is 0. So 
> SWTBot could stop searching as soon as it finds the first widget 
> matching the criteria. Or if its the second widget which needs to be 
> found by label, it could stop searching as soon as it finds the second.

Yes, that is quite correct. In fact SWTBot does that for all matchers, 
it always finds all the widgets that matched a particular widget and the 
selection based on the index is done at the end.

This was done earlier to keep the API clean and simple, I'm however 
convinced that this is a good place to optimize, and can infact be 
scaled up to any number of finds. So we could stop looking after say 2 
matches, if the user requested the 2nd widget.

-- Ketan

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SWTBot-users mailing list
SWT...@li...
https://lists.sourceforge.net/lists/listinfo/swtbot-users
http://swtbot.org/ - a functional testing tool for SWT/Eclipse




      

Re: [SWTBot-users] Performance optimization for SWTBot

[Ketan P. <ket...@gm...>]

Hans Schwaebli wrote:
> I have a suggestion for improving performance.
> 
> I have seen that finding widgets by label collects all widgets it can 
> find and then it returns the widget by index. Often the index is 0. So 
> SWTBot could stop searching as soon as it finds the first widget 
> matching the criteria. Or if its the second widget which needs to be 
> found by label, it could stop searching as soon as it finds the second.

Yes, that is quite correct. In fact SWTBot does that for all matchers, 
it always finds all the widgets that matched a particular widget and the 
selection based on the index is done at the end.

This was done earlier to keep the API clean and simple, I'm however 
convinced that this is a good place to optimize, and can infact be 
scaled up to any number of finds. So we could stop looking after say 2 
matches, if the user requested the 2nd widget.

-- Ketan

Re: [SWTBot-users] Performance optimization for SWTBot

[Hans S. <han...@ya...>]

I have a suggestion for improving performance.

I have seen that finding widgets by label collects all widgets it can find and then it returns the widget by index. Often the index is 0. So SWTBot could stop searching as soon as it finds the first widget matching the criteria. Or if its the second widget which needs to be found by label, it could stop searching as soon as it finds the second.



--- On Sun, 10/26/08, Ketan Padegaonkar <ket...@gm...> wrote:
From: Ketan Padegaonkar <ket...@gm...>
Subject: Re: [SWTBot-users] Performance optimization for SWTBot
To: swt...@li...
Date: Sunday, October 26, 2008, 10:15 AM

Hi,

I've uploaded the latest 2.0 with some performance optimizations,  
there were a few tests that locked up and froze the UI but that has  
been fixed.

I'm not sure if this was the only freezing issue. If anyone is using  
2.0, I'd like to hear of any issues with the latest available at
http://swtbot.sourceforge.net/artifacts/2.0-dev/ 
.

-- Ketan

On 26-Oct-08, at 12:05 AM, Ketan Padegaonkar wrote:

> Hi,
>
> I'm working on improving the performance of SWTBot, and am looking  
> for ideas or areas where SWTBot could be made faster. Not that it is  
> very slow, but hey turning a few knobs to get a little extra does  
> not hurt!
>
> If you have something that'll help optimize the performance for the  
> better, then I'm all ears. It may even be a single statement that  
> you think will slow down SWTBot, or things that make you say: "why  
> is this thing so very complicated?"
>
> I have a few ideas like removing unnecessary log statements etc. My  
> mind is clearly out of ideas, since I know most of the code base  
> inside out. So a fresh pair of eyes would help.
>
> -- Ketan
>



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SWTBot-users mailing list
SWT...@li...
https://lists.sourceforge.net/lists/listinfo/swtbot-users
http://swtbot.org/ - a functional testing tool for SWT/Eclipse




      

Re: [SWTBot-users] Why SWTBot sometimes does not find widgets by label

[Ketan P. <ket...@gm...>]

The earlier implementation just flattens the entire UI hierarchy finds
a widget of a particular type, and starts walking backwards to find a
label. Which does not seem to be the right thing to do, but works in
most cases.

The new implementation does this:

protected boolean doMatch(Object obj) {
	Widget previousWidget = SWTUtils.previousWidget((Widget) obj);
	if ((previousWidget instanceof Label) &&
mnemonicTextMatcher.matches(previousWidget))
		return true;
	return false;
}

Which means that it finds the _immediate previous sibling_ and matches
it for the specified label. Which seems to be the right thing to do,
but does not work in most cases.

Any suggestions to find a middle ground ? I'm thinking along the lines
of making this search fuzzy, which means flatten the hierarchy, but
don't walk backwards all the way to the shell, but stop after say 5
widgets.

-- Ketan

On Thu, Nov 6, 2008 at 9:29 PM, Hans Schwaebli <han...@ya...> wrote:
> I could not find a widget by label today. Previously it found the widget by
> label. But the development team changed the implementation from
>
>     final Label functionalGroupLabel = new Label(selectTeardownGroup,
> SWT.NONE);
>
> to:
>
>     final Composite funGpCom = new Composite(selectTeardownGroup, SWT.NONE);
>     funGpCom.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, false,
> false));
>     funGpCom.setLayout(new GridLayout());
>     final Label functionalGroupLabel = new Label(funGpCom, SWT.NONE);
>
> Could it be that this is the reason why SWTBot sometimes does not find
> widgets by label?
>
> The other labels where I cannot find the widget for it are similiar
> implemented.
>
> Does this give you a clue and if yes, can you please fix it?
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SWTBot-users mailing list
> SWT...@li...
> https://lists.sourceforge.net/lists/listinfo/swtbot-users
> http://swtbot.org/ - a functional testing tool for SWT/Eclipse
>
>
>



-- 
Ketan Padegaonkar
I blog... therefore I am... http://ketan.padegaonkar.name
http://swtbot.org/ - a functional testing tool for SWT/Eclipse

[SWTBot-users] Why SWTBot sometimes does not find widgets by label

[Hans S. <han...@ya...>]

I could not find a widget by label today. Previously it found the widget by label. But the development team changed the implementation from

    final Label functionalGroupLabel = new Label(selectTeardownGroup, SWT.NONE);

to:

    final Composite funGpCom = new Composite(selectTeardownGroup, SWT.NONE);
    funGpCom.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, false, false));
    funGpCom.setLayout(new GridLayout());
    final Label functionalGroupLabel = new Label(funGpCom, SWT.NONE);

Could it be that this is the reason why SWTBot sometimes does not find widgets by label?

The other labels where I cannot find the widget for it are similiar implemented.

Does this give you a clue and if yes, can you please fix it?



      

[SWTBot-users] Changes in SWTBot license from Apache License 2.0 to EPL

[Ketan P. <ket...@gm...>]

Hi,

I'd like to take this opportunity to thank all the contributors and 
committers for their consent in changing the SWTBot license to EPL.

I'll eventually be changing the license text in the source code headers 
in the course of the next few days.

I'll be dropping support for ExpandItem/ExpandBar since I've not 
received any consent.

-- Ketan