1) are features such as display position and display timeout part of the
notification spec, and are they handled by the notification daemon or display?
2) are display decisions, such as whether to show a notification or not (e.g.
in presentation mode), handled by the notifcation daemon or displ
Nate wrote:
> What if the notification bubbles started neatly in the corner, but
> after a moment slid down the screen and slowly faded while it moved
> down a few inches, where it would disappear? New bubbles would pop up
> in the corner, but would slide down while their duration ran out.
> More
Mark Shuttleworth wrote:
> Nate wrote:
>> What if the notification bubbles started neatly in the corner, but
>> after a moment slid down the screen and slowly faded while it moved
>> down a few inches, where it would disappear? New bubbles would pop
>> up in the corner, but would slide down while
But if the user is focusing on something else, the worse thing to do would
be to force him to break his focus. I quite like notify-osd as it is (apart
from the terrible lag when using the backlight change keyboard shortcuts).
Mark, do you mind explaining what you mean with an "halfway line" ? Does
Celeste Lyn Paul wrote:
> 1) are features such as display position and display timeout part of the
> notification spec, and are they handled by the notification daemon or display?
>
I would consider both of those to be implementation decisions, and
outside the scope of the "standard". If, howev
Celeste Lyn Paul wrote:
> 1) are features such as display position and display timeout part of the
> notification spec, and are they handled by the notification daemon or display?
> 2) are display decisions, such as whether to show a notification or not (e.g.
> in presentation mode), handled by
(Apologies, but this got a bit long. I've warned ya...)
Hi all, I'm interested in the idea of making user presence more useful
desktop-wide, and notifications seem like a good candidate for
integration.
notify-osd intends to solve certain issues by:
* not getting in the user's way (click-thro
On Monday 11 May 2009 13:06, Mark Shuttleworth wrote:
> We won't bring actions back, even if a patch is contributed to do so.
> The user experience of "racing to click on the action" is fundamentally
> broken, and can't be fixed even though many people will clamour for it.
> So, actions require com
8 matches
Mail list logo
