KNotificationAreaItem

[Thomas Lübking]

Am Friday 24 April 2009 schrieb Aurélien Gâteau:

> First I believe most non-techy users do not use multiple monitors.
(this is unerlate to the rest, and) just for the records:
from my personal experience multimonitor setups are mostly used by artists, 
CAD designers and dtp's. nerds don't use many monitors but tend to steer on 
/one/ (they actually never move their head - unless the other one has a p0rn 
screensaver... ;-P )

> Second, just because there are many ways to get screwed, doesn't mean we
> should add others. It's not just me: I have witnessed this problem with
> a few users.
sorry, but if you're not in control of an input device, why not just drop (or 
deactivate) it? - it's pretty simple to make the mousewheel do nothing.

> I believe mouse wheel on empty Plasma space is bad too, especially since
> it can't be undone:
clicking the "close window" button can't be undone either, so that's a bad 
feature? (short: it's a bad argument, sorry)

> scroll from empty desktop to busy desktop, now
> scroll back... can't do that, the window in front just caught the mouse
> event.
well, just adapt to the new situation (you btw introduced yourself), find some 
emtpy space and wheel there. (and if you constantly run into this situation, 
learn sth. out of it and stop using the MW to scroll desktops or don't use FS 
apps)
--
this is rather a problem when you want scroll 2 desks ahead and wheel them at 
once and the next desktop catches your wheelevent in a window - but hey: no 
one said "spaces" wasn't cooler - though having a trigger for it in a window 
corner leads to probles either, and triggering it by a key shortcut fracts UI 
dev usage... I WANT A BRAIN INTERFACE! ;-)
--

> Adding mouse wheel support to desktop items is a bad idea. It is just
> too easy to accidentally trigger a wheel event, and a mouse wheel is not
> precise enough for simple increase/decrease actions.

errr, i'll take position for my beloved MX500 that has done a great and 
reliable job for YEARS now:

could you please say "my mousewheel emulation on my touchpad"? [*]

mousewheels /are/ precise (they do one "click" by one "click", just the delta 
may vary, but it's (appside) easy to ignore it if you want to trigger 
"precise" stuff by it) and they're not "too easy to accidently trigger" as 
well (as long as your fine motorics aren't broken - but then a mouse is a 
problem in general)

in contrast to that, touchpads are the most $§$%&*' UI devices /ever/. they're 
just nowhere any "precise" enough.

luckily they tend to turn off when you plug in a mouse and if you can't use a 
mouse "well: be happy with what you've got"
(the better touchpads however let you configure their sesitivity - even 
independent for the MW emulation)

please don't get me wrong,
i /do/ see that touchpad wheels introduce problems (trust me, i do...sadly) 
but imho the solution (to this very problem) was to write an (X wide) MW 
filter that passes wheelevents only to a customizable whitelist of apps. not 
to say: "hey my touchpad is crap, can we please not use anything but single 
leftclicks?"

this way you can fix your whole touchpad trouble at once, and not just "the 
desktop", "mplayer", ... and anyone with a working mouse/wheel can just go on 
making use of it -> everyone's happy =D

Thomas

[*] i am aware that there're some cheap silly mice that try to have a "smooth 
as possible" wheel, but that's just a bad UI design for the lack of feedback.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090424/93978c42/attachment.htm>