[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KNotificationAreaItem
From: Thomas =?iso-8859-1?q?L=FCbking?= <thomas.luebking () web ! de>
Date: 2009-04-24 16:43:25
Message-ID: 200904241843.26227.thomas.luebking () web ! de
[Download RAW message or body]
afaics his request went far beyond "don't use wheels on systray icons"
regarding that (and hoping i understood aarons proposal) there should be no
"mouse wheel" on no "icon" at all, because both are not assumable anymore.
--
you've got a client, a server and a protocol. the server signals the client an
action requesting input and the client reacts.
what actually triggered the input on the server and if it displays an icon at
all is then matter of specific implementation.
--
as for "sensible limits": i think there's none. you can just have "priority"
some apps won't make use out of more than one action at all, while others
might provide access to 15.
if you connect them to the actions in priority descending (and maybe
configurable to personal preferences) order, that's no problem at all.
e.g. for kmix
- #1 show simple mixer
- #2 show context menu (these may already be swapped by pers. pref.)
- #3 toggle mute
- #4 master volume up
- #5 master volume down (MW, press mouse and move, ...)
- #6 line volume up
- #7 line volume down (e.g. ctrl + MW)
- ....
the app and it's proxy are fully usable by one or two actions, but if the
client can make use, the server can provide and the user wants more, nothing
holds them back.
so why exactly should we artificially limit interaction to some arbitrary
degree?
i mean, it's not like auntie nora has to learn all the possible stuff or frag
2h a day to improve a mouse skills. (e.g. i can squeeze a document out of
LaTeX, but i'm not nearly half aware on one percent of all options...)
Thomas
Am Friday 24 April 2009 schrieb Robert Knight:
> I'm thinking it would be a good idea to keep the number of ways of
> interacting with an icon very limited to force application developers
> to make the interaction 'model' simple. Three choices, as provided by
> the proposed API, is a sensible limit.
>
> I know some KDE users would love the idea of being able to two a
> three-fingered twisting gesture with medium pressure to change their
> microphone input volume in KMix but that's not helpful when that piece
> of the desktop UI is something which is meant to be used by a broad
> audience including less technical users and users who don't have the
> motor skills of a regular counter-strike player.
>
> Regards,
> Robert.
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" \
"http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" \
content="1" /><style type="text/css">p, li { white-space: pre-wrap; \
}</style></head><body style=" font-family:'Segoe'; font-size:10pt; font-weight:400; \
font-style:normal;">afaics his request went far beyond "don't use wheels on systray \
icons"<br> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; \
margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>regarding that (and hoping i understood aarons proposal) \
there should be no "mouse wheel" on no "icon" at all, because both are not assumable \
anymore.<br> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; \
margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>--<br> <p style="-qt-paragraph-type:empty; margin-top:0px; \
margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; \
text-indent:0px; -qt-user-state:0;"><br></p>you've got a client, a server and a \
protocol. the server signals the client an action requesting input and the client \
reacts.<br> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; \
margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>what actually triggered the input on the server and if it \
displays an icon at all is then matter of specific implementation.<br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>--<br> <p style="-qt-paragraph-type:empty; margin-top:0px; \
margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; \
text-indent:0px; -qt-user-state:0;"><br></p>as for "sensible limits": i think there's \
none. you can just have "priority"<br> <p style="-qt-paragraph-type:empty; \
margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; \
-qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>some apps won't make \
use out of more than one action at all, while others might provide access to 15.<br> \
if you connect them to the actions in priority descending (and maybe configurable to \
personal preferences) order, that's no problem at all.<br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>e.g. for kmix<br>
- #1 show simple mixer<br>
- #2 show context menu (these may already be swapped by pers. pref.)<br>
- #3 toggle mute<br>
- #4 master volume up<br>
- #5 master volume down (MW, press mouse and move, ...)<br>
- #6 line volume up<br>
- #7 line volume down (e.g. ctrl + MW)<br>
- ....<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; \
margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>the app and it's proxy are fully usable by one or two \
actions, but if the client can make use, the server can provide and the user wants \
more, nothing holds them back.<br> so why exactly should we artificially limit \
interaction to some arbitrary degree? <br> i mean, it's not like auntie nora has to \
learn all the possible stuff or frag 2h a day to improve a mouse skills. (e.g. i can \
squeeze a document out of LaTeX, but i'm not nearly half aware on one percent of all \
options...)<br> <p style="-qt-paragraph-type:empty; margin-top:0px; \
margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; \
text-indent:0px; -qt-user-state:0;"><br></p>Thomas<br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Am \
Friday 24 April 2009 schrieb Robert Knight:<br> > I'm thinking it would be a good \
idea to keep the number of ways of<br> > interacting with an icon very limited to \
force application developers<br> > to make the interaction 'model' simple. Three \
choices, as provided by<br> > the proposed API, is a sensible limit.<br>
><br>
> I know some KDE users would love the idea of being able to two a<br>
> three-fingered twisting gesture with medium pressure to change their<br>
> microphone input volume in KMix but that's not helpful when that piece<br>
> of the desktop UI is something which is meant to be used by a broad<br>
> audience including less technical users and users who don't have the<br>
> motor skills of a regular counter-strike player.<br>
><br>
> Regards,<br>
> Robert.</p></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic