GNOME Bugzilla – Bug 347630
Support non-ASCII characters
Last modified: 2009-06-16 05:28:20 UTC
Please describe the problem: the gcalctool keys are correctly labelled with U+2212 MINUS SIGN − and U+00D7 MULTIPLICATION SIGN ×, but when these keys are pressed ugly ascii - and * are displayed in the operation field Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
this is made that way because most programming language uses * as their multiplication sign. This is also a way of showing that you can also press * to do a multiplication.
I don't think the kind of people who use the tool care what programming language use as operator (nor should they). And a numeric keypad is pretty much self-explanatory. BTW Bsp is a disaster as it's not labeled this way on most non-english keyboards (even my old hp hardware calc uses left arrow for this), Clr shoud be clear or a pretty X icon (my calc uses DEL and CLEAR), and Abs should be |x| It's pretty bad when a software calculator with little or no limitations self-limits itself further than the real hardware things.
This is an enhancement request. Thanks for your comments Nicholas. They will helped me prioritise it accordingly.
You should probably compare the labels to the stuff on high-end scientific calculators, as these people spent a lot of time and money optimising them to justify the price of their products. For example: http://fr.wikipedia.org/wiki/Image:Voyage200.jpg http://fr.wikipedia.org/wiki/Image:HP48G.jpg http://fr.wikipedia.org/wiki/Image:TI-89Titanium.png http://www.casio-europe.com/fr/sc/products/detail/FC-200V/ ...
from http://www.unicode.org/reports/tr25/tr25-7.html#_Toc27 : "Minus sign. U+2212 [minus sign] is the preferred representation of the unary and binary minus sign rather than the ASCII-derived U+002D [hyphen-minus], because U+2212 is unambiguous and because it is rendered with a more desirable length, usually longer than a hyphen."
As we've deviated from the original subject quite a bit, I've moved the button label problems to bug #347700
gcalctool calls set_display() in gtk.c to update the calculator display. The variable v->display typically contains a char* equivalent of what is going to be displayed. This is what is most often passed into set_display(). This variable gets updated from numerous routines (mostly in functions.c). Probably the simplest way to get the desired results here is to adjust the set_display() routine (near the beginning) to call another (new) routine: Something like: ... str = localized; } } str = adjust_display(str); <---- New routine. buffer = gtk_text_view_get_buffer(GTK_TEXT_VIEW(X->display_item)); ... The " char *adjust_display(char *str)" routine would enumerate over the str it has been given, building up a new string, character by character. It would also be looking for certain characters, and replacing them with their Unicode equivalents. It would then return the converted string. It's either that or rewrite all the routines to fully understand Unicode. That's a lot of work.
Created attachment 97010 [details] [review] Patch to adjust the display but... Adjusting the display is only half the fix here. The routines that parse the display and form the expression are also going to need to be adjusted to recognize these new characters. Note that this change is only needed for arithmetic precedence mode, because left-to-right precedence doesn't show the arithmetic operators in the display. Transferring to Sami for further evaluation.
*** Bug 530532 has been marked as a duplicate of this bug. ***
Description from bug #530532: Gcalctool does not properly support unicode characters. The problems are: - GTK+ uses locale dependant strings so users can enter any unicode character (normally UTF-8) - The thousands separators and radix can be non-ASCII - The internal representation is ASCII (the code assumes string[3] will be the third character which is not correct if the input is UTF-8) - The flex parser is 8 bit only and freaks out when it sees UTF-8 characters. It doesn't appear the standard upstream version of flex can support 32bit strings. The proposal is: - Use an internal unicode (32 bit strings) representation - Convert GTK+ input to unicode - Convert equation to ASCII before sending to the parser. Obvious substitutions such as ×->*, ÷->/ need to be made before parsing. - Consider doing localization at the latest possible point, i.e. before sending to the GUI for display. The factors making this difficult currently: - Lots of code modified v->expression in various ways - Lots of code calls ui_set_display
Made a display object: http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2146 This showed that the exponential number entry had been broken in left-to-right mode so this patch disables the broken functionality. I think this is the last nail in the coffin of LTR mode (bug #500994)
Fixed finally! http://git.gnome.org/cgit/gcalctool/commit/?id=d6e47cb777deaf2bc2c755aba9fe78d40831e8a7 http://git.gnome.org/cgit/gcalctool/commit/?id=d76194956a3e99f289fc90afe988512e3ca06003 http://git.gnome.org/cgit/gcalctool/commit/?id=6b2e817389378153da88d62a8a868433e369f11f 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.