Adjustable Clock, Spell Check and Window List applets moved to kdereview

[Aaron J. Seigo]

On October 10, 2009, Emdek wrote:
> On 09-10-2009 at 22:05:03 Aaron J. Seigo <aseigo at kde.org> wrote:
> > On October 9, 2009, Emdek wrote:
> >> On 09-10-2009 at 20:19:40 Aaron J. Seigo <aseigo at kde.org> wrote:
> >> > right clicking is "well known" to trigger a context menu, but other
> >>
> >> than
> >>
> >> > that
> >> > special behaviour we try not to overload mouse button clicks with
> >>
> >> various
> >>
> >> > behaviours. the reason is that these behaviours are not discoverable
> >>
> >> and
> >>
> >> > end
> >> > up with items requiring multi-button mice. fingers tend to only have
> >>
> >> one
> >>
> >> > button. ;)
> >>
> >> Sure. ;-)
> >>
> >> But multi button mouses are something normal (and these with middle
> >> button
> >> are something typical for at least five years)
> >
> > that's fine; the issue is that when the buttons do different things in
> > different places it means people have to form complex mental models of
> > what
> > causes which action where. this is something people on average suck at.
> >
> > right click works because it's really consistent. right click -> menu.
> >
> > add to this that the click behaviours are almost completely
> > non-discoverable
> > until you try them. a lot of people still don't know what middle
> > clicking on a
> > link in a web browser can do :)
> 
> But we can't forget about that group of users that wants do a bit more
> advanced things and finds use of for example middle mouse button as
> something handy. ;-)

there are a small # of such people. they are the overwhelming minority, 
however. catering to them instead of trying to make things work well using 
non-advanced interaction techniques usually works out better.

and as apple has shown time and again, even advanced users actually appreciate 
that approach as well.

iow, this "advanced things that advanced users like" idea is largely a myth.

> By the way, is it possible to have documentation (handbook) for users for
> applets?

yes; we don't have a way to get to it from the widget itself, however. 
something that needs to be added still.

> There could be placed information about these invisible features.

while a good idea, we should be aware that rather few people read such 
documentation very thoroughly.

> >> and we already have some
> >> signals in API that propagate information about clicks done using other
> >> buttons (for example for tool tip previews).
> >
> > yes. i'm still not overly happy about that, btw. it's a direct fix to an
> > obvious use case. i keep wondering if we couldn't do it more like how we
> > do
> > the new system tray, though, with some "semantic" information like
> > "primary",
> > "secondary" and "wheel".
> 
> I'm not sure if it is really needed and won't make some things more
> complicated to some "fresh" programmers.

assuming these programmers can tie their own shoes in the morning and do other 
such complex tasks, i doubt "primary action" will confuse anyone.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091011/fff00ad6/attachment.sig