2011/7/8 Aurélien Naldi <aurelien.na...@gmail.com> > 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.
That is no longer true. Usually notifications are shown for a short time at the bottom center of the screen and then move to the summary until acknowledged by the user. Applications can specify a 'persistent' hint though, which means that a notifications remains in the summary even after having been acknowledged (e.g. rhythmbox uses the hint for its "currently playing" notifications), until the applications exits or explicitly removes the notification. The notification area was used both for such notifications and to provide a > way to interact with > "background" applications. > True, though the latter was always a HIG violation. As mentioned in my previous mail, I've suggested a way to "background" applications which doesn't abuse the message tray, but designers' reactions have been rather reserved. As I see it, the use of "notification" icons as a way for applications to run in the background has its origins on Windows - as there are no workspaces, every running application uses precious space in the task bar, so the "minimize-to-tray" behavior was created as a workaround. Given that GNOME3 does have workspaces to "move stuff out of sight" and no task bar which could get cluttered, the need for the "background" workaround pretty much disappears. > 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. > No, there is no API - the name "system area" should really say it all. Applications can use status icons, although their use is discouraged, and there are patches for adding support for "app indicators" in the message tray as well - though while the latter would have a more integrated shell look, conceptually it's no less broken than status icons, so it's not clear that it will be merged. Personally I think the KDE spec is broken by design, as it defines "bits of information" and allows both applications and "hosts" (e.g. the entity which displays the indicator) to pick an arbitrary subset - this works fine as long as applications can assume a specific implementation (as the Canonical one), but would fail silently when an implementation happens to expect a completely different subset than the application. Ironically Canonical should be well aware of that possibility, as they implemented the notification spec without support for actions, which was optional in the spec but taken for granted by many applications. Fortunately, unlike the notifier spec, the notification spec provides a mechanism for testing the server's capabilities, so applications incompatible with Canonical's notify-osd could be patched ... > If it can be extended, which protocol does it use? > If it can not be extended, does it mean that some other solution > exists (now or as plan) or that the shell will NOT allow this? > The system are cannot be extended by applications, and extensions are not encouraged to do it (though at least in my opinion there are cases where doing so is justified). Maybe the notification tray is not the right place for this, but the > protocol used for the indicators is just a protocol, the shell can the > choose where these things are placed, hide some of them, show them in > the overview or whatever feels right to the designers. Maybe the > protocol should be extended to add hints allowing better placement > In my opinion that is the wrong way looking at it. "How should XY be implemented" is not an interesting question, try to identify a problem in the current shell design, and designers will work on a solution. Florian
_______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
