Big fan of notify-osd overall but the new vertical placement is really
unintuitive, due to being separated from everything it should be
associated with and intrusive due to its position. I too thought it
was a bug initially.
Just so y'all know =D
Cheers,
Jack
--
Leighman | 'And, if rain brings winds of change, let it rain on us forever'
On 28/08/2009 11:06, Mirco Müller 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 ...
Mirco
_______________________________________________
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ayatana
More help : https://help.launchpad.net/ListHelp
|