Ubuntu is phasing out the notification area (a.k.a. “system tray”), because of its ineffectiveness at notifying people of things, and its inconsistent behavior. Many programs that previously used the notification area should use other notification mechanisms instead. Some notification area items will be replaced by various system status menus we’re introducing. For a few programs, it will be appropriate to use custom status menus.
Why we’re doing this
This story begins in 1990, when Microsoft released Windows 3.0 without an easy way to see what time it was.
There was a Clock application in Windows, and it could float on top of all other windows, but setting that option wasn’t obvious. And when the Clock was minimized, its icon showed the current time, but usually that icon was covered by the Program Manager window and any other maximized windows.
Microsoft fixed this during the design of Windows 95 by embedding a clock in the new taskbar. They also realized that people wanted a quick way of changing the system volume, so they placed a speaker control next to the clock. Then for people using notebook computers, they added a battery meter and PCMCIA status as well.
Together, these elements were controlled by a program called systray.exe. But at some point, Microsoft decided to make this mechanism generic, so that any application could use it. And so was born something called the notification area.
Eventually geeks discovered the systray.exe name and started calling the notification area the “system tray”. Microsoft has been struggling for 15 years now to get people to call it the “notification area” instead, and largely failing.
In the first versions of Gnome, there was no notification area (though, infamously, there were five separate clocks). Building on a “status dock” in Gnome 1.4, Gnome 2.0 introduced the status notification area, again with strict instructions to use it only for notifications — only to find that people kept calling it the “system tray” here too.
I think there are two basic reasons people keep using this name. The first is that the notification area has always been used for things that aren’t notifications. The first two items in the Windows implementation, clock and volume, were never “notifications” in any meaningful sense. And in Gnome there’s a technical distinction between “panel applets” (such as the clock and volume) and the notification area itself, but visually, that distinction barely exists.
The second reason is that the notification area isn’t actually good at delivering notifications. A tiny square icon, taking up less than 0.1 percent of a typical display, can communicate extremely simple, ignorable things — like “you have new messages” or “your battery is charging”. But any information more abstract than that, such as “software updates are available for this computer”, is a non-starter. This became clear when Windows 2000 introduced notification balloons that point at particular icons, explaining what they mean. These balloons have their own problems: in particular, they float on top of every other window regardless of whether you need to pay attention to them right now. (For that reason, we replaced Gnome’s equivalent notification balloons with Notify OSD bubbles that you can click straight through if you want to.)
The situation is made worse by developers who feel the urge to add a notification area icon for their application just because they can. In Ubuntu, many programs — Rhythmbox, Banshee, VLC, Pino, and Pidgin, to name just five — put items in the notification area that aren’t notifications at all.
Often this is a substitute for minimizing the window, to avoid cluttering the taskbar. For example VLC’s notification area has a menu with a “Hide VLC media player in taskbar” item, and the AllTray utility exists for people who want “to have a program always running, but easy to put out of the way”. That may make perfect sense to the developers of those individual applications. But looking at the operating system as a whole, it’s crazy. No competent designer, sitting down to design an operating system from scratch, would say to themselves “I know, let’s have two completely inconsistent ways to hide windows”.
Microsoft, to their credit, have tried to rein in this kind of misuse of the notification area in Windows. But combined with their devotion to backward compatibility, that has caused its own problems. Windows XP hid persistent notification area items by default, and therefore also had a button for revealing them just in case you needed to access them. And in Windows Vista and 7, there is an entire dialog devoted to toggling which notification area icons should be hidden. It’s the OS equivalent of a car dealer including, with every car, a free roll of masking tape so you can cover up unwanted warning lights on the dashboard.
Meanwhile, there’s another problem with the notification area: inconsistent behavior. On Windows, in theory, a left single-click is supposed to “display whatever users most likely want to see”, a right-click is supposed to display a context menu, and a left double-click is supposed to either “Perform the default command on the context menu” or “perform the same action as a left single-click”. In practice, icons have a huge variety of behaviors, with the only common element being a context menu on right-click — to the point where some users have forgotten that they could ever left-click on the icons.
In Gnome, the same kind of hyper-flexibility is baked into the System Tray Protocol: items embedded in the notification area can do pretty much anything they like. So we’ve inherited the same problem as Windows: some items open a menu on left click, some open a menu on right click, some do both, some open a window, and at least one reliably disappears when you click it. It’s hopelessly inconsistent — and as long as we continue with the current protocol, it always will be inconsistent.
We can’t go on like this.
Nuke the entire site from orbit — it’s the only way to be sure
We took our first small step towards getting rid of the notification area in Ubuntu 9.04, when we stopped trying to use it to notify people of software upates, and instead just opened the updates window. Our reasoning was that a tiny icon couldn’t possibly do a good job of conveying something bureaucratic like the availability of new versions of software. (We still have work to do to simplify and streamline the presentation of updates, and we’d be glad to have help with that.)
In Ubuntu 9.10, we introduced the messaging menu, which replaced the various notification area items from messaging applications (Empathy, Evolution, Gwibber, and so on). We also introduced the session menu, which replaced both the user account switching menu (fast-user-switch-applet) and the big red button that had previously opened the shutdown dialog.
In Ubuntu 10.04, we’ve introduced the sound menu, which replaces the Gnome volume applet; and the “me” menu, which replaces the items for setting your status in various instant messaging programs.
In Ubuntu 10.10, we plan to introduce a power menu, which replaces the Gnome Power Manager applet; a network menu, which replaces the Network Manager applet (nm-applet); and a clock menu, or time and date menu, that replaces the Gnome clock applet. We’ll also be extending the sound menu, to replace the notification area items for music players. We will be posting more about these and other menus, and asking for feedback on our designs, in the coming weeks.
The pattern here is that everything is becoming a menu. And further, everything is becoming a single set of menus. You can see glimmerings of this in Ubuntu 10.04: for example, if you click on the messaging menu by mistake instead of the sound menu, you can just slide straight over to the sound menu without having to click again. (Currently, this is implemented using two panel applets, indicator-applet and indicator-applet-session. We’ll be consolidating this in future Ubuntu versions.)
Our roadmap is that in Ubuntu 11.04, one year from now, there will be no notification area. And in Ubuntu Netbook Edition, we’ll remove it even earlier, in 10.10. So if you develop an application that uses the notification area, and you want the millions of Ubuntu users to be able to use it, now is the time to change it.
What applications should do instead
Many programs should not have an item in the panel at all. Where a notification area icon was being used mainly as a substitute for minimizing, the window should just minimize instead. We will be working on ways for long-running applications to be less obtrusive when their windows are minimized.
Some applications should integrate into one of the menus that aggregate a particular category of items. An e-mail, instant messaging, feed reading, or similar applications should integrate into the messaging menu. An instant messaging client should respond to status changes in the “me” menu. And a music player should integrate into the sound menu. We’ll provide tutorials and example code for each of these things, as we finalize designs for each menu.
In a few cases, it makes sense for an application to use its own custom status menu. Some applications do this already in Ubuntu 10.04, and we’ll be extending this “application indicator” mechanism in Ubuntu 10.10. The application indicator protocol uses D-Bus, which means that the menu a program publishes looks native whether it’s running in Gnome (appearing in the Gnome panel) or in KDE (in the KDE system tray). Once the API stabilizes in a year or two, we’ll propose it for inclusion in those environments.
We welcome your feedback on these plans, either on this post directly, or on the Ayatana mailing list.
Our colleagues in Canonical’s desktop experience team have worked extremely hard over the past year in implementing these menus and APIs, and we are grateful to them. This is not revolutionary work, but it is important. When we’re done, we will have fixed an annoyance that has existed since years before Ubuntu began.
Try to be faster than Apple ;)
>you can just slide straight over to the sound menu without having to click again
I’m on a Mac now. Using Snow Leo. I can click at the AirPort (WiFi) icon and slide over other Apple icons — Time Machine, eject, Bluetooth, volume, language, etc.
But I can’t slide over 3rd-party app icons.
>Once the API stabilizes in a year or two, we’ll propose it
Oh, so slow.
Interesting.
I hope all BitTorrent clients, P2P apps, and just plain downloading apps can go together in a common downloads menu.
But what about Windows apps running in Wine? Some of them actually minimizes to the notification area when you click on the x, and you have to rigth click the notification area icon to close it (like Spotify).
I’m also conserned about apps that you want to have running in the background, but not minimized so it shows up in the Alt+Tab all the time, especially Wine apps.
unbelievable
“if you click on the messaging menu by mistake instead of the sound menu, you can just slide straight over to the sound menu without having to click again.”
Sounds good in theory but I find that if I click on the sound menu then run the cursor up to a selection I often run sideways as well then the next menu or the one after that offers an option.
By the time I have ‘slid’ back to the sound menu options I often go too far thus getting another menu.
Too many menus too close together making for navigation hell.
If this is going to be implemented then think of the less-abled and elderly without the fine motor control that would be needed for this implementation.
Include an overarching option to ‘show one menu only per click’ to allow sensible navigation for those of us non-texting, non-gaming, artritic and just plain slow.
Nuke the whole thing from orbit!
That’s the way to do it, piss off tons of developers, break their applications on Ubuntu, and push users who really require certain aps in the tray toward another OS. I suggest the clear way to deal with this is via standards. You know, those folks over at freedesktop.org.
This surely sounds interesting. But: Do you coordinate anything of that with upstream? Also I don’t quite see how that would fit in the GNOME Shell / GNOME 3.0 world. Or do you plan to stay with the classic panel instead?
MyFreeWeb: Canonical has many, many fewer designers and engineers than Apple does. The more help we get, the faster we can improve. ;-)
Børge: Thanks for reminding us about the Wine issue (though I’m sure Scott Ritchie, the Wine maintainer, would have reminded us at UDS next month). It might be useful to research how Parallels and VMWare Fusion handle the Windows notification area.
bob: Yes, I know the problem you’re talking about. It has long been solved in GTK for submenus — you can usually drag diagonally off a submenu title towards an item near the bottom of the submenu, without triggering one of the other top-level items. We just need to apply that same submenu logic to menu titles.
Wert: You’re right, this would make a lot of sense as an XDG specification. But we need to implement it first to demonstrate that it’s feasible. “Standards” without implementations are useless.
Wert,
The KDE people have proposed this spec to fdo and we’ve proposed it to GNOME. I don’t see where this “breaks their applications” since it has a fallback mechanism.
@Wert:
You mean, like this: http://www.galago-project.org/specs/notification/
I’ve got to echo suka’s thoughts about upstream and gnome-shell.
Beyond that, though I’m sure it goes without saying given Canonical’s commitment to accessibility, please test your new design thoroughly so that users of ATs can enjoy the new experience as much as everyone else.
I was wondering why on lucid it’s easier to handle rhythmbox from the panel icon. Of course, it has a menu now. At first it was hard to get used to the right click doing nothing on the icon, but now I find it really useful.
And what’s the plan for the applications that are “minimized to the tray” instead of being closed when you click on the CLOSE button. For me it is a bad design error that when I click the red X, the application just disappears from sight.
Thanks for the awesome post, MPT.
Aside from my earlier musings on UI that affects too many places at once (on the mailing list), one thing I’m worried about is scalability. Is this design moving towards having, instead of an indicator for each service (as in Rhythmbox’s and Transmission’s indicators), a few generic meta-indicators that collect information from other applications? (Eg: indicator-messages for every category an indicator could possibly need to fill).
If so, what happens in the future as major categories of background functionality are created, perhaps that aren’t provided for by default? How can we avoid having a million different, conflicting attempts at generic geolocation meta-indicators where each geolocation service talks to a different one?
In addition, will there be a consistent API for adding things to these meta-indicators like the power indicator, or does each one risk doing things its own way? Will a service that adds to indicator-power rely on its existence, or will it gracefully fall back to creating a top level indicator?
Leo, but what does the “red X” mean?
“Activity termination” or “get this window out of my sight”?
How do you choose to draw a consistent line between the two?
Why?
Good post.
Are there any plans on what to do with the window list? If applications can’t minimize to the tray anymore, they take up a lot of space on the taskbar. On Windows 7 and OS X they use big icons without text (which can of course be emulated easily, with DockbarX or a dock app, but that’s not really the point).
Do you want to keep the text on the taskbar? Are there any plans to adjust this part of the taskbar? Or should applications that are constantly running move to one of those system status menus?
Thanks and keep up the great work. Looking forward to Lucid. :)
So, instead of the typical “left-click” to un-hide ive got to go via the menu each time a la Transmission.
Absolute genius of a unnecessary idea.
I posted a message on ubuntu-devel-discuss a few weeks ago that is somewhat related to this. How do you feel about the ‘X’ window control for “closing a window” but leaving the application running (either in the notification area or in an indicator applet)? I’ve read the responses, and I understand both sides of the argument (I think). The behavior still seems counter-intuitive to me. Do you have any ideas of how this could be improved in the workflow you’re proposing here? Or do you have any thoughts on this “problem” (as I see it) in general?
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-April/011107.html
I see now that others have brought up my issue :)
I just hope application indicators gets smarter and more capable. I can’t imagine controlling music player without scroll-to-change-song or having a menu for that task! :)
@Jeff:
That what virtual desktops are for. But new users don’t use virtual desktop because they think it’s complicated or don’t even know about it. There should be an easy way to explain about that and encourage users to use virtual desktops.
I hope ubuntu manual is covering that.
The notification area is one of the few freedesktop.org standards that are really used, and work on any desktop environment. Any app tray icon would work on gnome, kde, xfce, tint2, stalonetray…. I agree it is over-used by apps, but it should just be properly used, not to be ditched. The “indicator applets” just do the same thing, and will be over-used (read: “ineffective” and “inconsistent”) on the future.
There is a lot of great potential here but I think that hover to show information is essential e.g. banshee’s current tray app uses this well.
+1 to what Suka said.
I really find this ‘notification area removal’ pretty exciting. It’s only drawback would be that *everything* would be a menu and I *hate* the messaging indicator thingy, because I mainly use only empathy and it makes me have to click multiple times, so I usually just remove it first thing.
Anyway, this article makes a lot of sense… it’s so stupid to have the task bar and yet again have the “system tray” with same apps overall but just icons, it’s like the same crap twice but not quite.
This is one thing I appreciate Apple / Mac OS X, as well as windows7: trying to erase the line between shortcuts/launchers/tray/running applications, by somewhat making a dock.
Anyway, keep in mind Gnome Shell / Gnome 3 as well, eventually influence it.
“It has long been solved in GTK for submenus — you can usually drag diagonally off a submenu title towards an item near the bottom of the submenu, without triggering one of the other top-level items.”
I take it this refers to behavior such as how the’applications.places.system’ menus work ?.
If the menus you are proposing would work like that then well done.
As it stands in Lucid I find their operation to be frustrating and a backward step.
And don’t even get me started on having to click on a menu to access and adjust something as simple as volume.
Pre-Lucid the hover and scroll-wheel approach just seemed so right.
Now with Lucid I need two extra actions to adjust volume.
That sort of ‘improvement’ is just not right nor does it ‘reduce clutter’ it only hides it in layers of extraneous actions.
Make sure you give the network control of bittorrent apps and other download managers, if you plan on doing this. If you don’t want a gui editor, at least make it changable with gconf, otherwise it’s a real pain. There are apps like tomboy that are sooo needed in the tray; I hope you can implement jumplists so if it’s not there, we can at least sill access features as a right-click.
Sounds interesting! I look forward to seeing the new changes :)
@Samium Gromoff, I think that a consistent line between the two should be drawn, because they are different actions. If you have 4 actions and 3 controls, problems will arise. And you will get frustrated users like me that can’t predict if the application is going to shut or hide, because they behave inconsistently.
Anyway, if the “get this window out of my sight” action is needed and it’s not possible to add an extra button for it, I would set it on the minimize control, and not on the red X. Then, if the application decides to minimize to the tray instead of to the windows list, I don’t know who gave it permission to do so but it seems a little more intuitive.
This is slightly unrelated to the theme of the post. I’ll read the thread started by Jonathan Blackhall and add my impressions there.
Hey, look, the design team are giving us something different and explaining their reasoning!
Fantastic! Good work guys.
yuss, GNOME Shell could get tricky to manage with this, but it could become a nice marriage, too!
looking forward to first tests on my box :D
I’d like something like a “monitoring area” or panel, which includes several items of information:
1. notify-osd past messages. Right now, I’m running 9.04, planning to install 10.04 in the next couple of days, but AFA Karmic (in a VBox VM) is concerned, if I step away from the comp for a few mins, I miss any OSD notifications that might have popped up. There probably is a way to view past notifications (?) but I haven’t found it yet.
2. Trifurcation of notifications into ‘urgency levels’. Critical/security updates should be up and ‘in your face’. Less urgent updates – not. Apps that are just being chatty… can go into the third level. I’d like each level to have its own area in the monitoring area (described below).
3. Running system information that is useful to even new users, and can be customized/added to by power users. For new users, default could be something like simple CPU meters, a memory & swap meter, a network meter, battery meter, temperature monitors (most hardware now has the sensors, but it’s usually a manual effort to get them set up to monitor).
4. Mail/social network updates (icons, or maybe even photos of user’s contacts that are issuing status updates/whatever). This would include monitoring Evo or Thunderbird for new mail messages (yeah, some of us old-fashioned people prefer email.. sighh)
How would the monitoring area look? Well, call me old-hat if you will, but I really like gkrellm, and tend to set it up first thing after a new install. Widescreen monitors are becoming common; the docked gkrellm window probably won’t annoy people. Gkrellm displays much of the information above, as well as date/time, proc, uptime and HDD activity (by my config).
So something like gkrellm, with the trifurcated notification areas added at or near the top, docked to a vertical edge of the screen, themed to blend with the current Ubuntu theme, and eyecandy like transparency/shadows etc by Compiz, when it’s enabled. The larger unit areas in such a setup would afford a lot more screen area for urgent notifications — a 90x50px (approx, measured with screen ruler) unit of the monitor area flashing orange or red (critical level notification) would get way more user attention than the little icon in the old notification area. This scheme also exposes a lot more useful information to users. Of course, the appearance needs a makeover… for example, new users should see a “network” icon in the network display unit, not a label saying “eth0” :-/
Naturally, in contrast to gkrellm, mouse interaction with this area should be useful :-/ Hovering the pointer above a unit should display useful info: CPU meter: tooltip with `top` 3 or 5 processes hogging CPU; disk meter: likewise; social/email units: summary info of the communication – who from, subject line or truncated message text. Left-click on a unit should launch/show an app that handles that particular type of info — system monitor/email client/IM client etc.
I’ll leave double-clicks, right-clicks, middle-clicks etc to the interaction gurus – I just had to get this idea off my chest because it’s something I would really like.
Can we please get a messaging-menu icon that doesn’t look like “You’ve got mail!” ?
For those of us who used Eudora, back in the day will notice that the icons are almost identical and I believe this is a valid use-case. An empty mailbox (until needed) with a sing up when we have a message would be fine, or a black envelope. Just not a gray or a white envelope – it’s WAY too distracting.
Otherwise, solid design choices, imo.
I’ve written a couple of Java applications that sit in the “system tray”:
http://sourceforge.net/projects/wrldtimesystray
http://sourceforge.net/projects/stardatesystray
Each essentially sits as an icon in the tray area and display information either during a hover or single left click. A menu also pops up during a right click (which can kick off different functions).
How would such applications fit into this new paradigm as I don’t believe Java integrates directly with Gnome/KDE?
Well researched and written up as usual. Thank you for working on this and making our systems a little bit less black magic.
I truly hope that Gnome and particularly KDE can resist to this change, because of its complete lack of flexibility. If I read correctly:
1) indicators must go to the top right of the screen no possibility to change it.
2) indicators must be in a fixed order, no possibility to change it.
3) once indicators are in place, all applications using the system tray must be modified to work with indicators.
If Gnome and KDE accept this, margin for other distros to take different paths will be minimal and Ubuntu will actually end up imposing its choices on everybody. As a matter of fact there is already a push to do so by telling developers that they must stop relying on the system tray applets even before Gnome and KDE can take any decision about that.
A first point against the current suggestion for indicators is that on screens that are much wider than tall, to put things both on the top and the bottom of the screen is a very poor design choice. The gnome idea of having two panels, one at the top and one at the bottom of the screen was nice on the 4X3 screens that were used a few years ago, and can be nice today on phone screens that have a vertical form factor, but is not ok for the “panoramic” screens that computers and laptops get today.
Recently I always reconfigure gnome to use a single panel a la KDE, otherwise on 1024X600 screens there is not enough estate to vertically display anything. To have 2 20-pixel thick panels is to steal from applications 7% of your vertical space and screen area.
A second point is that maybe the reason why the “system tray” paradigm has sticked and the “notification area” has not is that people do not want a notification area. Maybe they exactly want a “system tray”, namely a single place to quickly check and access system or hardware related applications that typically live for the same amount of time as the session itself. It is not a substitute for minimization nor an inconsistent way to hide windows: such applications are not started as a window and then actively minimized or hidden. They are set up to start automatically and readily in the system tray form, something that is completely different from the very beginning. And no… the possibility to conceal things in the tray is not like “masking tape so you can cover up unwanted warning lights”. It is much more like the toolbox paradigm. Ideally one would like to have a toolbox with an infinitely wide opening, so that when you open it you can see all the tools. But the opening is limited in size, so what do you do? You put the tools that you use less on the bottom of the toolbox, so the ones you use more can be visible at the top.
Finally note that the main argument made against the system tray is that programmers have too much freedom to make the many applets inconsistent. Unfortunately, by the same lines one could say that the desktop must go because programmers have too much freedom to make the many applications inconsistent.
sorry, but your notification area looks bad, because you made it in that way. why do you use date, and weather there? just remove it. another thing is using empathy in that way – just waisting space, especialy if you are using pidgin. just remove all of that rubbish, and it will be usable.
look like this screenshot was made on purpose. I have no problem with notification area. please don’t repair something, that is not broken. like you changed buttons from right, to left.
I don’t use any of the indicator applets in ubuntu – for me they are useless implementation of something already implemented.
Why have another background application running and wasting memory just to show me the indicator-applet-session menu, when I can do the same actions via several .desktop files or the “System” menu?
Why dumping the “system tray”, when it was around for many years and there are a lot of users (and developers) who are familiar with it?
Just because your design team thinks this is logical, does not mean it really is.
Maybe it’s time for me to switch to another distro.
I feel more and more annoyed by ubuntu developers, especially since 9.10.
Some mockups of what you’re describing would be really nice…
I really hate the idea of notifying for updates. Chrome OS threatens to do transparent updates. Hallelujah.
Good riddance to annoying notifications. DND for me.
I like innovations. When I see them. But honestly, is there any here? What you’re trying to implement, in my humble view, is already there. It has always been, but with a different name: it’s called “Applications”. And, surprisingly, it’s already a menu.
You may argue you’re trying to move that menu from left to right (recalls painful memories of buttons moving around), and turn it into a new notification system organised in categories unfolded along the panel length. But, the Applications menu is already organised in a clean list of categories, isn’t it? Ultimately, if “the pattern here is that everything is becoming a menu”, and “further, everything is becoming a single set of menus”, then, further still, we might also be justified to expect even a single category button that, located entirely on the right, sits there as the final container for all the set of menus/pre-ordered categories. That would be actually nice, wouldn’t it? Well, surprise-surprise, it already exists, it sits on the left, and is called “Applications” menu.
So, instead of just “being different” for the hell of it, why not trying to improve on something that has always been there and which users are accustomed too? Following your original intentions, for instance, you could implement everything you envisioned directly in the Applications menu, let it flash in the same fashion minimised windows in the task bar do when they call for attention, and when you click on it, then the category will flash and so on, until you reach the app notifying you. Applications running may be indicated in bold, or by the “play” symbol next to them, while others could just stay there greyed out.
I don’t know, it may not be the brightest idea, but the pattern I see here is replicating uselessly features satisfactorily employed by users for years. If programmes can be started directly from their dedicated indicators, why would anyone be bothered to use the “old-fashion” menu? What will be the purpose of the Applications menu, then? Just to use your own words, will you “nuke the entire site from orbit” again, just because it’s the only way to be sure?
i think it´s really usefull for thing like instant messaging programs,it would be annoying to have it on the taskbar, unless there were no titles in the task bar
This is a direct copy of my Ubuntu Forums post.
I like what they’re doing with all the new menus, but they seem to be threatening to get rid of the systray altogether and break thousands of working, useful applications! This is a very heavy-handed, Apple-like move and I had honestly come to expect better from them. I certainly hope I’m not understanding them correctly. It’s true that if anyone comes up with an alternative to the systray, I will be the first in line. But any solution *must* have some kind of legacy support for old programs and protocols.
This is not like system software, such as X servers, drivers, and kernels. When you are dealing with non-system software, i.e. applications, compatibility becomes important. I know that the systray is visually offensive and could probably use some depreciation, but you need to be realistic. For example, I hate the Tk look-and-feel as much as the next guy, but I still keep it installed because I use programs that need it. And I still write code for it because it is *the* cross-platform toolkit for Python.
As far as notifications go, Notify-OSD was a good effort but it’s really not an improvement. It really is just as annoying as it looks at first. I’ve never really learned to like it. One of my programming projects in the future will be a dummy daemon which implements the freedesktop notification protocol but, by default, sends everything to the bit-bucket. It will also be configurable so you can have totally customized actions and methods of display, via shell scripts. Personally, I think this is going to be the best way to do this kind of thing.
Finally, I hope Notify-OSD and these new menus will be developed separately from Ubuntu itself, and effort should be made to reach out to packagers for other distros.
I actually like this, I’m not a fan at all of the system tray abuse that’s currently happening, but unfortunately for a lot of apps it’s the only way to quickly control some actions.
I am having trouble understanding how all app functionality can fit into these predefined containers. For example I use exaile music player, it closes to the notification area, and when I right-click the icon it shows me a nice menu that includes the standard music player actions (play, pause, etc.) – but also a nifty little utility that allows me to rate the current playing song on 5 stars without having to open the full program. It’s one of the main reasons I chose exaile over other media players.
Will apps be able to innovate like this using the new system? If not, you would effectively be eliminating a very important source of value and differentiation. These applets are very much part of the main interfaces and functionality of all apps. It would be akin to forcing all media player applications to fit into a new MusicAppShell where the library MUST be on the left, the player control MUST must provide a library saying that we no longer want media player apps to use all these “inconsistent” interfaces with progress bars in different places, different library management and so on.
Oops, submitted by accident, the last line should instead read:
It would be akin to saying “we hate the inconsistency between how media player apps are laid out, from now on, all media apps will have to fit into our new ‘Music Shell’ interface with the library on the left, the player on the bottom…”
If these were provided as optional applets that apps can code to, that could be great. People and developers will naturally gravitate towards them, because, seemingly, they add value. But others who don’t want to, don’t need to, or have good reason not to, should still have the choice to be pigeon-holed into it.
I have an idea for apps to be properly hidden without taking much space on the taskbar, and a pretty simple way to be implemented. Why not add a right click action to the “close” button, just like the maximize button has now, to have a different behavior when pressed. This way, if you want to “tray” your app, right click on the close button, and it will go at the beggining of the taskbar as an icon only. This way, you can have apps with different level of visibility. When you need apps in the taskbar to be fast and easily visible, minimize it, with the normal behavior and representation we have now. If you just want it to be there for a long while, but don’t really need to click it a lot, “right-close” it, to “iconify” it.
Just my 2 cents
A comment regarding:
“Where a notification area icon was being used mainly as a substitute for minimizing, the window should just minimize instead.”
As you say yourself, OS’s basically started out this way, and throughout the years, people realized that it makes more sense for some stuff to be tucked away – who are you to say they are wrong? I HATE, for example, that on my Win7 desktop I can’t minimize media player to the tray. It doesn’t belong in the task bar FOR ME. I am not saying people who like i in the task bar are wrong, just that it is a completely subjective call, and therefore the choice should be there to do either. A “messy” systray to you, can be considered perfectly organized by someone else.
Lelamal: Your approach actually seems pretty interesting. The only grip I see is lurking around the menu to find the notifying app. I would add a “zone” to the app menu with, when needed, would show the needed app. Anyway, I don’t see notifications that necessary at all, as the taskbar normally notifies me when something needs attention. I think this problem is originated from apps minimized to the systray, but then, I’ve already apported my thoughts about that in my previous post.
Strange. The only notification icons I have that I didn’t explicitly ask for are ones baked into core Ubuntu functionality: volume, network manager, and ibus. These are also the only ones I CAN’T REMOVE.
The others are:
compiz-icon, which I use when playing games
pidgin, which I like for the status and hiding the buddy list
whatpulse, which just flickers as I type and glows when it updates
gnome-do, which I only have around in case my WM crashes and I can’t otherwise run anything
parcellite, which I rarely use but which is only useful via icon
All of these things have useful menu functionality for me.
Also, minimizing windows when I have multiple desktops means that now I either need a “home” desktop for all these windows, or to have them appear on every desktop. Awesome.
There’s a lot of blame-spreading and UI disruption going on here when, at least on my screen, Ubuntu itself is the only thing causing a problem.