--Boundary-01=_URd8J7qlKVGt5Zy
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Am Friday 24 April 2009 schrieb Aur=C3=A9lien G=C3=A2teau:
> 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,=
=20
CAD designers and dtp's. nerds don't use many monitors but tend to steer on=
=20
/one/ (they actually never move their head - unless the other one has a p0r=
n=20
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=20
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=
=20
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 s=
ome=20
emtpy space and wheel there. (and if you constantly run into this situation=
,=20
learn sth. out of it and stop using the MW to scroll desktops or don't use =
=46S=20
apps)
=2D-
this is rather a problem when you want scroll 2 desks ahead and wheel them =
at=20
once and the next desktop catches your wheelevent in a window - but hey: no=
=20
one said "spaces" wasn't cooler - though having a trigger for it in a windo=
w=20
corner leads to probles either, and triggering it by a key shortcut fracts =
UI=20
dev usage... I WANT A BRAIN INTERFACE! ;-)
=2D-
> 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=20
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 del=
ta=20
may vary, but it's (appside) easy to ignore it if you want to trigger=20
"precise" stuff by it) and they're not "too easy to accidently trigger" as=
=20
well (as long as your fine motorics aren't broken - but then a mouse is a=20
problem in general)
in contrast to that, touchpads are the most $=C2=A7$%&*' UI devices /ever/.=
they're=20
just nowhere any "precise" enough.
luckily they tend to turn off when you plug in a mouse and if you can't use=
a=20
mouse "well: be happy with what you've got"
(the better touchpads however let you configure their sesitivity - even=20
independent for the MW emulation)
please don't get me wrong,
i /do/ see that touchpad wheels introduce problems (trust me, i do...sadly)=
=20
but imho the solution (to this very problem) was to write an (X wide) MW=20
filter that passes wheelevents only to a customizable whitelist of apps. no=
t=20
to say: "hey my touchpad is crap, can we please not use anything but single=
=20
leftclicks?"
this way you can fix your whole touchpad trouble at once, and not just "the=
=20
desktop", "mplayer", ... and anyone with a working mouse/wheel can just go =
on=20
making use of it -> everyone's happy =3DD
Thomas
[*] i am aware that there're some cheap silly mice that try to have a "smoo=
th=20
as possible" wheel, but that's just a bad UI design for the lack of feedbac=
k.
--Boundary-01=_URd8J7qlKVGt5Zy
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
p, li { white-space: pre-wrap; }Am Friday 24 April 2009 schrieb Aur=C3=A9lien G=C3=A2teau:
> 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 o=
n /one/ (they actually never move their head - unless the other one has a p=
0rn 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 wit=
h
> 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.<=
br>
> I believe mouse wheel on empty Plasma space is b=
ad 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 mous=
e
> event.
well, just adapt to the new situation (you btw introduced yourself), find s=
ome emtpy space and wheel there. (and if you constantly run into this situa=
tion, learn sth. out of it and stop using the MW to scroll desktops or don'=
t use FS apps)
=2D-
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 w=
indow corner leads to probles either, and triggering it by a key shortcut f=
racts UI dev usage... I WANT A BRAIN INTERFACE! ;-)
=2D-
> 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 n=
ot
> precise enough for simple increase/decrease actions.
errr, i'll take position for my beloved MX500 that ha=
s done a great and reliable job for YEARS now:
could you please say "my mousewheel emulation on my t=
ouchpad"? [*]
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 acc=
idently 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 $=C2=A7$%=
&*' UI devices /ever/. they're just nowhere any "precise" enough.
luckily they tend to turn off when you plug in a mous=
e 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 ind=
ependent 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 f=
ilter 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 singl=
e leftclicks?"
this way you can fix your whole touchpad trouble at o=
nce, and not just "the desktop", "mplayer", ... and anyone with a working m=
ouse/wheel can just go on making use of it -> everyone's happy =3DD
Thomas
[*] i am aware that there're some cheap silly mice th=
at try to have a "smooth as possible" wheel, but that's just a bad UI desig=
n for the lack of feedback.
--Boundary-01=_URd8J7qlKVGt5Zy--