GNOME Bugzilla – Bug 598989
Message Tray
Last modified: 2010-01-14 18:29:35 UTC
Questions about the Message Tray after reading the design doc (20090705): - Status menu: - Presumably the status menu items here just set org.gnome.SessionManager.Presence.status? - What are the icons for the statuses? - API - Presumably we need a new D-Bus interface for the new Message Tray? (I'm not familiar with the current API, but I assume it's not going to work completely for us.) - addNotification(sourceId, icon, message, importance) "sourceId" is defined by the app and is used to indicate if this is associated with a new Message Source or an existing one. "importance" is at least "critical" vs "non-critical" (qv, "The Tray should not appear at all for non-critical notifications if the user is marked as Busy".) - removeMessageSource(sourceId) - need some way of specifying "Details Mode" data too... - Should we be listening to the existing notification-daemon dbus interfaces as a legacy notification system? - Modes - Summary Mode - the spec doesn't provide any way for the user to get to Summary Mode under their own power; they have to wait until something else causes it to appear... - Detail Mode - How does this work? Does the app provide an X Window (possibly with alpha) that gnome-shell displays as needed? Or does the app provide a javascript module that the shell loads? Or provide a GtkBuilder file describing a Clutter/St UI? If the app is creating the UI, we need to figure out how it can theme itself to match the shell, assuming it wants to.
bug 599193 points out that we can listen to telepathy dbus interfaces for the IM stuff. However, there are two kinds of things we need to deal with: - "notifications" (eg, showing the text of an IM when it arrives) - "invitations" (eg, answering a voice call; user action is required) The first case is covered by the existing specs/mockups, but we need some design for the second case. > - Summary Mode - the spec doesn't provide any way for the user to > get to Summary Mode under their own power It behaves like an auto-hide panel. Also, it's visible in the overview (which was mentioned elsewhere in the spec, just not in the Message Tray section).
Hey Dan, (In reply to comment #0) > Questions about the Message Tray after reading the design doc > (20090705): > > - Status menu: > > - Presumably the status menu items here just set > org.gnome.SessionManager.Presence.status? Yes, mostly. We have some of this in GDM (inside ifdefs) already I think. Except that "idle" should not be user settable apart from locking the screen. Also, FWIW, Ubuntu uses a submenu which isn't a bad idea either. Need to go back and do a design for this menu. > - What are the icons for the statuses? Good question. This is the primary reason we didn't complete this work in GDM. We were waiting on some icons. Still are. I'll try to follow up on this. > - API > ... > - Should we be listening to the existing notification-daemon dbus > interfaces as a legacy notification system? Maybe. There may be a few difficulties. Most use of the existing interface is not well behaved. For example, most apps seem to "fire-and-forget" notifications rather than treat them as an alternate front end to the application or service. Also, our system is a conbination of status icon + notification where the existing notification spec does not deal with any kind of persistence. Maybe to summarize some problems with the old notification spec: * we don't have any way to correlate application with notification through the spec alone - though maybe we can sniff the sender * apps or services don't treat the system as an alternate UI but more like a message log * apps or services rarely update notifications in place * apps or services rarely recall messages when no longer needed (eg. when the app becomes focused again) These probably aren't too hard to work around. Also, I'll try to do a survey of what apps are currently using libnotify and how they are using it. > - Modes > > - Summary Mode - the spec doesn't provide any way for the user to > get to Summary Mode under their own power; they have to wait until > something else causes it to appear... It says (or should say) you are be able to go to the bottom of the screen and it will appear. It also appears in the overview as a reminder. > - Detail Mode - How does this work? Does the app provide an X Window > (possibly with alpha) that gnome-shell displays as needed? Or does > the app provide a javascript module that the shell loads? Or > provide a GtkBuilder file describing a Clutter/St UI? I'm not going to speak to the implementation but I think the Detail could be considered an alternate front end to the application or service. > If the app is creating the UI, we need to figure out how it can > theme itself to match the shell, assuming it wants to. Yeah we want to keep the visual design of this as consistent and constrained as we can. It will directly impact how people view the shell. Though I suppose you can do with using either norms or architecture.
(In reply to comment #1) > bug 599193 points out that we can listen to telepathy dbus interfaces for the > IM stuff. > > However, there are two kinds of things we need to deal with: > > - "notifications" (eg, showing the text of an IM when it arrives) > > - "invitations" (eg, answering a voice call; user action is required) I'm not too sure this is exactly the distinction though. To me a voice call isn't that different from say an alarm going off: Wake the f*** up! You have an appointment [Snooze] [Dismiss] or {picture} Incoming call from Dan Winship [Ignore] [Answer] If I miss either of these notifications they should go and sit in the summary area. And if I look at them again I should see, for example: {picture} Missed call from Dan Winship [Dismiss] [Call back] or similar. Should these appear even if you are busy? By default I think yes. Thought that may need to be configurable. In that sense, simply assigning them a severity won't really work. I suppose we should always show critical battery warnings.
(In reply to comment #3) > I'm not too sure this is exactly the distinction though. To me a voice call > isn't that different from say an alarm going off: > > Wake the f*** up! You have an appointment [Snooze] [Dismiss] Sure, but there's no design for that either; all the message tray notifications that have been mocked up so far (that I've seen) are non-interactive. It's only the detail view that lets you interact.
gonna close this, we can have more specific bugs