> 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 ------------------------------------------------------------------------- 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 SWTBot-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/swtbot-users http://swtbot.org/ - a functional testing tool for SWT/Eclipse
