unity-design team mailing list archive

[Mike Rooney <mrooney@xxxxxxxxxx>]

On Fri, Aug 28, 2009 at 3:06 AM, Mirco
Müller<mirco.mueller@xxxxxxxxxxxxx> wrote:
> Am Freitag, den 28.08.2009, 11:14 +0200 schrieb David Barth:
>> Mark Shuttleworth wrote:
>> > Mirco Müller wrote:
>> >
>> > > Am Freitag, den 28.08.2009, 09:30 +0100 schrieb Mark Shuttleworth:
>> > >
>> > >
>> > >
>> > > > ...
>> > > > Mirco, is there any way to know, when the notification appears, how
>> > > > long the mouse has been stationary?
>> > > >
>> > > >
>> > >   Yes, that should be doable. I'll give that a try today and let you
>> > > folks know about the outcome.
>> > >
>> > >
>> > OK, just let us know if it's *possible*.
>
> Well, it is possible :)
>
>> >  I'm thinking that we might
>> > leave the fade if the mouse has moved in the past 5 seconds on the basis
>> > that your eye is likely to be tracking the mouse. But if the mouse has
>> > been still, we wouldn't fade because you just left the mouse there from
>> > previous work.
>> >
>> > This would be pretty fragile to small accidental nudges of the mouse,
>
>        It would not need to be "fragile" in this regard. We could introduce a
> movement-threshold or delta, which, if stayed within, won't make a
> movement count as "real" mouse movement.
>
>        What that delta/threshold should be is another question of course and
> probably not that easy to answer, as people have different
> mouse-acceleration settings, movement- or "jerking"-habits.
>
>> >  so
>> > I don't think we should implement it yet, but I'd like to know how much
>> > we can cheaply determine about the mouse's behaviour in the past few
>> > seconds. I do *not* want notify-osd to be eating CPU cycles watching the
>> > mouse all the time, though :-)
>
>        Like David wrote, we have a mouse-pointer monitor in notify-osd
> already, because we need that in order to be able to do the
> proximity-fade. To that we can easily add a "last 5 second
> activity"-watcher.
>
>> Currently, we're adding a cursor monitoring callback once a
>> notification is on display, but that's polling. It's acceptable to
>> finely track what the user is doing for fading, blurring, etc. But not
>> as general mechanism.
>>
>> However, using the XScreenSaver extension, the X server is maintaining
>> this information for us, so that we can track the idle time, without
>> doing any polling, in particular when no notification is on display.
>
>        Using this does not gain (or save) us anything (in terms of
> CPU-cycles... not that our current monitor is very costly), since we
> have to do the mouse-pointer monitoring anyway already for
> proximity-fade. To our current mouse-motion monitor we can easily add a
> "last 5 second activity"-watcher.
>
>        It's so easy that I already have a working patch for this. Not super
> nice yet, but proof enough that it's a possibility for us, should we
> decide to pursue that path (see attachment).
>
> Best regards ...


While we are on the subject of mouse cursor behavior, I just want to
mention to keep in mind the visibility of the mouse. I noticed before
if I am doing something which hides the mouse cursor, the notification
would appear faded if the mouse was there, even if it was hidden. In
this case the mouse is not being used and it seems like wherever you
do conditional logic based on mouse position/proximity, there should
first be a check to make sure it is visible. Otherwise you'll end up
with notifications behaving strange (from the users perspective) when
the cursor is hidden but close to the notification.

-- 
Michael Rooney
mrooney@xxxxxxxxxx