GNOME Bugzilla – Bug 465989
Adding panel applets
Last modified: 2008-02-19 16:12:31 UTC
Hi, when adding an applet (like weather etc.) to the gnome panel, the LayerdPane with all the available applets is anounced, but not the applets available. (When moving the cursor, the display still says "LayerdPane"). I also cannot read the area with flat review. Thanks for looking into it. Cheers, Rudolf
Just to be sure -- the dialog we're talking about is the "Add to Panel" dialog that contains a list of all sorts of applets that can be added. When arrowing around the icons in this dialog and analyzing the Orca debug output, I don't notice the events that I would expect from this panel. I would expect to get focus changed or active descendant changed or selection events. In looking at the accessible hierarchy, I see that the icons advertise themselves as STATE_FOCUSABLE (and STATE_FOCUSED when highlighted), so I suspect we're dealing with an AT-SPI implementation bug in the toolkit or in the gnome-panel custom widget if this is a custom widget. The bug is that focus: events do not seem to be issued. For the flat review problem, I see also that the STATE_SHOWING state is absent from components showing on the screen. I believe this is another AT-SPI implementation bug. :-( I'll enter some blocking bugs against gnome-panel regarding these issues.
The news from the gnome-panel team is that this is an Ubuntu bug and one needs to log a launchpad bug against them to get them to fix it. I'm not quite sure how to do that since I never set myself up with a launchpad account.
I just tried this in Solaris and sure enough things are fine there. But I'm wondering, is this a Ubuntu bug or is it an icons-in-a-layered-pane bug? I didn't see any examples of layered panes in gtk-demo. Can anyone think of other examples of layered panes? Will, if you go to https://launchpad.net/ubuntu/ you can create an account and file a bug.
(In reply to comment #3) > I just tried this in Solaris and sure enough things are fine there. But I'm > wondering, is this a Ubuntu bug or is it an icons-in-a-layered-pane bug? I > didn't see any examples of layered panes in gtk-demo. Can anyone think of > other examples of layered panes? The icon view of nautilus is composed of icons in a layered pane. :-)
D'oh! I knew that.... Thanks. :-)
Okay, I just built both gnome-panel and gnome-applets from svn trunk in Gutsy. Now the dialog *looks* like it does in Solaris, and we're getting selection-changed and active-descendant-changed events like we do in Solaris. But we're still not speaking anything in Ubuntu when the selection changes -- we do speak the right thing in Solaris. I wonder if the critical difference is a dependency that was not included....
(In reply to comment #6) > Okay, I just built both gnome-panel and gnome-applets from svn trunk in Gutsy. > Now the dialog *looks* like it does in Solaris, and we're getting > selection-changed and active-descendant-changed events like we do in Solaris. Cool. > But we're still not speaking anything in Ubuntu when the selection changes -- > we do speak the right thing in Solaris. Not cool. Do you see anything wrt to "focus:" events. For examplem, does the parent thingy (is it a tree?) get focus on Solaris but not Ubuntu?
After a couple of hours at this.... The difference seems to be -- are you ready? -- in Solaris my preferences are set to speak row and in Ubuntu my preferences are set to speak cell. In both cases, focus seems to be starting out in the first column which has an image. (And with speak cell, that column is silent). Been one of those days it seems.... Sorry! So we're back to the original problem of the Ubuntu-ized version not giving us events.... :-( On a bright side, the unadulterated version from GNOME works -- as long as you have Orca speaking rows or know to move to the second column. :-) Rudolf, that might be a decent interim fix for you.
Launchpad bug #1: https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/133795 Launchpad bug #2 https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/133796
> The difference seems to be -- are you ready? -- in Solaris my preferences are > set to speak row and in Ubuntu my preferences are set to speak cell. In both > cases, focus seems to be starting out in the first column which has an image. > (And with speak cell, that column is silent). Been one of those days it > seems.... Sorry! The silence when navigating by cell in the first column bothers me. When I look at the relevant objects and events from the Solaris table, I see the following: * All the cells on the selected row have SELECTED, FOCUSABLE, and SELECTABLE (I think the FOCUSABLE thing is a bug, but we can ignore that I think) * The active cell (defaults to the icon cell) has ACTIVE * When arrowing up and down, the table issues active descendant changed and selection changed events, and the affected cells issue state changed selected events (both when losing and gaining selection). * When arrowing left and right, the table issues active descendant changed events When 'focus' is in the first column, Orca is handling the active descendant changed event appropriately, setting the locus of focus to the cell in the first column and tossing stuff to the speech and braille generators. The problem is that the generators seem to be getting no information from the cell and present nothing as a result. It might be nice to try to say *something*, but I'm not sure what. I think we can detect it supports the Accessible Image interface and say something like "unknown image" or the image description if we can get it (the images in the table currently have no information, I believe). For where to do this, I'm not sure. We might consider modifying getDisplayedText to return image information as a fallback, or we might create a getImageText or something. Or, we might do something else. :-)
Rich - I think it would be good to get this fixed for GNOME 2.20. By taking the following approach, I think we can do this without a string change: In the xxxForTableCell methods in the speech and braille generators, do some checking to see if the cell supports the accessible image interface (obj.image) if we aren't able to obtain any other information for it. If it does support the accessible image interface, the presentation for both speech and braille should be obj.image.imageDescription + the speech/braille rolename for ROLE_IMAGE. If there is no imageDescription, then just output the speech/braille rolename for ROLE_IMAGE. I realize that Eitan doesn't like the hack of changing the rolename of an object for temporary purposes, but I think we can live with that for now until we refactor the way to get the speech for a rolename. Thus, you could just do something like obj.role = rolenames.ROLE_IMAGE, call rolenames.get{Speech,Braille}ForRoleName, and then reset the role. If you want to do the refactor, a very simple thing might be to modify rolenames.py:get{Speech,Braille,ShortBraille,LongBraille}ForRoleName to take an optional "rolename=None" parameter and use it instead of obj.role if the passed in rolename != None.
Okay, I think I understand what you want me to do (w.r.t. Orca code). Could one of you (Joanie or Will), give me step by step key sequences to get to somewhere where I can reproduce this problem please? I saw "The icon view of nautilus is composed of icons in a layered pane" above, but for me, Nautilus folder icon view nicely speaks the icon names, so I'm a tad confused. The original bug talks about panel applets. How do I get "up there"? Thanks.
Rich, I'm afraid this bug has gotten rather convoluted -- mostly, if not entirely, due to me. Sorry! So: 1. The *original bug* pertains to the inaccessibility of the Ubuntu-flavored dialog, which uses a layered pane. 2. What Will is talking about in comment #10 can be seen in the *non-flavored* version of the dialog. Solaris uses it. Alternatively you can grab gnome-panel from svn trunk and build it on Ubuntu. Having acquired the offending dialog.... The easiest way to get into it if your goal is simply to implement the fix Will suggests is to right-click on an empty area of area of your top or bottom panel and choose Add to Panel. Focus will be in the entry. Tab once to get to the table. If you have table reading set to cell, you should hear nothing because the column with focus contains an icon. Hope this helps!
> Having acquired the offending dialog.... Thanks Joanie, although I'm still slightly confused. Can't I just use the gnome-panel that Ubuntu supplies (assuming I don't need to build it from source)? The following steps seem to reproduce an it-no-speakee situation for me. 1/ Start Orca 2/ Right click on a blank area of the panel (I admit, I'm using the mouse here ;-) 3/ Select "Add to panel..." 4/ When the "Add to Panel" dialog appears, Tab twice to get focus into the icon area. Nothing is spoken. 5/ Use the arrow keys to move around. Again, nothing is spoken. If this is the original bug as reported by Rudolf, then I think I have something to work with tomorrow.
> Thanks Joanie, although I'm still slightly confused. Well, maybe you're not and I am. :-) > Can't I just use the gnome-panel that Ubuntu supplies (assuming I > don't need to build it from source)? Maybe you can. See my previous statement. :-) That said, Will said this: > In the xxxForTableCell methods in the speech > and braille generators, do some Which to me means you're working with a table. So I figured what you wanted was a table and not a layered pane. > 5/ Use the arrow keys to move around. Again, nothing is spoken. I believe that is because we're getting jack for events and not because we've selected an icon. For instance, having selected an icon/applet (crucial step), tab out of the pane and back to it. Orca will announce the name of the icon/applet. I bet if we were getting the proper focus events, we'd speak all those icons just fine as we moved amongst them. Perhaps not. > If this is the original bug as reported by Rudolf, then I think I have > something to work with tomorrow. What you described is indeed the original bug reported by Rudolf.
So this sounds like we have two separate bugs, and perhaps we should separate them into two separate bug reports. To say it's confusing would be rather an understatement. I do agree, if Will said "In the xxxForTableCell methods in the speech and braille generators," then he's indeed talking about tables. So Will, can you give me step by step instructions for running some application (don't wanna build source code here unless I have to ;-) that exhibits the problem, that would require implementing the instructions in comment #10, to fix. Thanks.
Will, no need to look any further. Joanie spelt it out in commands on one syllable, so I work from these instructions. here's what you do: 1. sudo apt-get build-dep gnome-panel 2. svn co http://svn.gnome.org/svn/gnome-panel/trunk gnome panel 3. cd gnome-panel; ./autogen.sh --prefix=/usr; make; sudo make install 4. Log out and back in. Now you've got the dialog with the table to do your thing. 5. sudo apt-get install --reinstall gnome-panel 6. Log out and back in Now you're back to normal.
> Will, no need to look any further. Joanie spelt it out in commands > on one syllable, so I work from these instructions. Excellent. Are you still looking for an answer from me on something, or do you have enough to go on now?
> Are you still looking for an answer from me on something, or do you > have enough to go on now? I think I have enough for now thanks.
Created attachment 94195 [details] [review] Patch for the gnome-2-20 branch, to implement the first suggested fix from Will in comment #11
Created attachment 94196 [details] [review] Patch for SVN HEAD, to implement the first suggested fix from Will in comment #11 in comment #11 Patches not committed yet. I want to check first if this is what's wanted. A couple notes. 1/ I didn't do the suggested refactor. I simply changed the role name, got the braille or speech for the new role type then reset it back to ROLE_TABLE_CELL. 2/ The images in the first column of the gnome-panel Add to Panel dialog do not have descriptions. So that means that we are just speaking "image". For Orca for GNOME 2.21 (i.e. SVN HEAD), perhaps we should adjust the code to something like: if obj.image.imageDescription: utterances.append(obj.image.imageDescription) else: utterances.append(_("unknown"))
Oh, that makes a huge difference!! Thanks Rich. Now that I don't have dead silence any longer (yea!), new observations: When I tab from the entry to the tree, Orca now says "image". If I'm sufficiently curious, I'll do a whereAmI, find out I'm on a cell, and hear the whole row. Having done so I'll realize that I'm in a table, that I want to use Up/Down Arrow to examine its contents, that I should move to a column with meaningful info in it or switch to speak row, etc., etc. I suspect the average user will press Tab, land on the unlabeled image, figure it's useless and not be curious about it, and press Tab again thus completely bypassing the table. I'm wondering if in the case in question, we also want to say "cell" or "table" or something to let the user know that there's more here than the unlabeled image. > speaking "image". For Orca for GNOME 2.21 (i.e. SVN HEAD), perhaps > we should adjust the code to something like: > > if obj.image.imageDescription: > utterances.append(obj.image.imageDescription) > else: > utterances.append(_("unknown")) Should we? The fact that it just says "image" (to me) implies unknown. And if we have it say "image unknown" and switch to speak row, we now have to listen to two words (that really don't add to the content of the row) prior to the name of the applet.
I'll let Mike and Will decide what they want here. I am but a humble Orca peon. ;-)
Patches checked in. Will phoned me to say: 1/ Just say "image" (no "unknown"). 2/ Possibily speaking/brailling "table" or "cell" should be handled in a separate RFE. I would set the bug state to "[pending]", but there is the separate problem of Ubuntu not giving us events for their version of gnome-panel. So it stays as "[blocked]".
(In reply to comment #11) > In the xxxForTableCell methods in the speech and braille generators, do some > checking to see if the cell supports the accessible image interface (obj.image) > if we aren't able to obtain any other information for it. The current patch first checks to see if the cell supports the image interface. If it does, just the image information is used. This is probably sufficient for most of the cases we will probably run into (i.e., a table cell with just an image in it). But, it does bypass the expandable/expanded checks -- I suspect we could run into image-only table cells that are used to represent the expanded state of a tree node. In addition, I suspect we may also run into cells that support both accessible text and accessible image. In these cases, I think we may want to first check for the displayed text and then fallback to the image information if there is no displayed text. IMO, make the change above are not show stoppers for gnome-2-20, but should be looked into for Orca v2.21.0.
Created attachment 95081 [details] [review] Patch to address concerns in comment #25 > The current patch first checks to see if the cell supports the image interface. > If it does, just the image information is used. This is probably sufficient > for most of the cases we will probably run into (i.e., a table cell with just > an image in it). But, it does bypass the expandable/expanded checks -- I > suspect we could run into image-only table cells that are used to represent > the expanded state of a tree node. > > In addition, I suspect we may also run into cells that support both accessible > text and accessible image. In these cases, I think we may want to first check > for the displayed text and then fallback to the image information if there is > no displayed text. > > IMO, make the change above are not show stoppers for gnome-2-20, but should be > looked into for Orca v2.21.0. The attached patch for SVN trunk (not committed yet) hopefully addresses these issues. I've tested it again the default gnome-panel (not the standard Ubuntu one -- see comment #17), but that doesn't go down any of the desired paths (doesn't have displayed text and an accessible image and/or expandable/collapsed tree state). If anybody has any suggestions on what does have those conditions, I'll test it further. Other testing it would be most helpful too. Thanks.
This patch I believe is still valid. I would like others to test it. Will, I would also like you to tell me if this is how you would like this fix to be done.
I had actually tested this back when you posted it Rich. But then I went off looking for examples on the other conditions, eventually gave up, and then forgot to comment. Sorry!! Just re-tested and it still works. :-)
(In reply to comment #27) > This patch I believe is still valid. I would like others > to test it. Will, I would also like you to tell me if this > is how you would like this fix to be done. > I think this is fine. As part of the pyatspi.py work, Eitan is working on the refactor to allow us to do rolename trickery. So, we can cross that path as part of the pyatspi.py integration. This looks good for gnome-2-20 and trunk. Thanks!
Created attachment 96491 [details] [review] Patch for the gnome-2-20 branch.
Patches applied to the gnome-2-20 branch and SVN trunk. Removing Mike's name as Joanie has tested it.
Just to be sure -- this is still [blocked] due to the bugs logged in comment #9, correct?
Correct.
Rich, this just in: (https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/133795) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Ubuntu Add To Panel dialog was dropped[1] and we're now using the upstream version of it which emits the events, marking this as fixed, thanks for reporting. 1- https://launchpad.net/ubuntu/hardy/+source/gnome-panel/1:2.21.91-0ubuntu2 ** Changed in: gnome-panel (Ubuntu) Status: Confirmed => Fix Released ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Woo hoo! :-) I just confirmed that we are doing the right thing in Hardy. I think this bug can be unblocked and marked as FIXED.
Thanks Joanie.