KarmicNotifyOSDUDSDiscussion

UDS Discussion

(output from the UDS session)

Note: the follow-focus mode seems to make more sense for advanced users in the audience

Question about the appearance and the ability to adapt to a dark background. Having a light and a dark theme that the notification system could adapt to. Open to suggestions, knowing that we consider the user shouldn't have to deal with configuring that, ie that the system should adapt automatically

Feedback from the audience about the multi-monitor setup (incomplete) 15 persons use multi-monitor setup 13 would use focus-follow 1 user (Rick Spencer) considers that having them unpredictable (ie in focus-follow mode) would be highly disturbing All said that displaying notifications on all screens would not make sense (make them too intrusive, would break the ephemeral aspect)

KDE is adopting a standard media control interface. The media control interface is also providing feedback mechanism.

Note: this roadmap is now discussed on #ayatana

How do we handle multiple monitors?

  • Currently they appear next to the panel
  • multiple monitors are used in different configurations
    • main screen and secondaary
    • wider workspace
  • Currently, if there is aa panel, top level is sticks to that

How to handle notifications when videos are playing? Is the current approach of hiding them consistent enough? Do the users like it? Need a way to distinguish and not hide confirmation bubbles.


(this was previously living at: https://blueprints.edge.launchpad.net/ubuntu/+spec/dx-karmic-notify-osd)

RainCT: Not directly related to notify-osd, but FYI here's a proposal for notifications with actions which is being discussed at the GNOME Shell mailing list: http://www.gnome.org/~clarkbw/designs/system-inline-notifications/system-inline-notifications.gif

dbarth: The scope of this spec is to improve notify-osd, in accordance with the design principles we defined in 9.04 for interacting with users. @RainCT: We don't think that such notification mechanisms can carry action buttons in a usable and scalable way.

@dbarth: Yeah, I'm not saying to put notifications into notify-osd, just telling you to keep on mind that GNOME is also thinking about it. -- RainCT

tgpraveen: i feel concerned about the point " suppressing bubbles when any window is full-screen" although this might be an option and disabled by default, maybe the do-not-disturb mode should be able to better take care of cases where this might be desired. Also one of the main advantages of the new system was that notifications came on top of full screen windows which they couldn't earlier. Say i am watching video in totem in full screen, i might still want to know when i get a message from a friend via pidgin, or when i change volume, or when i loose wifi etc. So please if this is added then also DISABLE it by default.

hanthor: I would like to suggest that any notify-osd be made an option on a preference panel or at least in gconf. Growl is highly customizable on Mac OS X and it has become a wonderful tool. I think that being able to change what and how notifications are displayed will be essential to the user experience if this notification system will stay in place.

Tom Wright: @tgpraveen, it should discriminate based on app but not for hotkey icons and the like (say disturb all but fullscreen presentations and maybe flash). Activity notifications (e.g. pidgin or mail) should be universally turned off by the status menu.

DesktopExperienceTeam/KarmicNotifyOSDUDSDiscussion (last edited 2009-08-07 11:16:01 by dbarth)