[kde-linux] Anyway to have KDE hide mouse pointer when keyboard in use?
Boyd Stephen Smith Jr.
bss03 at volumehost.net
Fri Jul 27 05:34:34 UTC 2007
On Thursday 26 July 2007, david <gnome at hawaii.rr.com> wrote about 'Re:
[kde-linux] Anyway to have KDE hide mouse pointer when keyboard in use?':
> Boyd Stephen Smith Jr. wrote:
> > So, what's wrong with the mouse pointer being active even if
> > it is hidden?
> When the pointer is hidden, it should not be considered active - at
> least for clicks or highlighting items.
Yeah, I agree, but konsole actually un-hides the pointer as soon as focus
leaves the typing area, so by the time the menu is opened the mouse
pointer is visible (and therefore active).
I don't see any *huge* disadvantage to a hidden mouse pointer being active,
but it is counter-intuitive and should be avoided if possible.
> >>> insist on moving the highlight to
> >>> whatever item is under the mouse pointer (if there's even the
> >>> slightest movement of the mouse).
> > If your mouse moves when you don't want it to, you need a new mouse,
> > not better software.
> Sorry, I must correct my phrasing. The mouse (trackball, in my case)
> doesn't really move at all. Here's what happens:
> 1. Mouse pointer sitting at arbitrary location.
> 2. Keystroke combo brings down menu that happens to come down in the
> same area the pointer is.
> 3. System (application or window manager or whatever) sees that mouse
> pointer is now over the menu.
> 4. System highlights whatever item happens to be under the mouse
I see no problem, so far.
> 5. Problem 1: Some applications then proceed to ignore my
> efforts to move the highlight using keystrokes (it seems they give the
> mouse pointer priority).
I can't duplicate this, here. Moving around menus with a mouse pointer
over them is unimpeded.
> 6. Problem 2: If keystrokes aren't being ignored and I use one to open
> up a submenu - and in the process make the mouse jitter even the tiniest
> bit (for example, simply by typing on the keyboard beside my trackball)
> - the system thinks the mouse pointer moved and so it again highlights
> whatever item was originally under the pointer, making any submenu
> disappear completely.
If the mouse sends an event, the WM should respond to it. That said, you
should be able to make the WM ignore sufficiently small events by altering
the Peripherals -> Mouse -> Advanced -> Pointer threshold setting in the
Control Center. At least, I think that's what that setting does, mine is
set to 4px.
Perhaps that setting doesn't do what I think -- I appear to be able to move
my pointer a single pixel at a time when I try.
> Nothing wrong with the pointing hardware, but all trackballs and (to
> some extent) mice are sensitive enough to vibration to generate a tiny
> "pointer moved" event due to vibration from nearby physical activities.
Hrm, I must just have above-average mice then. Neither one of my Logitech
mice will generate any events due to my typing. Actually, I have to hit
my desk pretty freakin' hard to get it to move at all, while it still
glides quite effortlessly when I actually use it.
I'm still of the opinion that if your mouse generates events when you don't
want it to -- particularly if it generates events just because you are
typing -- that your pointing hardware is at fault and not the software.
It *should* be possible to ignore mouse events that occur within some
period of time after a keyboard event though, to correct for such a broken
setup. Something like 100ms should be enough... I wonder if any
developers would be interested in implementing this.
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03 at volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-linux