GNOME Bugzilla – Bug 503874
Read by row in Evolution reads cell information incorrectly
Last modified: 2008-07-22 19:33:19 UTC
From the orca-list: "When Orca is set to read the whole row in tables, the message headers in the message list are not read correctly. Orca reads the column titles and reports every mail as unread and with an attachment, and also be marked. I remember that this used to work in older Orca/Evolution versions: Only unread mails where announced with status, an attachment was indicated when there's one, and a set mark, such as important etc., was announced only when set by the user. The only workaround is to set table reading to cell. But the status of the headers gets not read correctly too. Advantage: you can scroll the headers by cell."
This seems not to happen on all systems (see postings in Orca mailinglist). My system: Ubuntu Gutsy, Orca 2.20.2, Evolution 2.12-1; it also happened in the original Evolution shipped with Gutsy.
Created attachment 101201 [details] Orca debug output generated whilst testing this problem with Orca v2.21.4
Created attachment 101202 [details] Orca output generated whilst testing this problem against Orca v2.20.2
I can't reproduce this problem. This is on Ubuntu Gutsy with Evolution 2.12.1 I first tried it with the very latest Orca (2.21.4). Here I had to do an ORCA_MODIFIER-F11 (Insert-F11) to switch from the now default of speak-by-cell to speak-by-row. It had no problems telling if a mail message was unread (see Orca debug in the evolution-2-21-4.txt attachment). I then installed Orca 2.20.2. I had to start it with "orca -t" as the very latest Orca has introduced some new entries in my ~/.orca/user-settings.py file that cause problems with earlier versions of Orca. I also noticed that the default with this version of Orca and Evolution is speak-by-row, so I ended up toggling that twice to get it back to speak-by-row. Again, it had no problems telling if a mail message was unread (see Orca debug in the evolution-2-20-2.txt attachment). So I think I need others to test this and see what they get. Michael Whapples on the list doesn't see a problem, so I'm not sure why you are Hermann.
I tried this in Ubuntu Hardy (Evolution 2.21.4) with Orca 2.21.4 as well as Orca 2.20. I also tried it in OpenSolaris (SNV77) which has Evolution 2.12.1. In all of these environments, Orca only indicates that something is unread, has an attachment, or is flagged when those conditions are true.
Thank Joanie. Okay Hermann, could you possibly bundle up your ~/.orca directory as a tarball and attach it to this bug please? I'll try to use that to see if i can reproduce the problem here. Thanks.
Created attachment 101209 [details] The archive of my .orca directory.
Can the performance problem of Evolution be caused by my graphic card and/or the screen resolution? I use an Acer 1600 laptop with a Mobility Radeon 9000 graphic card. Are there known issues with this hardware?
I like a good mystery, so I just replaced my settings with Hermann's. I did have to remove the speech dispatcher stuff from user-settings.py because I don't have speech dispatcher. But that was the only change I made and Orca continued to only speak unread, attachment, and flagged information when I arrowed to a row where those things were true. As for the graphic card and/or the screen resolution.... I wouldn't think so. We're getting the information (or perhaps in your case, failing to get the right information) via AT-SPI. We're not "screen scraping" or inserting anything into a "display chain." <shrugs> For good measure, however, I dropped my screen resolution from 1280 x 800 to 640 x 480. Orca still continued to speak the right information.
My findings are the same as Joanie's. Your settings work for me (once I replaced the Speech Dispatcher settings with Cepstral settings -- I don't run Speech Dispatcher). I did notice that you have a ~/.orca/app-settings/Evolution.[py,pyc], and that in there is: orca.settings.readTableCellRow = False so this means that you will need to do an ORCA_MODIFIER-F11 to switch to speaking the whole row, otherwise, by default, it'll just speak the status column. Hermann, is it possible to retry without using Speech Dispatcher? I'm having trouble believing that's the problem, but it is a difference between your system and ours.
I tried it without SD, same result. Orca reads the header and displays the name of the header in the row instead displaying checkboxes as it should. Example: When i'm on the status cell, I hear "status" and read "status" on my braille display. The same with "attachment" and "marked". Sender, subject and date are displayed correctly. When I switch to "read whole row", I hear the column title, the content of the cell, and the braille display shows sender, subject and date.
The next thing that might help is to create an Orca debug output file, with debugging turned on full and attach this to the bug. In your ~/.orca/user-settings.py file, uncomment the following three lines: orca.debug.debugLevel = orca.debug.LEVEL_ALL ... orca.debug.eventDebugLevel = orca.debug.LEVEL_OFF ... orca.debug.debugFile = open('debug.out', 'w', 0) You might want to change "debug.out" to "/tmp/debug.out" in the last one, so you'll know exactly where the Orca debug file is located after rerunning the test. Startup Orca and Evolution again, and revisit the mail header list, set to read table-by-row (ORCA_MODIFIER-F11) and move up and down. Then quit Orca and look for the Orca debug file. Don't forget to reset (comment) these lines after running your test.
Sorry, but I can't create the debug.out. I uncommented the three lines, restarted Orca, and there was no debug file. I've done this procedure often enough to conclude that something must be wrong with Orca. I observed that, after restart, there was no new user-settings.pyc created; I think it should.
Created attachment 101261 [details] Hermann's .orca directory with debugging turned on. Hermann, I took the comparessed tarball or your .orca directory that you attached to the bug, adjusted the three lines in user-settings.py and bundled it back up again. Could you unpack this in your home directory and rerun the Evolution Test? Don't forget to reset those lines after you've finished testing.
I'm very sorry but this doesn't work too. No debug.out file on the system.
Hermann, the debug.out file should be in /tmp Does Orca speak/braille for you at all?
There's no debug.out on my system, believe it. Orca speaks/brailles correctly. A few weeks ago I created such a file without problems. So I don't know what's happened to Orca in the meantime.
(In reply to comment #17) > There's no debug.out on my system, believe it. Orca speaks/brailles correctly. > A few weeks ago I created such a file without problems. So I don't know what's > happened to Orca in the meantime. Given that this problem only seems to be happening on your system, I'm guessing there might be some special configuration we haven't run into yet. Would you be willing to open a port on your machine and let one of us log into it and do some experimentation?
I've reinstalled Orca, deleted ~/.orca and made a strange observation: My settngs were still there: I changed some keystrokes in order to have a better handling of the laptop keyboard layout. When deleting the .orca folder, they should be gone; in fact they were still present. I fear I have to open a port on my machine, so please tell me what to do. I use a router, AVM Fritzbox, if you know this type of router. It's possible to open a port for a special purpose and assing this port to a certain IP. So what to do further?
Hi Hermann: (In reply to comment #19) > I've reinstalled Orca, deleted ~/.orca and made a strange observation: > My settngs were still there: I changed some keystrokes in order to have > a better handling of the laptop keyboard layout. When deleting the > .orca folder, they should be gone; in fact they were still present. This is indeed very very very strange. The fact that the settings are still present makes me wonder if you might be running orca as a different user? If you type the 'id' command in a terminal window, does it give you the expected results? For example, does the uid match what you think it should be? Alternatively, is it possible you might have some *.py files laying around in the directory where you are running Orca? Orca will pick up a user-settings.py{c} and/or orca-customizations.py{c} from the directory where you started Orca. > I fear I have to open a port on my machine, so please tell me what to > do. I use a router, AVM Fritzbox, if you know this type of router. > It's possible to open a port for a special purpose and assing this port > to a certain IP. So what to do further? What you generally need to do is forward port 22 (for ssh) or port 23 (for telnet) to your real machine sitting behind the router. On my LinkSys box, this is under the "Port Range Forwarding" tab of the "Applications & Gaming" tab. It should be straightforward on your router, but can be tricky if you've never done it before. You might consider joining us on the #orca IRC channel at irc.gnome.org. We could try to walk through some steps together first to see if we can resolve the problem that way.
Created attachment 102307 [details] My Orca debug file. Finally I managed to create the file. For Will: There were indeed some *.py and *.pyc files in my home directory. Removing them completely caused Orca to create the debug.out.
Thanks Hermann! In looking at the debug output, it looks like we get an example of a "focus:" event resulting unread ("ungelesen") and attachment ("Anlage") being presented. One thing I notice in Evolution is that it wants to present the 'extra' stuff added by mailing lists as an attachment. For example, the following stuff from the orca-list is always marked as an attachment by Evolution: _______________________________________________ Orca-list mailing list Orca-list@gnome.org http://mail.gnome.org/mailman/listinfo/orca-list Visit http://live.gnome.org/Orca for more information on Orca So, maybe the 'attachment' stuff you're getting isn't wrong, but occurs because of how Evolution chooses to view the world. For the 'unread' part, a message will remain in the 'unread' state unless you stay on the message for a while (1.5 seconds -- which is customizable via the "General" tab of the "Mail Preferences" item in Evolution's preferences dialog). So, if you quickly scan the message list, the messages will remain in the unread state. We may also be attacking this problem from the wrong side. Perhaps it's not an orca setting that's causing this behavior, but perhaps a customization in Evolution that might be tickling a bug in orca. Did you customize your Evolution preferences in any way? In any case, I'd also like to make sure we are all clear on what the expected output and the actual output are. Can you expand more on your comments from comment #11? For example, describe a specific message your viewing, what you expect the output to be, and what it actually is. This may seem tedious, but I think it is important for us all to make sure we're talking about the same thing.
Every mail is shown as I described it: "unread" "attachment" and "marked" are always brailled/spoken, no matter how long the mail stays in my inbox. Personal mails that definitely have no attachment, were announced as mail with attachment. The status is always shown as "unread", no matter how often I open and read them. This doesn't even change, when I explicitly mark a mail as "read" from within the context menu. When I switch Orca to "read by cell", I hear "status" when I'm in that cell, and I read that word on my braille display not only in the header of the table, but also in the message line. There should be shown checkboxes on my braille display, and the speech should announce their status. And the same with the other two cells: The headers get doubled, instead of reading/brailling the content. Only the "sender" "subject" and "date" cell are shown correctly, no matter which mode I activated for displaying tables. I've changed some Evolution settings: I turned off the quoting, and I set the notify setting to "beep" when a new mail arrives (in fact it doesn't beep, but speaks a tool tip).
(In reply to comment #23) > Every mail is shown as I described it: > "unread" "attachment" and "marked" are always brailled/spoken, no matter > how long the mail stays in my inbox. Personal mails that definitely have > no attachment, were announced as mail with attachment. The status is > always shown as "unread", no matter how often I open and read them. This > doesn't even change, when I explicitly mark a mail as "read" from within the > context menu. I just tried Evolution 2.12.1 with Orca from SVN trunk and with Orca v2.20.3 (just released less than an hour ago) on my Solaris Express b79 box. Here's some more things I noticed with both Orca v2.20.3 and Orca from SVN trunk: 1) Braille doesn't update when the message status goes from unread to read as a result of arrowing to the message summary line and then not arrowing away. We could potentially fix this -- it might be nice to present the change both in braille and speech. 2) When reading by cell, I also noticed a spacing issue with braille and with also what seems to be rather verbose output: VISIBLE: '< > Status CheckBoxStatus Cell', cursor=1 ... SPEECH OUTPUT: 'Status column header' SPEECH OUTPUT: 'Status check box not checked Status' I'd guess we probably just want to present just the following if possible: VISIBLE: '< > Status CheckBox' SPEECH OUTPUT: 'Status check box not checked' Whatever we do, we should also be consistent for the attachment and flagged fields. Mike, what do you think the output should be? 3) The way we present information when reading by cell and when reading by row is different. When reading by cell, we do the above. When reading by row, however, we present the status, attachment, and flagged fields only if they differ from the norm, and we do not present the indicators in braille. For example, we'll just present 'unread' instead of the whole slurry of stuff for status. I suspect this is by design. Mike? 4) If I enable reading by row, I think I can now reproduce the problem you are seeing, but it takes extra steps: a) Enable read by row b) Arrow left or right on the message summary list until you are sure you are in the "From" column c) Arrow up or down to a message d) Arrow left twice At step 'd', I end up seeing something like the following in braille: unread Attachment < > FlaggedFlagged Hair Loss Solutions <PartnerAd@partner.beliefnet.com> Get Your Hair Back in 6 Weeks. Find Out How. 9:12 AM This message is read and also does not have an attachment. > When I switch Orca to "read by cell", I hear "status" when I'm in that > cell, and I read that word on my braille display not only in the header > of the table, but also in the message line. There should be shown > checkboxes on my braille display, and the speech should announce their > status. This is strange and I cannot reproduce it. :-( Rich, Joanie, Mike, are you able to reproduce the problems I'm seeing above?
> 2) When reading by cell, I also noticed a spacing issue with braille and > with also what seems to be rather verbose output: > > VISIBLE: '< > Status CheckBoxStatus Cell', cursor=1 > ... > SPEECH OUTPUT: 'Status column header' > SPEECH OUTPUT: 'Status check box not checked Status' > > I'd guess we probably just want to present just the following if possible: > > VISIBLE: '< > Status CheckBox' > SPEECH OUTPUT: 'Status check box not checked' > > Whatever we do, we should also be consistent for the attachment and > flagged fields. Mike, what do you think the output should be? > I like your proposed output. > 3) The way we present information when reading by cell and when reading by > row is different. When reading by cell, we do the above. When reading > by row, however, we present the status, attachment, and flagged fields > only if they differ from the norm, and we do not present the indicators > in braille. For example, we'll just present 'unread' instead of > the whole slurry of stuff for status. I suspect this is by design. You are correct. I intended this behavior so that the user still has enough context when set to read cell.
> > 3) The way we present information when reading by cell and when reading by > > row is different. When reading by cell, we do the above. When reading > > by row, however, we present the status, attachment, and flagged fields > > only if they differ from the norm, and we do not present the indicators > > in braille. For example, we'll just present 'unread' instead of > > the whole slurry of stuff for status. I suspect this is by design. > You are correct. I intended this behavior so that the user still has enough > context when set to read cell. Should braille also do the same difference in presentation? The reason I ask is that heavy braille users may also want to use the cursor routing keys to change the state of the fields (if they can). For example, when skimming the message summary list, the user might have read by row enabled and may want to quickly set the 'flagged' field as a means to remind them to get back to the message later.
I've opened bug #508153 for issues #1 and #2 reported by Will in comment #24. > 4) If I enable reading by row, I think I can now reproduce the problem you > are seeing, but it takes extra steps: > > a) Enable read by row > b) Arrow left or right on the message summary list until you are sure > you are in the "From" column > c) Arrow up or down to a message > d) Arrow left twice > > At step 'd', I end up seeing something like the following in braille: > > unread Attachment < > FlaggedFlagged Hair Loss Solutions > <PartnerAd@partner.beliefnet.com> Get Your Hair Back in 6 Weeks. Find Out How. > 9:12 AM > > This message is read and also does not have an attachment. I cannot reproduce this. This is with Evolution 2.12.1 on Ubuntu Gutsy.
I can actually reproduce it.
Joanie came up with a nice set of steps that describe what's going on here (thanks!): 1. Have at least one read and one unread message in your list of messages. 2. Enable reading by row. 3. Right arrow to the From column. 4. Left Arrow to the status column. Regardless of the status and presence/absence of an attachment, Orca speaks "unread" and "attachment" (presumably because those are the column headers and we just moved into those columns). For flagged we speak and braille a checkbox and its state. Perhaps we should be doing something similar for status and attachment when read by row is enabled but we've moved by cell into those columns? Mike, as you were the one that wanted "unread" and "attachment" spoken, are you okay with Joanie's suggested fix? Thanks.
Joanie's suggested fix is perfectly OK with me.
(In reply to comment #29) > Joanie came up with a nice set of steps that describe what's going > on here (thanks!): > > 1. Have at least one read and one unread message in your list of > messages. Ahh -- that must be the main difference between the set of steps I wrote in comment #24. > Regardless of the status and presence/absence of an attachment, Orca > speaks "unread" and "attachment" (presumably because those are the > column headers and we just moved into those columns). Note that we also need to fix braille. > are you okay with Joanie's suggested fix? Is there a patch somewhere? I'm guessing you three might have been doing some offline debugging with this?
(In reply to comment #31) > > are you okay with Joanie's suggested fix? > > Is there a patch somewhere? I'm guessing you three might have been doing some > offline debugging with this? Ahh -- I missed the indentation in comment #29. Sorry about that.
Will asked via IRC exactly what this fix was going to be, so here's the plan: If you have "enabled by row" set, then if you are moving horizontally in a message header list row, then the column headers for Status (which we replace with read/unread) and Attachment aren't brailled/spoken and just the "checkbox checked" or "checkbox unchecked" is spoken/brailled instead. If this isn't what is wanted, or if I've misunderstood, then let me know. PS: There isn't a patch yet. I just want to make sure we are all on the same page before I start this.
I just chatted with Joanie on the phone since I was very confused. I think the proposal is this: 1) Nail down the individual cell presentation behavior for speech and braille. This is tracked via bug 508153. Example for the status column: VISIBLE: '< > Status CheckBox' SPEECH OUTPUT: 'Status check box not checked' 2) If you move horizontally on a row, you read a cell using the individual cell presentation behavior regardless of the 'speak current row' setting. Example for the flagged column: VISIBLE: '< > Flagged CheckBox' SPEECH OUTPUT: 'Flagged check box not checked' 3) If you move vertically up and down, and the 'speak current row' setting IS NOT enabled, you use the individual cell presentation behavior. Example: VISIBLE: '< > Attachment CheckBox' SPEECH OUTPUT: 'Attachment check box not checked' 4) If you move vertically up and down, and the 'speak current row' setting IS enabled, you use the row presentation form with the abbreviated status/attachment/flagged fields: Normal unread mail: BRAILLE LINE: 'orca (bugzilla.gnome.org) <bugzilla-daemon@bugzilla.gnome.org> [Bug 503874] Read by row in Evolution reads cell information incorrectly 10:22 AM VISIBLE: 'orca (bugzilla.gnome.org) <bugzi', cursor=0 SPEECH OUTPUT: 'orca (bugzilla.gnome.org) <bugzilla-daemon@bugzilla.gnome.org>' SPEECH OUTPUT: '[Bug 503874] Read by row in Evolution reads cell information incorrectly' SPEECH OUTPUT: '10:22 AM' Mail with attachment: BRAILLE LINE: 'Attachment aerospace1028@hotmail.com updating ubuntu Yesterday 5:30 PM ' VISIBLE: 'Attachment aerospace1028@hotmail', cursor=0 SPEECH OUTPUT: 'Attachment' SPEECH OUTPUT: 'aerospace1028@hotmail.com' SPEECH OUTPUT: 'updating ubuntu' SPEECH OUTPUT: 'Yesterday 5:30 PM' Does this seem right?
> 1) Nail down the individual cell presentation behavior for speech and braille. > This is tracked via bug 508153. Example for the status column: > > VISIBLE: '< > Status CheckBox' > SPEECH OUTPUT: 'Status check box not checked' Ah, but this is the problem you see. Mike wanted a tweak to the Evolution script. For the Status checkbox, he wanted it to speak/braille "unread" if the checkbox was unchecked and NOT to speak if the checkbox was checked. I.e to reduce verbosity. Now presumably that's when you go by row. I think Joanie's summation to me via IM sums this problem up: "If you move horizontally, speak/braille the cell like we do when speak cell is enabled." In other words, no special unread/verbosity tweaking. That and the double brailling I believe are the main problems. The double brailling is really the other bug, but I'll try to address it here. Rather than generate countless revisions of tweaked patches for this in the bug, Joanie and I will work off-line to come up with something that will hopefully be close to what we finally want.
(In reply to comment #35) > Ah, but this is the problem you see. Mike wanted a tweak to the Evolution > script. For the Status checkbox, he wanted it to speak/braille "unread" if > the checkbox was unchecked and NOT to speak if the checkbox was checked. > I.e to reduce verbosity. > > Now presumably that's when you go by row. I'm on the phone with Mike right now. He says the 'reduced' behavior is for read-by-row presentation only, and only when you are reading the entire row. That is, if read-by-row is enabled, but you moved horizonatlly, the reduced form is not used. Furthermore, when using the reduced form, it is applied to both braille and speech.
Created attachment 102542 [details] [review] Revision #1 Thanks to Joanie for her help fixing and testing this. The patch makes the following three changes: 1/ In Evolution.py:locusOfFocusChanged() in the mail header list: if we are on the same row, then just speak/braille the table cell as if settings.readTableCellRow was False. 2/ In speechgenerator.py:_getSpeechForTableCell(): if there is displayed text associated with this table cell and if it's already in the utterances being constructed for this table cell, then don't add it in again. Note that this is a generic change and not just for Evolution mail header list table cells. 3/ In braillegenerator.py:_getBrailleRegionsForTableCell(): add a blank region after the braille regions associated with a checkbox within that table cell. Patch not committed yet. Please test.
Hey! This looks much better. Thanks, and it looks like you addressed part of bug 508153 as well (the spacing issue). I have the following comments which revolve mostly around the output of the reduced mode. It's mostly questions for Mike: My assumption about the reduced mode is that it will give output for braille and speech that only includes status/attachment/flagged output that is different from the 'norm'. When it does so, it prefixes the output with this information and does so in a reduced way -- just a word and no indicators (i.e., no '< >'). For each of {status, attachment, flagged}, the non-norm and reduced form are as follows: field non-norm-value reduced-form-for-non-norm-value ----- -------------- ------------------------------- status False unread attachment True attachment flagged True flagged Is this correct? If so, I'm seeing some indicators squeak there way into the braille output when I move up and down by line and read-entire-row is enabled. The one I'm seeing is the one for flagged. To reproduce this, enable the read-entire-row feature and then arrow left until you are sure you are on the flagged column. Then arrow up (or down) until you land on a message that is flagged. If you don't have one that is flagged, well, flag one. You will see the braille line begin with "<x> Flagged Flagged". For the reduced form, I'd expect just "Flagged" if the above is correct. In addition, I also have a question for Mike about where the VISIBLE stuff of the braille line should begin when presenting an entire row. Should it begin with the focused column or should it just always begin with the first thing that is non-norm? For example, assume the column with focus is the "Subject" column. If read-entire-row is enabled and I arrow up to a message summary with an attachment, should cell 0 of the braille display begin with the message subject or with "Attachment"?
> My assumption about the reduced mode is that it will give output for braille > and speech that only includes status/attachment/flagged output that is > different from the 'norm'. When it does so, it prefixes the output with this > information and does so in a reduced way -- just a word and no indicators > (i.e., no '< >'). For each of {status, attachment, flagged}, the non-norm and > reduced form are as follows: > > field non-norm-value reduced-form-for-non-norm-value > ----- -------------- ------------------------------- > status False unread > attachment True attachment > flagged True flagged > > Is this correct? If so, I'm seeing some indicators squeak there way into the > braille output when I move up and down by line and read-entire-row is enabled. > The one I'm seeing is the one for flagged. To reproduce this, enable the > read-entire-row feature and then arrow left until you are sure you are on the > flagged column. Then arrow up (or down) until you land on a message that is > flagged. If you don't have one that is flagged, well, flag one. You will see > the braille line begin with "<x> Flagged Flagged". For the reduced form, I'd > expect just "Flagged" if the above is correct. > Will's expectation here is correct. > In addition, I also have a question for Mike about where the VISIBLE stuff of > the braille line should begin when presenting an entire row. Should it begin > with the focused column or should it just always begin with the first thing > that is non-norm? For example, assume the column with focus is the "Subject" > column. If read-entire-row is enabled and I arrow up to a message summary with > an attachment, should cell 0 of the braille display begin with the message > subject or with "Attachment"? > The braille display should start with the cell that actually has focus.
Question for Mike here: >> In addition, I also have a question for Mike about where the VISIBLE stuff of >> the braille line should begin when presenting an entire row. Should it begin >> with the focused column or should it just always begin with the first thing >> that is non-norm? For example, assume the column with focus is the "Subject" >> column. If read-entire-row is enabled and I arrow up to a message summary with >> an attachment, should cell 0 of the braille display begin with the message >> subject or with "Attachment"? > >The braille display should start with the cell that actually has focus. Suppose the column that has Focus is the Status column, and you arrow up to a row where that message has already been read, and you have braille verbosity set to BRIEF. What region should get focus on the braille line then? Don't forget that we won't have put "read" there because we only ever put "unread" to reduce verbosity, so if I understand this correctly, there won't be a matching region to set visible.
I didn't think about that case. Perhaps in that case we should present from the beginning of the row.
Created attachment 102643 [details] [review] revision 2 When Scott found that preferences dialog bug I panicked and told Rich I'd trade him that issue for something he was working on. (Thank you Rich!) Guess which bug I got? :-) I believe the attached causes the desired information to be spoken and brailled and the braille display to be set to the correct focused region. It's pylinted as well. Please test. Thanks!
For all the discussion below, assuming read-entire-row is enabled and the user has just moved up/down a row. (In reply to comment #42) > Created an attachment (id=102643) [edit] > I believe the attached causes the desired information to be spoken and brailled > and the braille display to be set to the correct focused region. It's pylinted > as well. Please test. Thanks! The patch looks good and starts from the focused region, and stuff in the norm doesn't consume any extra space. For example, assume we moved to a message and the order of the columns is: status, attachment, flagged, from, subject, date. If the focused column is the first column, but the message isn't read, doesn't have an attachment, and is not flagged, the visible braille information starts with the "From" column. (In reply to comment #41) > I didn't think about that case. Perhaps in that case we should present from > the beginning of the row. Mike - I think we need clarification on what you want done here. Given the same order of columns above, assume the focused column is the "From" column. If the user arrows up/down to a message with an attachment, the visible information on the braille display will still start with the "From" column rather than being prefixed with "Attachment". Is this the desired behavior? If so, I say go ahead and commit after Mike tests this patch more. If not, then we need Mike to describe the desired behavior more. For example, is the desired behavior to always start from the beginning of the row when presenting the reduced form? That way, things out of the norm are always readily apparent on the braille display?
The problem also occurs here on Gentoo (Evolution 2.12.1 and recent SVN check-outs of Orca and at-spi), as well as in Debian Sid (recent Orca 2.20 Branch.) However, I found out that the problem doesn't occur if I set LC_ALL to en_US (normally it's set to de_DE.UTF-8 for me.) Even if i set LC_ALL to en_US and LANG to de_DE.UTF-8 Orca reads the message index as it should. only occurs if LC_ALL is set to de_DE
In reply to Henning: This seems interesting, since I also use de_DE.UTF-8, but with Orca 2.20.3 under Gutsy. Question: Do other non-English reading/writing users face teh same difficaulties? The question is, why does this happen? I remember that in Feisty there was everything OK with the message list in Evolution.
Another strange observation: After changing the folder in Evolution, the message index gets read wrong again. :-(
Joanie asked me a bunch of questions about this bug in chat on Friday. I'm putting her name back on this one to see what info is stil needed from me on this one.
Personally, I thought we were good. Then Will asked a number of questions of you. See comment 43. In the meantime, I'll provide my answers for what they're worth. <smile> > Mike - I think we need clarification on what you want done here. Given the > same order of columns above, assume the focused column is the "From" column. > If the user arrows up/down to a message with an attachment, the visible > information on the braille display will still start with the "From" column > rather than being prefixed with "Attachment". Is this the desired behavior? I would say this is the desired behavior. After all, if the user wanted to scan for items that had attachments, wouldn't he/she move to the attachment column rather than stay in the From column? > If not, then we need Mike to describe the desired behavior more. For example, > is the desired behavior to always start from the beginning of the row when > presenting the reduced form? That way, things out of the norm are always > readily apparent on the braille display? Even in reduced from, those labels (unread, attachment, flagged) take up a lot of real estate in braille. If the thing I care about primarily is whom a message is from, I don't think I will want those "non norm" values potentially requiring me to have to scroll the display. But those are just my thoughts. Putting Mike's name back in place of mine. <smile>
I 100% agree with Joanie's previous comment.
Uh oh... Then what I meant to say was.... <grin> Mike have you tested this? Will said to check it in if we had the desired behavior and after you had tested it some more.
I think we can call this one good.
Patch committed. Moving to [pending].
No need to reopen. It's not closed yet. The gtk-demo regression tests for table cells fail because of the braillegenerator.py changes in the last patch.
Created attachment 103149 [details] [review] Remove braillegenerator.py change (which sometimes caused bogus extra spaces). * src/orca/braillegenerator.py: test/keystrokes/gtk-demo/role_table.py: Fixup for bug #503874 - Read by row in Evolution reads cell information incorrectly. With the fix for bug #508153, we no longer need to put an extra space after the table cell regions for a table cell that has a toggle action (i.e. checkbox). Regression test updated to remove the bogus spaces.
(In reply to comment #54) > Created an attachment (id=103149) [edit] > Remove braillegenerator.py change (which sometimes caused bogus extra spaces). > > * src/orca/braillegenerator.py: > test/keystrokes/gtk-demo/role_table.py: > Fixup for bug #503874 - Read by row in Evolution reads cell > information incorrectly. With the fix for bug #508153, we no > longer need to put an extra space after the table cell regions > for a table cell that has a toggle action (i.e. checkbox). > Regression test updated to remove the bogus spaces. > Thanks! Works for me. Marking as [verified]. :-) Looks like this and bug 508153 were very tightly coupled.
Thanks. Closing as FIXED.