After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 369292 - gcalctool doesn't speak the new result when the "=" button is activated..
gcalctool doesn't speak the new result when the "=" button is activated..
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
0.2.x
Other All
: Normal normal
: ---
Assigned To: Rich Burridge
Orca Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-11-02 08:25 UTC by Tim Miao
Modified: 2006-11-03 21:18 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
Patch to fix the original problem. (733 bytes, patch)
2006-11-03 21:15 UTC, Rich Burridge
none Details | Review

Description Tim Miao 2006-11-02 08:25:11 UTC
Please describe the problem:
This is an a11y bug for calculator.

Steps to reproduce:
1. Invoke orca and calculator.
2. Click buttons to make a calculation.
3. Press Tab to the result.


Actual results:
The focus can not be put on the calculation result, this makes result is not accessible.

Expected results:
The result should be accessible.

Does this happen every time?
Yes.

Other information:
This bug can be found with gcalctool 5.8.24 and orca 2.17.1.
Comment 1 Rich Burridge 2006-11-02 20:20:56 UTC
The way that the Orca gcalctool script is designed is that when the display
area is updated, it's new value is spoken and brailled. 

The gcalctool display area is deliberately made read-only so that the user 
cannot randomly change the contents.

I do not consider this a bug and I'm closing as such.
Comment 2 Rich Burridge 2006-11-02 20:37:40 UTC
The other point I should make is that in arithmetic operator
precedence mode, the Return key is a toggle between the result
and what you user last typed in. If the user forgot what was
being displayed, then they can hit Return twice, and it will 
be re-spoken and re-brailled.

Comment 3 Tim Miao 2006-11-03 02:00:39 UTC
Yes, the result will be updated and displayed in brlmonitor, but it failed to be reported in speech while operating the num-pad. If tabbing to the number button, the number and operator can be heard when he is typing, but the result is not accessible. This seems to be a conflict I think. I could find this with both orca 1.0.0 and 2.17.1.
Comment 4 Rich Burridge 2006-11-03 04:51:10 UTC
That's a totally different bug Tim. Reopening and adjusting
the summary (and severity) accordingly.
Comment 5 Rich Burridge 2006-11-03 15:46:16 UTC
Transferring to the Orca team for further evaluation.
Comment 6 Rich Burridge 2006-11-03 21:15:13 UTC
Created attachment 75963 [details] [review]
Patch to fix the original problem.

Will politely mentioned that the problem was this:

If you tab (or arrow) around to the "=" button and then use the spacebar to
activate it, then you do not hear the result spoken. This isn't a numeric
keypad problem after all. The attached patch fixes that original problem.
Comment 7 Rich Burridge 2006-11-03 21:18:38 UTC
Patch checked into Orca CVS HEAD. Closing as FIXED.
Tim, if you were refering to a different problem, 
please file a new bug. Thanks.