Il giorno ven, 08/07/2011 alle 07.24 -0700, Adam Williamson ha scritto: > On Fri, 2011-07-08 at 15:19 +0200, Aurélien Naldi wrote: > > > As far as I know, libnotify supports only notifications (and does it > > well). They can vanish after a while or require acknowledgement, but > > they can not be truly persistent. The notification area was used both > > for such notifications and to provide a way to interact with > > "background" applications. > > The reason for this, historically, is that it's an XDG standard while > panel applets never have been, FWIW. > > > I do like the notification part in gnome-shell (beside the integrated > > chat stealing focus, but all it needs is tweaking), I was talking > > about the "interact with background application" part: I thought > > gnome-shell also had an API for this as the indicators proposed by > > canonical have been rejected. From a user point of view, the system > > area in gnome-shell is very similar. What I do not know is wether it > > is it limited to the shell and extensions, or if any application can > > add something as well. > > It's limited to the Shell (and extensions), by design. The Shell > developers want the Shell interface to be consistent, not vary between > users, distros and apps. This is not true. The message tray is a central interaction point for a well defined set of applications (chat, music, email, etc). Note the word applications: they're not part of the Core Desktop, they're replaceable and not necessarily GNOME branded or following GNOME standards. It is expected that applications use libnotify, which supports three mode of operation (although they're not documented). One can have transient notifications (which disappear immediately, like in notify-osd); one can have persistent notifications (which must be acknowledged, like in plasma); one can have resident notifications, which are very similar to status icons, except that the content is more extensible but the actions are more limited. In case libnotify is not enough, one should file a bug and explain the kind of interaction required. Everything else (systray-spec, status-notifier-item) will be supported only for backwards compatibility and may see reduced functionality in comparison with notification-spec. Again, I said a central interaction point, not the primary interaction point. It is expected (or at least, I expect this, reading design documents) that such background apps will allow for a limited interaction, while doing something not necessarily related to the app (this includes, for example, switching track in a music app, or seeing the 5 most recent unread emails and marking them read/starred/deleted). More complex activities, that require a conceptual task and focus switch, should be carried out in the full application window, which can be triggered from the dash or from any notification (transient, persistent or resident). Parallel to that, it is expected that applications will use GtkApplication (or something different, currently under development, bugs 653509, 609114 and 621203) to expose a set of application-level actions, to be shown in the Application Menu (next to Activities button) and in each dash item, along with Zeitgeist powered jumplists. This is not yet standarized as it is still under discussion (and we may end up with dbusmenu, at least at the protocol layer, to avoid useless deviations). Lastly, there is a technical issue which prevents this to work effectively: currently ShellWindowTracker uses windows to track running applications, meaning that one cannot hide the primary window while still keeping the app running, from a gnome-shell perspective: minimizing will show the window in the overview, withdrawing or destroying have the same effect from the WM side and the app is considered closed. It is probably possible to use GApplication (watching the associated dbus name) to track apps, but this is not yet implemented and may have even more issues. Giovanni
Attachment:
signature.asc
Description: This is a digitally signed message part