This will ultimately be a problem for users relying on accessibility information - it's definitely a problem for building automated tests as dogtail uses accessibility information to access GUI objects. The easiest way to implement this in a way to support dogtail and automated GUI tests may be to always supply a "description" for each GUI element - as supported by: javax.accessibility.setAccessibleDescription(String description) Sets the accessible description of this object. http://java.sun.com/products/jfc/tsc/articles/accessibility/ I've attached an example of what this looks like - as displayed by the dogtail "sniff" utility. If a unique description - unique at least within each Frame - is available, the dogtail test scripts can access all GUI elements. Without this information, multiple GUI elements such as the combo boxes in the attached screenshots cannot be accessed as dogtail will always access the same combo box.
Created attachment 988 [details] Screen shot This screen shot shows the information available for the selected combo box. Note that description is blank. The Name field cannot be reliably used as the value displayed isn't the name of the field, but rather the value selected from the combo-box. In the case of this Frame, all the combo boxes have the same role name value ("combo box") so dogtail cannot specify which one to select in a test script.
Created attachment 989 [details] Screen shot Here's another illustration - this field has a "description" value that is unique in the Frame - so, dogtail can specify the field: observerName = observerPanel.child(roleName='text', description='Enter a name for the observer')
Created attachment 998 [details] Another illustration - the lack of AT info makes edit/delete tests impossible.
Assigning to Phil - May 2, 2006
Added other gui hackers, so they might investigate thier own respective glade responsibilities.
Action item for ldimaggi - define the AT-related fields in the glade files.
Proposed standard for the AT name values for each Glade GUI widget = the widget name + a useful/mnemonic suffix (ex) vbox45 becomes vbox45_processGroupComboBox
While doing it the way you indicate sound goods, this will actually lead to a scenario where the widgets name and the AT name will differ. Also, as vboxes/hboxes/alignment and most labels are not handled in Java thier names are just left as the glade default. What you propose will take weeks of work in the monitor (there are 1000s of hboxes/vboxes/alignments/labels). The actual "real" widgets are already properly named. Could we, for the time being, just propogate the name to the AT name, and work with the long term goal of applying your mneumonic to vboxes/hboxes/alignments/labels?
In response to Phil's comment this morning (2006-05-09): YES - definitely - that's just what I had in mind. The key is to get some unique information into the AT name property. In working with some prototype test scripts for the Druid, it quickly became a headache dealing with vbox/hbox named fields (but it was still possible), but we probably won't want to even try to give better names to ALL those fields. We'll try an iterative approach on added better names.
Len, I think all AT info was exposed at this time, and we are current with the glade files? (ie because of the dogtail scripts working, I would assume so)