On Saturday 02 June 2007 06:59, Joseph Loo wrote:
> I get a multiplication when doing it. I do not think it is tightvnc that is
> doing it because, if you open a standard xterm, it comes out as 8.
Yes, that is my result also... that is why I used xev... because it
will tell
me exactly which keysyms are being sent to KDE and being interpretted by
KCalc... this is the update I sent to the tightvnc people:
</begin>
I am using tightvnc 1.2.9 which shipped with openSUSE 10.0. I have
several headless application servers serving shared kde desktops across ssh
tunnels with the vncviewer also running as the client on openSUSE 10.0.
This setup is working great, and I want to thank the team who is making GPL
tightvnc possible.
I have a minor concern with the way the numeric keypad is handled, and I am
wondering whether this has already been addressed, or if I need to open a bug
report. I did some searching but did not find what I was looking for.
In version 1.2.9 the numeric keypad is not being handled properly when the
numlock is on. From my vncviewer client I am accessing my remote kde desktop
and running (from within a konsole) the xev tool. This displays the x events
(keypresses and keyreleases) plus the associated keysyms. With the numlock
off the keypad works as I would expect it to. The 7 key is keysym KP_Home,
the 8 key is KP_Up, etc. Each key receives ONE keypress event, and ONE
keyrelease event. However, when the numlock is on then the behavior is not
expected which causes different kinds of problems depending which app is
needing the keypad. With numlock on the 7 key recieves [ in this order ] :
keypress shift_L
keypress KP_7
keyrelease shift_L
keyrelease KP_Home
[ this is not correct behavior, even though it does work for
some things ]
The 8 key press with numlock on gives:
keypress shift_L
keypress KP_8
keyrelease shift_L
keyrelease KP_Up
[again, not correct and very strange behavior in some apps]
The shift meta keys should not be used at all--- although the technique would
work for the most part if the keyreleases were in the correct order. Here is
what happens in kcalc --- the 8 key activates the * key [multiplication
key] why?-- because the 8 is being interpretted as an "8" with the shift_L
key down... "*".
Using the shift_L technique vncviewer should be sending the keyrelease shift_L
*last*. However, even so, it will not work in KCalc because the 8 key will
still be interpretted as an * .
What should be happening is this:
keypress Num_Lock
keyrelease Num_lock
keypress KP_8
keyrelease KP_8
So, I would like to know is this a bug? If so, has it been fixed in 1.3.x (I
have downloaded the tarball but have not installed it as yet)? Is there a
work-around in the current version, or is there something I am missing here?
</end>
The tightvnc folks say to install the 1.3.9 version... which I *have*
downloaded, but which I have not installed as yet. They tell me that the old
version numlock state was the state of the Server PC instead of the Client
PC. When the client pushes numlock the numlock comes on at the client but
stays off at the server<?>. Yikes. I am playing with that now... but have
not confirmed that that is my problem. I still think its a bug in vncviewer.
Different apps give different results depending on whether the keyreleases
are valid symbols for the app!
I'll keep you posted. :-|
--
Kind regards,
M Harris <><
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
