thomas.luebking at web.de
Fri Apr 24 16:01:40 BST 2009
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
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
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
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
[*] 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...
More information about the kde-core-devel