GNOME Bugzilla – Bug 363830
Provide feedback in OOo when toggling bold, underline, and italics
Last modified: 2008-07-22 19:33:31 UTC
In OOo, when using keyboard shortcuts to toggle bold, underlining, and italics, Orca provides no feedback. Would it be possible to check the formatting of the current (or currently selected) text and inform the user that the formatting in question has been turned on/off as a result of the keyboard shortcut? Thanks!!
Created attachment 75252 [details] debug.out with Ctrl+{B,I,U} showing we don't get any events OOo doesn't seem to give us enough information to do this. :-(
Thanks Will. We'll need to file a bug against OOo for this (with a simple non-Orca Python at-spi test script to help them reproduce it).
In light of the above: Rich, you're probably already doing this, but given the narrow nature of my RFE.... Can you also include the following commands which also don't seem to be giving us any info: Alignment-related: Control+{L, R, E, J} Heading-related: Control+{1, 2, 3} Revert to default style: Control+0 I suspect there are others. These are just off the top of my head and verified as eventless in debug.out. Thanks much!!
Will do. I'm juggling about 5 bugs at the moment. The same non-Orca Python script should handle your new test cases. I just need to make sure that the output transcript runs them. More in a couple days. I'm otherwise engaged tomorrow.
It seems like it would be best if we could just announce the state of these settings such as "bold on" or "bold off".
I had a quick look at this. I believe that each of those states: Bold Underlining Italics Alignment-related: Control+{L, R, E, J} Heading-related: Control+{1, 2, 3} has a StarOffice/OOo "widget" in the GUI that changes state when the user does the Control-<whatever>. Revert to default style: Control+0 presumably would potentially effect one or more of those widgets. (If it didn't change any, we probably don't need to announce anything). I would have expected us to have received some kind of accessibility event when those key sequences were entered. If we don't, then I don't think we can script for it. We'll need the OOo folks to make some changes. I'll investigate a bit more later this week.
I take it back. We could (sort of) script for this. We would have to override processKeyboardEvent() in default.py, then look for those key events (and there state). If we find them, then we need to check the state of it's matching widget in the swriter accessibility component hierarchy. I haven't checked how easy that would be to do.
Yikes! I'd rather make sure OOo issues the events we need.
I just had a look at swriter with at-poke. These widgets are toggle buttons that have states: (CHECKED) ENABLED FOCUSABLE SENSITIVE SHOWING VISIBLE You're right, we really should be getting events for these. I'll open an OOo bug and block this one.
OOo issue #70872 has been filed. http://www.openoffice.org/issues/show_bug.cgi?id=70872
Created attachment 81804 [details] [review] first pass at this issue Guess what. It turns out that we *do* get these events. At least in OOo Writer 2.1 and 2.2-dev. You just have to tickle/poke the hierarchy first. In light of this.... I took an initial stab at this issue. This patch will announce when the toggle buttons (which sometimes, but not always claim to be push buttons) have been toggled by us through the keyboard. Given that they can be toggled by a customizable keyboard shortcut as well as by navigation to text with/without those attributes, the logic is that we toggled it if we used a command and the command is not a navigational command. I have not yet addressed toggling them with the mouse for users with low vision. I'll look at that next. Mike: It speaks "on" and "off" as you suggested in comment #5. Here's the kicker though: We want to announce when bold, underlined, and italics have been toggled off. What do we want to do about alignment? If you change alignment, you have two toggled events: one for the new alignment and one for the old alignment because alignment is mutually exclusive. With the current patch, both events get spoken. Personally, I find that annoying. If my text is centered now, I really don't care that it used to be left-aligned. Do you agree? If so I'll look at that as well, but I wouldn't mind a hint if anyone has a clever way of programmatically distinguishing the "off" events we don't want to speak from those we do. This patch has been tested in Edgy (OOo Writer 2.1) and Feisty (2.1 and 2.2-dev). I no longer have a box with OOo 2.0.x.
Neat discovery! Thanks. The only issue with the proposed patch is when the call to getFlatReviewContext is being made. getFlatReviewContext is a very heavyweight call, so it probably shouldn't be done on every focus event. If you move it to the __init__ method of the script, will it still work (both in the situation where one Alt+Tabs to a running OOo and in the situation where one starts OOo after Orca is already running)?
I started with it in __init__, actually. Didn't work. :-( Then I moved it to onWindowActivated. No luck.... I was kinda hoping that the check if not self.flatReviewContext: would cause it to not get done *each* time there was a focus event, but rather only when the script loaded. Guess not, eh? :-(
BTW, is there any other lighter-weight way to "tickle the hierarchy"? This issue came up in Gaim, it came up with gnome-panel (prior to Bill's at-spi patch). If it keeps keepin' up, it would be cool if we could tickle/poke/slap the app without a performance hit.
Sorry to be spammy. The "focus event" statement should have jarred my memory since that was my next plan. (Desperate times and all that.) However, it's actually looking at object:state-changed:active events. Is that as bad as "every focus event"?? End of comments for now. :-)
(In reply to comment #13) > I started with it in __init__, actually. Didn't work. :-( Then I moved it to > onWindowActivated. No luck.... > > I was kinda hoping that the check > > if not self.flatReviewContext: > > would cause it to not get done *each* time there was a focus event, but rather > only when the script loaded. Guess not, eh? :-( > default.py:toggleFlatReview, which is called in several spots, clears self.flatReviewContext. These spots include locusOfFocusChanged and onCaretMoved. So, I'm not sure it's going to work. But...maybe all you want to do is just check to see if you've tickled the hierarchy or not. You might do something like this in __init__ (with gratuitous docs pointing to the Orca and OOo bugs in question): self.sillyOOoTickleHack = None and then: if not self.sillyOOoTickleHack: self.sillyOOoTickleHack = self.flatReviewContextClass(self) As for a general purpose tickle-me-elmo utility, I'm not sure. I think we'll continue to need to take it on a case by case basis, trying to limit our tickling to only those parts that need it.
Created attachment 81808 [details] [review] revision of the previous patch: less tickling :-) Thanks for the feedback and help Will! This version does as you suggest and only tickles once. Verified to work on all three of my Ubuntu boxes. I will look at handling mouse events tomorrow.
Looks good, Joanie. Thanks! Can you please add some comments to the code that refer to this bug (something like "see http://bugzilla.gnome.org/show_bug.cgi?id=363830 for more information on why this is being done")? It'll help jog our memory down the road when OOo eventually fixes the problem (i.e., we shouldn't need to tickle).
Created attachment 81826 [details] [review] latest version: includes handling of mouse clicking Okay, this version of the patch causes the toggled items to be spoken when you click on them with the mouse. That turned out to be easy. In addition, I more clearly (and in two places) documented the bugs so that we'll be reminded to check on that periodically. What I cannot figure out how to do -- and what I feel is the last piece missing for this to be done -- is avoid announcing when alignment gets toggled off while still announcing when styles (bold, underline, italics) do. When things get toggled off, we get a detail1 of 0; when they get toggled on, we get a detail1 of 1. When alignment gets toggled, we get one of each, with the toggled on event coming first. Initially I thought I could just keep track of toggle events per input event. When something is toggled on, note that. When something is toggled off for the same input event, see if we just toggled something on. If we did, don't speak it; otherwise, do. The problem with that, however, is that with the different styles (Heading 1, 2, 3; default) multiple things can get toggled on and off for a single input event. Hopefully I'm making some sense. And hopefully one of you has a brilliant idea -- or the obvious one that I'm overlooking. :-)
Update and wrap-up -- I hope. :-) I was chatting with Mike about not announcing when the alignment buttons get toggled off. He indicated that it was a good thing to hear what formatting just got turned off, even in the case of alignment. I've asked him to elaborate here after he tries the patch. Assuming he doesn't change his mind, I'm not going to look this gift horse in the mouth. :-) Based on our conversation, the patch in its current format seems to meet his specification. That's the good news. The bad news is that every once in a while, programmatic tickling doesn't get the job done. In addition, when you create new documents in an existing OOo session the tickling doesn't occur. :-( However, under each of these conditions, the user can work around this by giving a flat review command. Having done so once in the current window, the rest of the patch will kick in and start announcing events. So.... Do we want to do additional checks/tickling, or leave it as-is, documenting the work-around and reminding users of it until the OOo team fixes the bug? Finally, I pinged the OOo issue with a comment as nothing seems to have taken place on it in quite some time. :-(
The reason I think the current behavior is useful is that if a user is frequently changing alignment it is actually useful to know the previous alignment as confirmation of the document layout the user is creating.
I think this patch is a definite improvement over what we had. After talking with Rich this morning we think Joanie should commit the patch but leave the bug open until Will has time to comment.
Okey doke. :-) It's committed.
Looks good to me! Thanks!
You think this should remain open because there are still times when the patch won't solve the issue (e.g. creating a new document with Control N)? The work-around for the user (having to toggle flat review once in that window) is not completely obnoxious. Still, this issue won't be fixed-fixed until we get the events we need out ot OOo. Speaking of which, I just looked at http://www.openoffice.org/issues/show_bug.cgi?id=70872. Target milestone of 3.0. :-(
Where does this bug stand? We recently did an isolated tickler for another bug (I believe it was to prevent us from traversing each cell in a spreadsheet) - did it have an impact on this bug?
Not really Will. The bottom line is that the OOo guys need to give us these events(for which we have an open bug, milestone moved up to 2.3). Once we have these events, we should then remove the tickling. If we want a tracking bug on that, we could use this or close this one and open a new one.
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
(In reply to comment #25) > the events we need out ot OOo. Speaking of which, I just looked at > http://www.openoffice.org/issues/show_bug.cgi?id=70872. Target milestone of > 3.0. :-( > Woo hoo! Target milestone of 2.4 and marked as FIXED!! I'm not sure if that means it's in the publicly-available binaries yet, but I'll keep an eye out. Perhaps we can finally get rid of the "tickling" code (which was at best a crapshoot). Removing the blocked status.
Rich and I are trading bugs. :-) Rich, while it's hopefully clear from the comments here and in StarOffice.py, here's the executive summary: We are "tickling" the hierarchy in order to increase the odds of getting the correct events. It only works with the first document at best. If the original blocking issue is truly fixed, the tickling code can be removed and we will always announce when bold, underline, italics, and justification have been changed via keyboard shortcut or clicking the mouse on the buttons. Thanks for taking this!
I've just downloaded and installed the latest Linux RPM's compressed tarball from http://download.openoffice.org/680/index.html The directory it unpacked into (before I installed it) was SRC680_m241_native_packed-1_en-US.9254 I can confirm the problem in now fixed.
After chatting with Joanie, i'm reopening this one. The bug is not fixed. Or rather the fix isn't integrated into the version of OOo 2.4-dev that I just tested. I didn't realize that there was some "tickling" code in the StarOffice.py script that was forcing it to do the right thing. If I remove that, then the problem persists. I'll retry in a week or two when there is a newer OOo build available.
Created attachment 104578 [details] [review] Patch to remove the "tickle" code. Looks like this bug is finally showing up in a publically accessible OOo 2.4-dev build. I just downloaded OOo-Dev_OOH680_m6_LinuxIntel_install_en-US.tar.gz from http://download.openoffice.org/680/index.html and installed that and after applying the attached patch, I'm able to get feedback when I change bold, underline and italic text attributes.
Setting to "[testing required}. Please test.
Cool, it works!! :-)
Thanks Joanie. Patch committed. Moving to "[pending]".