[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: [Fwd: Usability and open source]
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       2000-01-31 12:30:51
[Download RAW message or body]



Stephan Kulow wrote:
> 
> --
> It said Windows 95 or better, so in theory Linux should run it
>                                                 GeorgeH on /.
> 
>   ------------------------------------------------------------------------------
> 
> Subject: RE: Usability and open source
> Date: Mon, 31 Jan 2000 10:44:38 +0100
> From: "Ben Last" <ben@last.uk.com>
> To: <kde-look@kde.org>, <kde-core-devel@kde.org>
> 
> > From: Richard Moore [mailto:rich@ipso-facto.freeserve.co.uk]
> > I have been doing a little work in this area. I am writing a class
> > KMouseHole that tries to improve Fitt's performace of widgets....
> > The idea is to make a widget 'virtually' larger than it really is
> > by moderating the relationship between mouse movement and pointer
> > movement using QCursor::setPos(). It is similar to a snap-to type
> > systsem, but less proscriptive.
> Well, not having tried it maybe I shouldn't comment, but interfering with the
> relationship between mouse movement and pointer movement can *really* get
> annoying (in fact, it feels very, very wrong).  I'd also suggest that this is a
> misinterpretation of Fitt - the law is intended to demonstrate the relationship
> between screen size and position and effective availability to the user; big
> things are easier to click.  Things "grabbing" the pointer as it passes over

I understand Fitt's law, this technique increases the clickable area of the
widget and so should increase the Fitt's value. Of course there will need to
be testing before we can see if the concept works. In fact the 'feel' is quite
natural because of the very small movements involved, though in a future
version it would be better to moderate the mouse speed instead of position.

> interfere with the system's ability to reflect the user's intentions.
> It also means that more widgets will be responding to MouseMove events (and
> window-enter and window-exit, if I recall my X11 correctly) and thus you'll
> potentially get more CPU consumption for a single mouse move (and apps can't be
> swapped out if they have to track mouse moves, etc, etc).

This is a non-issue as most widgets where the class would be useful have
tooltips which means mouse tracking is enabled anyway.

Cheers

Rich.

> 
> > On a more general note though, I think we should perhaps be trying
> > to recruit academic institutions for this. I know from my experience
> > at the University of Manchester, that if we could define some small
> > projects in research areas like this and were willing to put in
> > the work to support the efforts and evaluate the results then we
> > could propose these projects for students.
> Now, that's a *nice* idea - students get a research project and KDE gets the
> benefit.  In fact, MS certainly have a history of using research students and
> getting the benefit of their ideas, so why not the OSS community!
> 
> ben

-- 
     Richard Moore		rich@ipso-facto.freeserve.co.uk
http://www.robocast.com/	richard@robocast.com
http://developer.kde.org/	rich@kde.org

[prev in list] [next in list] [prev in thread] [next in thread]