Hi Luca, On Fri, May 15, 2009 at 1:29 PM, Luca Ferretti <elle....@libero.it> wrote: > 2009/5/15 William Jon McCann <william.jon.mcc...@gmail.com>: >> On Thu, May 14, 2009 at 7:58 PM, Luis Menina <liberfo...@freeside.fr> wrote: >>> >>> Please, don't try to abuse the system tray for things that should be >>> applets. System tray has been made to notify events. One should be able to >>> use GNOME without requiring a notification applet. A recent example of >>> things gone wrong is the volume controler : it should be an applet an not a >>> system tray item, as it presents a permanent state and not an event nor a >>> response to an event. >> >> Seems to me you have this almost entirely backwards - you should be >> able to use GNOME without applets (though we need GNOME Shell to make >> this a reality). The volume status icon was wrong as an applet. >> There are a number of reasons for this that I won't go into here. The >> volume status icon shows you the current status of the system volume. >> This is very similar to the power and network status icons. > > William, please note that *currently* we have a Notification Area and > GNOME HIG speaks about notification icons, so IMHO Luis is right: by > now the volume icon (while it calls itself applet) in Notification > Area is, strictly speking, wrong because, as you say, it represents a > *status*, not a *notification*.
Firstly, the HIG does not call it a Notification Area it calls it a Status Notification Area (as does Windows). Secondly, the HIG does not say that system status indicators are wrong for this area. Lastly, the HIG is a set of guidelines and it is entirely possible that it is wrong or that we want to change the way we're using the area. Matthew (mpt) and I discussed this on IRC the other day and I think we agree that: * this area is not an effective way to display notifications * we may want to rename it the System Status Area * we need to improve our notification story (Ubuntu is already experimenting with this) * we need to change and improve the HIG * we should make these icons behave more like menus * we may need to change or improve GtkStatusIcon I'd like to go a few steps farther and try to use a rule of thumb that status icons should serve primarily as visible indicators and not as primary interaction points - only optional ones. This is especially important on small form factor devices where we may not want to make the panel, that holds the status area, large enough to enable interaction. Look at basically all embedded devices (especially phones like iPhone or Android) for examples of this. For example, the volume indicator displays the volume status but the primary interaction would be with hardware controls or a control center action. Trying to do this makes it very obvious how broken our control center story is... Some people are concerned that if we have an interface that looks, feels, and is named similarly to the Windows Status Notification Area that it will be difficult to change application developers expectations and behaviors. Hard to say. Perhaps if there was some architecture in addition to the norms imposed by the HIG and a developer community that agrees on the correct usage we could regulate the proper usage. I'm not sure that even if we came up with an entirely different API that, over time, we wouldn't face the same problems. Look at menu extras on OS X as an example. Application developers have already started adding lots of non-default somewhat oddball stuff there too. An example of this is Norton Antivirus for Mac (yes it exists - I think partly for companies that have an unwavering policy that all computers must have anti-virus software)... Architecturally, I think the system status area is actually pretty solid. Owen seemed pretty happy with it too when I asked his opinion the other day. So, I think we're better off just fixing up the few issues with the current system rather than scrapping it and starting over. Particularly since this is one of the better examples of a successful XDG spec. In addition to requiring that all status icons to behave like menus, I think we need to fix at least: http://bugzilla.gnome.org/show_bug.cgi?id=558628 http://bugzilla.gnome.org/show_bug.cgi?id=565697 http://bugzilla.gnome.org/show_bug.cgi?id=583115 http://bugzilla.gnome.org/show_bug.cgi?id=583272 http://bugzilla.gnome.org/show_bug.cgi?id=583273 > So the interesting question now is: what for GNOME 3.0? do we want to > keep the "Notification Area" (then we need another solution to show > current status of some stuff, like battery, network, audio input and > output volume...) or we want to use this area for as "Status Ares" > (then we need another solution to show notifications like new email, > new IM message, new updates[1]...)? > A different approach for notifications was proposed here[2] and > something similar is going to implemented here[3]. > > In suborder, another interesting question is: how could GNOME Desktop > prevents applications to mis-use the Notification/Status area? By now > we are providing gtk_staus_icon_*() functions and usage policies on > HIG, but this wasn't enough to avoid bad usage. Yes I think we first need to acknowledge that this area is not a notification area today. Then for 3.0 we should make sure we figure out how better to present notifications to the user and improve our existing status area. It will be interesting to see how the Ubuntu experiments here work out... or if they'll be useful to adopt upstream at all. Jon _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list