Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1057 - NumLock on messes up ability to change focus
Summary: NumLock on messes up ability to change focus
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 5.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-02-06 07:19 UTC by kevingal
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-03-22 21:35:33 UTC


Attachments (Terms of Use)

Description kevingal 1999-02-06 07:19:20 UTC
If NumLock is on, mouse clicks no longer change focus from
one window to another.  The window in which the mouse is
clicked pops to the top on the desktop but the window does
not receive focus.

Turn off NumLock and proper operation is restored, i.e.,
mouse clicks move the focus to the window in which the mouse
was clicked.

Comment 1 David Lawrence 1999-02-06 22:48:59 UTC
This is not actually a bug, more of a feature. This was created for
people who wanted to play Doom and Quake type games and not have the
color map keep changing on them if their pointer exited the window.
This only usually is set as default in fvwm. You could try another
window manager to alleviate the problem.

Comment 2 kevingal 1999-02-07 05:09:59 UTC
Some X applications support the use of the keypad keys.  These are
enabled when NumLock is on.  The keysyms generated when NumLock is on
are KP_1, KP_2, etc.  Choosing the PC NumLock key to turn on the
"feature" of disabling the setting of focus via a mouse click clearly
disrupts the proper function of the mouse on the desktop for those who
are using X applications which support the use of these keypad keys.
It would have been better if the choice of key where selectable via an
fvwm X resource attribute.  Indeed, setting this attribute to a key
(or not) could also double as a way to enable (or disable) the
feature.

In any case, leaving things as they are means fvwm has a useful
feature for players of doom and, at the same time, an annoying bug for
users of applications which support the keypad keys.

Comment 3 Jay Turner 1999-03-22 21:35:59 UTC
This is the documented behavior of X.  Also, this is not something
that Red Hat has control over, as it is a feature of X and not
something that Red Hat chose to implement.


Note You need to log in before you can comment on or make changes to this bug.