Community
Participate
Working Groups
Support GUI test tools. SWT should provide common facilties and APIs so that GUI test tools can integrate with SWT-based UIs. [SWT]
Tom, The UI team would be interested in exploring the use of Abbott to test our commands and keybindings infrastructure, and perhaps other areas of our test suites. Could you please let us know: - how close is this to being open source and under which license will it be open sourced (i.e., if it makes sense for us to use Abbott, how soon could we include it in the eclipse.org repository)? - what other code does this bring in (e.g. we don't want to require Swing) - is it possible to generate key events to a window overall, rather than a specific control in the window (our key bindings mechanism is implemented using Display.addFilter, so it gets first crack at key events before any controls)? Thanks, Nick
Please excuse my delay in following up to bugzilla. I posted to Nick separately about this awhile back; I'm adding some more recent stuff as well. Nick Edgar 2003-09-15 15:47 ------- > The UI team would be interested in exploring the use of [Abbot] to > test our commands and keybindings infrastructure, and perhaps other > areas of our test suites. > Could you please let us know: > - how close is this to being open source and under which license > will it be open sourced (i.e., if it makes sense for us to use > [Abbot], how soon could we include it in the eclipse.org repository)? The license will be CPL, since Abbot itself is available under CPL. "Closeness to release" is harder to determine, since that's the lawyers' call. (And harder to talk about, since the lawyers don't even like that.) However the process is currently such that we should have a pretty good idea by mid-Nov 03. > - what other code does this bring in (e.g. we don't want to require > Swing) Both abbotforswt and Abbot are in a sense superstructural to javax.awt.Robot. Fortunately that is part of J2SE, and will therefore be found in any compliant JDK. I have been told that it (and its dependencies) are part of both "the IBM JDK" and the J2SE version of J9. (I have no idea why one is privileged over the other--are they both not JDKs from IBM?) Note that abbotforswt has also produced a "base Robot" (i.e. our SWTized equivalent of java.awt.Robot) that is free from Abbot dependencies which we are hoping to donate to Eclipse, if desired. > - is it possible to generate key events to a window overall, rather > than a specific control in the window (our key bindings mechanism is > implemented using Display.addFilter, so it gets first crack at key > events before any controls)? I don't know. But a Window hasa shell, a parentShell, and a contents, all of which are Control's, so I'm pretty confident we could send key events to any of those--would that do? I'll make a task to check on this as soon as [the unnameable site where we manage the project] recovers from its recent upgrade. TIA, Tom Roche <tlroche@us.ibm.com> abbotforswt admin
In the past day or two, I have released two test cases to the head for platform-ui. These tests case use java.awt.Robot to generate key events at the OS-level. To do this, do the following: 1.) Grab the SWT display, and addFilter() for the type of event to listen to. 2.) Create a new Robot. 3.) Send the events you want to track. Remember to match every event with its opposite. For example, a key pressed requires a key released. Otherwise, your OS might become very unhappy. 4.) while (display.readAndDispatch());
Douglas Pollock 2003-10-22 11:05 ------- > In the past day or two, I have released two test cases to the head > for platform-ui. These tests case use java.awt.Robot to generate key > events at the OS-level. Thanks for the validation! Two questions, one suggestion: ? Could you point me at the specific testcases? ? I'm assuming that this means Nick Edgar 2003-09-15 15:47 (question -> statement) >> [it is] possible to generate key events to a window overall, rather >> than a specific control in the window (our key bindings mechanism >> is implemented using Display.addFilter, so it gets first crack at >> key events before any controls) Is that correct? (Sorry for not following up on this earlier, but deadline looms in my "real job") ! Instead of going all the way down to the j.a.R level, you might consider using abbotforswt <IBM internal URL omitted due to fear of repeat spanking by lawyers-- ping me and I'll send it> We have more usable API than > 1.) Grab the SWT display, and addFilter() for the type of event to > listen to. > 2.) Create a new Robot. > 3.) Send the events you want to track. Remember to match every event > with its opposite. For example, a key pressed requires a key > released. Otherwise, your OS might become very unhappy. > 4.) while (display.readAndDispatch()); and we might even be OSS Real Soon Now ...
Look in "org.eclipse.ui.tests" ... in the package called "org.eclipse.ui.keys". The test cases are Bug43538Test and Bug43610Test. Yes, as of M3, we rather shakily held the reins to all keys coming into the system. M4 was a lot more stable, but there are still some lingering issues to work around. If you want top-level key events yourself, display.addFilter (type,listener). Though doing so while Eclipse is running is generally frowned upon; it's supposed to be a platform-ui-keys thing only. I have adopted this approach for two reasons: 1.) We really needed test coverage a couple of months ago, and so sooner is better than later. We can't use Abbot in Eclipse until legal issues are sorted out. 2.) For the two key binding tests so far, "java.awt.Robot" appears to be perfect. We don't need much, since we are trapping keys at the top-level. We'll see what happens when things get more complicated.
Please note that * Abbot http://sourceforge.net/projects/abbot is available under CPL. * abbotforswt has received all preliminary approvals to OSS (to Abbot), and goes for final approval 27 Jan 04. * a binary plugin for Abbot (AWT/Swing) 0.11.0 is available @ http://prdownloads.sourceforge.net/abbot/abbot-0.11.0-eclipse.zip?download https://w3.opensource.ibm.com/frs/viewRelease.php?release_id=545&group_id=1023 * a binary plugin for abbotforswt (containing our SWT-ized Robot) is @ https://w3.opensource.ibm.com/frs/viewRelease.php?release_id=545&group_id=1023 It prereqs the Abbot plugin. * EA users report success with abbotforswt on both Windows and Linux. (Abbot is widely used on many platforms.)
bug 15025 has been marked as fixed (generate system key and mouse events)
The latest 3.0 plan lists this as being completed but the entry is still open, is it really considered completed?
Ed Burnette 2004-04-28 16:19 > is it really considered completed? Umm ... my group has some test automation running, but it's incomplete without https://bugs.eclipse.org/bugs/show_bug.cgi?id=38436 E.g. MenuItem picking requires a non-performant, platform-specific workaround.
Bug 38436 is one limitation which can be improved in the future (window systems permitting). We've made significant progress on this plan item, and certainly enough to declare success for 3.0.
Success? If the goal was to enable Abbot (and presumably Costello), then the inability to reasonably drive via the menu is a serious (crippling?) restriction. I would love to advocate Abbot / Costello as a viable alternative for our performance team. We're not there yet.
Please see proposed patch to enable Abbot https://bugs.eclipse.org/bugs/show_bug.cgi?id=38436.
This is no longer a plan item but ongoing maintenance. Please enter individual bug reports for any outstanding issues.
