GNOME Bugzilla – Bug 140836
text field (for numerals) hard to delineate in a11y themes
Last modified: 2009-06-24 04:00:22 UTC
Running GNOME built using gcalctool-4.3.50-9 source tarball: -Change the theme to High Contrast Large Print Inverse -Open the gnome calculator Observe that the the area limits of the text field (for the numerals) cannot really be seen, and this makes direct entry of numerals into the field difficult for vision-impaired users.
Created attachment 26963 [details] calc using High Contrast Inverse theme - text field hard to locate
Created attachment 26964 [details] calc using High Contrast theme - text field hard to locate
This is a regression in gcalctool, since version 4.3.38 does not have this problem, but 4.3.50 does. Rich, it looks as though you either removed a frame or changed its widget type... can you have a look? thanks.
I've just tried this with gcalctool v4.3.51 and GNOME 2.6 (cinnibar-lite on Solaris x86). I did not see a "High Contrast Large Print Inverse" theme there, but I tried it with "High Contrast Inverse" and "Large Print" and had no problems seeing the display text field.
Rich: did the display text field have a contrasting border around it? In our tests (calum and myself), there was a contrasting border in 4.3.38 but not in 4.3.50. If your gcalctool looks like that in Patrick's attachments (ignoring the text itself, but concentrating on the delineation of the text field's borders), then we have a problem.
Ah, I think I understand what you are talking about now. Then it looks like the change to "fix": http://bugzilla.gnome.org/show_bug.cgi?id=132570 is the culprit here. Add Calum to the CC: list here as this appears to be a HIGy thing.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Hi. I'm trying to fix/close gcalctool bugs. Bill, Calum how would you like this one fixed?
In gcalctool 5.6.31, it doesn't seem possible to have a void text (numeral) entry so it's more easy to locate the field.
Created attachment 56196 [details] The bug is fixed gcalctool 5.6.31 on Ubuntu Breezy 5.10 and a11y theme.
The behavioral change mentioned in comment #9 has reduced the problem. The underlying issue with frameless layout is still there however.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
reopening as this is still there according to bill in comment 11.
What do we want to change in gcalctool to fix this? Calum can use suggest a change please? We either fix this or close it as WONTFIX. It's been open for almost three years now. Thanks.
Hmm, well, I've just noticed something interesting. If I use the sample ~/.gcalctoolrc file (from the svn module), I get a nice solid border around the numeric display area with the high contrast inverse themes (but still not the regular high contrast themes). If I remove the ~/.gcalctoolrc file, I get no border. So maybe one possible fix here is to work out what in the .rc file is making the border appear with the inverse themes, and make it happen for all the a11y themes all the time...? (Aside to Rich: has also just become apparent that the reason my .gcalctoolrc file was apparently doing nothing up to now is down to Sun's Nimbus and Blueprint themes/engines-- they pretty much over-ride the .rc file completely. With other themes/engines, the buttons do take on at least *some* colour. You might want to file Nimbus/Blueprint bugs about that, although I doubt it'll be a high priority fix...)
I see the solid border in the two high contrast inverse themes, like you said, but not in the "High Contrast, Large Print" theme. Shouldn't it be there too? The way the radio buttons are rendered suggest that it should. I'll investigate what's going on here, but I'll need a pointer first please? Where are the themes stored? Thanks!
Yes, I expect we'd want a border in all variants of the high contrast themes. First thing to check would probably be /usr/share/themes/<themename>/gtk-2.0/gtkrc-- it's possible there's an unintentional difference between the gtkrc files for the themes where the border appears, and the ones where it doesn't. On the other hand, it's possible there's a glitch in the HC gtk theme engine (/usr/lib/gtk-2.0/<gtk-version>/engines/libhcengine.so), in which case somebody more knowledgable than me will have to assist :/ (The source code for that is in the gtk-engines module.)
Now that we've got a "gcalctool-maint@gnome.bugs" alias, I'm reassigning several bugs and enhancement back to that. They are free to be picked up by one of the team and worked on. Now that gcalctool has been Glade'd, I'm hoping that this problem will be easier to find and fix.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. http://git.gnome.org/cgit/gcalctool/commit/?id=0bc717a6a62350fa775e0cf2a432e64dd335cc4c