GNOME Bugzilla – Bug 75391
gnome-calculator fails to add two numbers while using '+' from numpad
Last modified: 2004-12-22 21:47:04 UTC
This bug is reported for the beta-2 release version of GNOME-2.0 1) Click on a number (eg: 26) 2) Turn NUMLOCK key ON 3) Click on the '+' operator from the numpad in the keyboard 4) Input another number (eg: 4) You can observe on the display the number together as "264". "+" operator on the numpad doesn't works with gnome-calculator in this case and hence a bug.
Numlock is on by default in gnome-calculator, so when you hit the numlock key, it toggles it off. So I think this should be marked "NOTABUG".
Agreed with jfleck.
This behaviour is observed in Solaris 2.9 28th March build
Guys, this _is_ a bug. Basically it should respond to any keybindings that have to do with + and clearly the num-lock/+ combo on Solaris generates a key value that gcalc doesn't support.
Avirupa, Ashok: Can either of you or someone you know figure out which keybinding corresponds to the plus button when num-lock is on for Solaris? I can't really fix this because I don't have access to Solaris and it works fine on Linux
Bharat: who would be responsible for this type of bug within wipro? (specifically, gnome-utils bugs)
this bug has a fix which has been made into the gtk code which is still not checked in. I am not too conversant with the fix but i will ask the developer to submit the patch over here as well as give the analysis of the bug.
The problem is described as below: 1. In gdk_keymap_entries_for_keyval and update_keymaps() we are only looping for less than max_keycode. ie (keycode < max_keycode) rather than (keycode <= max_keycode). In the case of sun type-4 keyboard the keycode of KP_Add is the max_keycode value. 2. Secondly for some reason the following logic doesnt return the desired value for sun type-4 keyboards. SYM (group, shift_level) I guess its because the keysyms_per_keycode is 5 and not 4 which is the ideal case. However XKeycodeToKeysym or XKeysymToKeycode works just fine. Attaching a patch which fixes the problem.
Created attachment 7655 [details] [review] Proposed patch
The patch also fixes the problem reported in bug #78061
Adding appropriate keywords; would be nice (as usual) if wipro engineers did that themselves. :) Shivram: also, you must have meant some bug other than bug 78061, which is a nautilus bug. Do you know what bug you really meant?
Oops. Really sorry about the worng bug id. The bud id i meant is #75747. Will update the keyword appropriately in future. Sorry about that too.
Shivram: have you opened a bug for gtk+ and included this patch. I don't have commit privaledges for gtk+. Otherwise the gtk maintainers will not know about the patch
Created a bug for the same in gtk+ and included the patch. The bug id is bug #79184. Also bug #75746 is related to this bug.
*** Bug 75746 has been marked as a duplicate of this bug. ***
Okay, let's get this sorted for 2.0. We need to bug Owen if it is indeed a gtk issue.
*** Bug 79647 has been marked as a duplicate of this bug. ***
Agreed that bugging owen about this would be good, but that should take place in bug 79184 and not in this bug, so removing the 'urgent' priority here.
*** Bug 70697 has been marked as a duplicate of this bug. ***
*** Bug 80573 has been marked as a duplicate of this bug. ***
*** Bug 81341 has been marked as a duplicate of this bug. ***
Okay, closing - it's really a gtk+ bug. *** This bug has been marked as a duplicate of 79184 ***
Funny, it is stated that it works fine on Linux, well I have build Gnome2 yesterday for the first time, using the cvsgnome Script 0.2.0 whch checks out the latest sources (however I ave done a stable build to pull the *.tar.gz from the Gnome.org site) I still remark this behavior, using the Numblock with the Numlock Key on, then hitting 2 for example does nothing, whereby 8,9 and so on work. I mean that the 2 generally does not work, no matter if you hit + sign or not. Sources grabbed on 19 June, build on LFS 3.0, using gcc-2.95.3 and glibc-2.2.5 gtk+.2.0.5 Could someone please comment on this ?
Sorry, I better should have deleted all files related to gnome in my homedir, I rebuild again and now it works
Yes, again, as stated in some other Bug Reports GCalc does not work with NumLock ON. Well this still happens for me as well on Linux. It works only correct if you turn off Numlock. I think it should be made that GCalc 1. Either works correctly with NUMLOCK ON or OFF 2. Works with NUMLOCK ON, as other Programs require to have the NUMLOCK ON when you want to type something in, the normal user would not think to turn NUMLOCK OFF to get to work with GCalc.
The numlock bug is in gtk: 79184
John: I do not have a Sun keyboard, I have standard PC-105 Keyboard on x86 hardware using Linux and what I'm talking about is Comment 1 by you. I think that it is wrong to have Gcalc toggling the NumLock OFF when it is actually set to on. Or do you think, that this will be seemed logical for people ? I mean, now I know that the behavior is simply changed but I don't think that a new Gnome User will think "Hey, I use Gcalc so to use the NumPad I have to set the NumLock to OFF, and when I'm back in Gedit I have to set it NumLock back ON to get it working" So I would suggest to either let Gcalc accept both modes as they were NumLock ON or to use NumLock when it is *REALLY* set to on. In my eyes it doesn't make much sense to switch the NumLock behavior of Gcalc, also it is uncomfortable to always switch NumLock ON and OFF when working in Gnome wether you use Gcalc or another Gnome Program.
Carsten - You need to go look at bug #79184. This is a legitimate bug, people are working on it, that's where this and all the other duplicate reports have been assigned, and that's where all the discussion about fixing it is going on. No one is suggesting just leaving it this way.
Today I tested with the source taken on "July 10th " from CVS Head. I tested on Solaris 5.8 machine. Still I am able to reproduce this problem. Steps to reproduce: 1. Press Numlock. 2. Press 1. 3. Press + 4. Press 5 5. Press enter. Expected behaviour: It should total both the numbers. Current behaviour: It shows the number as 15.
I tested with the source on "15th July" on Solaris 5.9 and I could simulate the problem. Louie: Can we reopen the bug once again.
prabhut: does your version of gtk have the relevant gtk patches discussed in bug 79184?