[kde-linux] Anyway to have KDE hide mouse pointer when keyboard in use?

[Boyd Stephen Smith Jr.]

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
> pointer. 

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           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-linux/attachments/20070727/db0a86b0/attachment.sig>