GNOME Bugzilla – Bug 350674
make orca announce when a new folder is opened and announce number of items
Last modified: 2007-03-27 15:42:15 UTC
When pressing enter on a folder and it opens, have orca announce when the folder is opened and number of items in the folder. normally no speech is presented when opening a folder until the user arrows through the folder and suddenly finds things have changed. It also is confusing to have no speech anounce when a folder is open and there is 0 items, which is why it is recommened to anounce the number of items in the folder automaticaly when the window is refreshed or a new window is opened. Other information:
Cody are you describing what you'd like with Evolution or Nautilus? In other words, email or file handling? Either way it's an enhancement request. Adjusting accordingly. Thanks.
See also http://bugzilla.gnome.org/show_bug.cgi?id=319666 - it may be related.
Cody still need to know whether you are describing what you'd like with Evolution or Nautilus? In other words, email or file handling?
Add accessibility keyword. Apologies for spam.
In a discussion amongst us chickens today, we've determined this is most likely the Nautilus application.
Created attachment 82560 [details] [review] Patch to hopefully implement this feature. nautilus.py should be a new file. I do not see how you can do an "svn diff" command for a new file. I'll attach that file separately after this attachment.
Created attachment 82561 [details] The new nautilus.py script.
Mike/Joanie, could you try it and see if does what Cody requested please? Thanks.
Created attachment 82562 [details] full debug.out illustrating a minor issue Totally slick Rich! I really like this new feature! And, yes, it does seem to be what Cody was asking for. I did notice something however: Taking Orca out of the picture momentarily, sometimes when you press Enter on a folder, the icon list takes its time appearing. Putting Orca back in the picture, when this takes place Orca indicates that there are 0 items. Compare line 5533 of the attached with 10186.
Hey Rich, it looks good with one minor change: You can lose the "viewing folder" and such as the user will know where they are by the context of the new item with focus when it is spoken/brailled. I tested this on an edgy system. I'll test feisty after you check in the patch. thanks much
Mike: When you say "and such" do you also mean the folder name? If so, I'm wondering if there should be a special case when backtracking using Backspace. I agree that if you press Enter on a folder, you should know that you are now viewing the contents of that folder. But when you press Backspace, you know that you're in the parent of whatever folder you were in, but you might not remember the name of the parent.
No, I think I wasn't clear on this one. I still want to hear the folder name just not the extra "viewing folder" verbosity.
Joanie, I'll look into the "0 items" problem. Thanks for testing it. Mike, if Orca doesn't say "Viewing folder", how do you know it's a new folder? Would "Opening folder" be better? Removing it completely I think will confuse users. Perhaps we should throw this open to the community for their comments...
The other thing is I'm not going to check this in until 2.19/2.20. Any chance you can test the patch on Feisty before then Mike? Thanks.
> Mike, if Orca doesn't say "Viewing folder", how do you know it's a > new folder? Would "Opening folder" be better? Removing it completely > I think will confuse users. It won't because when you speak the name of the new folder as well as the number of items and the size which is the default when read by row is enabled it will be obvious that a new folder has focus. > Perhaps we should throw this open to the community for their comments... no need for this one.
(In reply to comment #14) > The other thing is I'm not going to check this in until 2.19/2.20. I'd like to push back here. This is really nice functionality and improves the use of nautilus. If we have no string changes and it is a new script what is the risk of checking this in for 2.18? > Any chance you can test the patch on Feisty before then Mike? > Thanks. sure I'll do it shortly
If I remove "Viewing folder", we have one new string ("items").
(In reply to comment #17) > If I remove "Viewing folder", we have one new string ("items"). > Keep in mind that we should also strive to eliminate assumptions about the concatenation of short strings to make a short phrase. Thus, the form in nautilus.py probably should be _("%d items") and _("Viewing folder %s"). In this particular case, though, I'd guess we're safe with what you have already done. But, my knowledge of the 40+ languages for Orca is limited to about 2 main groups: English and French. In addition, early on in the development of Orca, I made this visualAppearanceChanged method that was supposed to be one of the two ultimate sources of speech, braille, and magnification (locusOfFocusChanged is the other). When I was in Spain, it became apparent to me that we really are not doing this, for a variety of reasonable reasons. As a meta-comment to this bug, I think we should revisit the decision as to whether or not we should try to move back to the visualAppearanceChanged model or just abandon it. Finally, Mike and I also reached a compromise on the "Orca navigation" versus "Firefox native navigation" issue. We're planning on keeping Firefox native navigation enabled by default, but using Insert+F12 to allow you to toggle between the two for GNOME 2.18. It will also be a very useful debug feature for me. The impact of this will be some additional string changes, so I'm going to need to request these. This does look like a pretty low risk change. So, if we all think the functionality provided by the new nautilus script is a great benefit for GNOME 2.18, I can roll all the string change requests into one. Please let me know your thoughts.
My vote is to include the new nautilus script in 2.18. It really does make a big difference in usability.
Created attachment 82577 [details] New version of the nautilus script. The new version of the script makes the following changes: 1/ Removes "View folder". 2/ Uses " %d items" instead of concatenating strings. Thanks for doing the string request for the one new string (" %d items") Will. I've still got to investigate the problem that Joanie found, but that shouldn't require a string change. I'll just post a new version of nautilus.py if/when I work out what's going wrong. I plan to do that tomorrow.
Rich, I just discovered something.... If the user goes to the View menu and unchecks the Location Bar, we no longer have our toggle buttons whose state nautilus.py examines. I'm not sure if that means we just need to inform the users (a la "You have to maximize your Synaptic window") or if there should be some sort of back-up plan in the script....
To follow-up, looking at at-poke, we still get events for those toggle buttons whether they are showing or not. But their absence is causing Orca to not speak the newly-opened folder and its item count. I'll dig further....
More follow-up: 1. When the Location Bar is hidden util.isDesiredFocusedItem(panel, rolesList) returns False. I even tried changing the call to util.findByRole so that onlyShowing = False. No luck. 2. I was able to get the name and item count even when the Location Bar is hidden by moving things out of onNamedChange and into: - onStateChanged (because we get checked events if the toggle button is already in the panel) - onChildrenChanged (because we get an add event if the toggle button is not already in the panel) UNFORTUNATELY, these events are YATMEB (TME = tickle me elmo): We don't get them until we tickle the hierarchy. Based on my experience with doing this for speaking changes to OOo's attributes, such an approach would at best be a crap shoot. :-( At least you can count on the accessible-name change so long as the Location Bar is visible (which it is by default).... Rich, if you already worked out the above, never mind. ;-) At least it was educational for me. :-) :-)
The announcing of the "<folder name> n items" should not be dependent upon whether the Location bar is visible. I'm just using that to stop it speaking/brailling two identical messages because we get two apparently identical accessible name changed events. I could cons up another version of this script such that, if the Location bar isn't present, you'll get the folder change message anyhow (i.e. twice). Joanie/Mike, is that the preference over getting it zero times? I'm guessing it is. P.S. I'll have a look at the "0 items" debug log after I've caught up with the rest of my mail. I've been thinking about it since yesterday. I haven't looked too hard yet, but I suspect there is not too much I can do with just using the accessibility events on their own. One thing that might be possible is to work out the full path name from the toggle buttons in the Location bar (if present) -- all the toggle buttons up to the armed/checked one -- then use standard Python calls to open that directory and see how many entries are in it. Of course this starts to get more complicated as we would also have to interrogate the View->Show Hidden Files menu item to see if the user had hidden files showing, and adjust the total accordingly. I wonder whether it's worth going to all this trouble. Comments?
Hey Rich. > I could cons up another version of this script such that, if the > Location bar isn't present, you'll get the folder change message > anyhow (i.e. twice). While it's kinda hacky, could you store the last folder change message spoken and do a check to see if what we're about to speak is what we just said and, if so, not speak it? Twice is better than not at all, but once is even better. ;-) I wonder if this might solve the 0 items thing in part. Total speculation based on no evidence whatsoever: Is it possible that a delay in displaying the icons causes there to be 0 items at the first event and the real number of items at the second event? If so, and you went the stored string route, we'd hear "blah 0 items, blah 12 items" but at least we'd get the 12. Again, assuming what I'm suggesting is actually going on....
Yes, I could store the last folder name each time, and if the Location bar wasn't showing, I could just do a compare on that. It doesn't help with navigating /path/to/same/same/same/same but it does improve the situation for most normal use. Okay, I'll factor that into the next version. Without looking at the logs, I'm guessing we are getting the accessible name change events before the items have been added to the parent in the folder panel. I'll test out your theory as well. Why do we get two of these accessible name events? Seems like a bug in gail/atk/at-spi to me. Of course if there was decent documentation <grumble>. More later.
> bar wasn't showing, I could just do a compare on that. It doesn't help > with navigating /path/to/same/same/same/same but it does improve the oops. Didn't think about same/same/same.... Good point. Then could you also check the index of the checked toggle button? The first same would be x, the second same x+1, and so on.... > Why do we get two of these accessible name events? For the benefit of AT with ADHD??? <grin>
> Then could you also check the index of the checked toggle button? What checked toggled button? ;-) I thought we were looking for a solution when the Location bar isn't present. I've got a perfectly good solution for when it is there already.
> What checked toggled button? ;-) I thought we were looking for a solution > when the Location bar isn't present. I've got a perfectly good solution > for when it is there already. Stop making sense. ;-) BUT.... When the Location bar isn't present, the toggle buttons still are I think and their state is changing. They just aren't generating accessible events to that effect until they get poked/tickled/slapped/kicked in the shins. Is there a non-violent way to get at them since util.isDesiredFocusedItem(panel, rolesList) fails when the Location bar isn't present? I suppose I should stop asking questions and start trying to figure this out myself.... :-)
Okay, I think I understand what you are saying now. Thanks for the clarification. I'll at-poke around and try Orca Insert-F8 (without the Location bar) and see if I can come up with something. (We are spending a lot of time on this edge case. I predict that most blind users will: a/ have the Location bar on. It's initially there by default. b/ Won't have directory hierarchies of the form /path/to/same/same/same/same I think I'll quickly generate a new script to integrate the other suggested changes, then look at your debug log, then come back to this problem.)
Created attachment 82616 [details] New version of the nautilus script. New version of the nautilus script attached. This does a reasonable job of trying to handle folder changes if the Location bar isn't showing. Doesn't handle /path/to/same/same/same. I'll now look at the "0 items" debug log.
> (We are spending a lot of time on this edge case. I predict that > most blind users will: > a/ have the Location bar on. It's initially there by default. > b/ Won't have directory hierarchies of the form /path/to/same/same/same/same > I think I'll quickly generate a new script to integrate the > other suggested changes, then look at your debug log, then > come back to this problem.) I have to agree with Rich here. The real problem here has been solved and after the zero items problem gets looked at I think it is safe to move on.
> I have to agree with Rich here. The real problem here has been solved and > after the zero items problem gets looked at I think it is safe to move on. I think the default "out of the box" behavior seems to be working well with the patch, and the edge case we're running into requires the presence of a two special conditions: 1) The user turns off the location bar. 2) There are folders of the form identical_name/identical_name/identical_name/... This is kind of a unique situation, and requires the user to do work to hang themselves. It is definitely an issue, but I'm OK with letting this one slide. For the 0 items bug, it seems as though this is something we see visually on the screen: the folder first opens with 0 items while nautilus goes out to populate the folder with a gazillion items. Then, when the items appear, the new number is announced. So...I think I might be comfortable with the behavior in the script. If any improvement were needed (and I don't think it's needed for GNOME 2.18), it might be to try to detect that nautilus is busy populating the directory and speak something such as "Please wait. Reading directory contents." I'm not sure how this might be detected, but perhaps it's something that should exist in a separate RFE?
Given the comments, I'm thinking I should just keep my mouth shut. <smile> But I do have a silly question having looked at the new patch: Isn't if self.oldFolderName != newFolderName: shouldAnnounce = True the case whether the location bar is visible or not? If so, would it make sense to do that check first in order to potentially eliminate unnecessary calls to util.findByRole() and util.isDesiredFocusedItem() and the subsequent traversal of the children of panel looking for a checked toggle button?
> If so, would it make sense to do that check first in order to potentially > eliminate unnecessary calls to util.findByRole() and > util.isDesiredFocusedItem() and the subsequent traversal of the children > of panel looking for a checked toggle button? Good point. Okay, I'll rework the script and give you something to try. New version in a few moments. Thanks!
Created attachment 82622 [details] Another new version of the nautilus script. Coded reordered. Mike/Joanie, could you give this new version a workout please. If it's (mostly) working, I'll check it (and the Makefile.am diff) in after lunch. Thanks.
with the latest patch I hear the new folder information twice without fail. I am using the list view for presentation.
Yup, because for the second name-changed event if self.oldFolderName != newFolderName is False and if not util.isSameObject(child, self.pathChild) is True.
As I understand it, the reason we are doing the whole panel check business is to handle cases of path/to/same/same/same (right?) If so, I'm afraid I've got some bad news for you: At least on my laptop, I am not getting any name-changed events where the event.source is a frame in the /same/same/same case. As a result, using any of the versions of the script posted, Orca does not announce anything when I go from same to same.
Created attachment 82630 [details] Reinstating previous version of the script. I've put back the previous version of the script. Can we agree that this is "good enough" even though it: 1/ is not the most efficient. 2/ it doesn't handle (or sound like it can possibly handle from Joanie's latest comment) the /path/to/same/same/same case. This version keeps the code fairly clean and I think the inefficiency isn't that bad. It doesn't seem slow on my machine. Thoughts?
I'm thinking it's feeling like a dead horse and that I should have let it be a long time ago. :-) I agree that it is "good enough" and still a great addition for 2.18.
I've now committed that previous version. Closing as FIXED. I think we have something that works well for most cases. Will, note that I've committed that string change. If "the committee" don't like it when you ask them for it to be included, I'll revert it to a plain "..." string for GNOME 2.18.
Reopening, as we pulling the fix for this at the last moment before the final Orca for GNOME 2.18. And I want to do a slightly different version of nautilus.py. More in a moment...
Created attachment 84185 [details] New version of nautilus.py Changed: itemCountString = _(" %d items") % itemCount to: itemCountString = " " + _("%d items") % itemCount for easier/more understandable i18n.
Changes checked into SVN trunk/HEAD. Summary prepended with "[pending]". Could others test this out before I close it as FIXED. Thanks.
One of the things we got hammered on during the string break request was that we didn't pay attention to the plurality of the items. So, the i18n aspect should look something like the following. The dual use of itemCount is at first confusing, but it is actually correct: ngettext returns a string of the form "%d item" or "%d items". So, we then need to tell python what value to use for %d, which is what the 'extra' % itemCount is for. itemCountString = ngettext("%d item", "%d items", itemCount) % itemCount ngettext comes from "import orca.orca_i18n.ngettext as ngettext" (or something very close to that).
Created attachment 84189 [details] [review] Patch to use ngettext. Thanks Will. I've adjusted (and committed) a variant of your suggested change. Please let me know if I've still got to adjust it. For the record, calling this routine ngettext is very confusing. Going just on the name, I took that to mean "don't convert this string using gettext". In other words, "no gettext". Oh well. Live and learn.
Looks good to me! Thanks! > For the record, calling this routine ngettext is very confusing. > Going just on the name, I took that to mean "don't convert this > string using gettext". In other words, "no gettext". Oh well. > Live and learn. Yeah. Unfortunately, the name choice wasn't ours and we just live with it. I think we'll also learn a lot more when we go through the detailed i18n/l10n exercise.
Closing as FIXED. If any new problems, are found please reopen.