I think this aplication can be useful. It as other have described needs a better description. I tought i would have the programs loading to this instead. But know now that is not entierly true.

Also.. to open it should be possible to swipe the stylo/finger from outside screen bottom up to open. (like cursor mode in microB)

Loaded without an issue, Showed up in the system tray after installation. No need to reboot. However its not clear what its function is. Also bug-tracker is missing.

Showed up in the system tray after installation. No need for reboot. However, it is not clear what its function is. Also no bug-tracker

• Bug-tracker missing
• as others have mentioned, no info about the 'reboot' requirement
• -1

Needs a bugtracker, a better description and a notice telling the user that a restart is required should be also added.

Needing restart after installation will make some users uninstall it before attempt a restart. Better description is also a must. Other then that it works as expected. Although commonly used, I don't think system tray fits at all in Fremantle interface. It's a quick and dirty solution for quick porting of course, but to be honest, I personally consider it just a necessary evil in GNOME and would consider it annoying on Fremantle.

BTW I've not encountered Uwe's bug, I've not rebooted and all seems to work well.

It has taken a lot for me to understand how this works, but finally all is clear. ;) Well, there should be a sort of list where you can read which programs use the notification area. Until now, I only know Pidgin, and I even don't like how it works with it.

However, I can understand this could be useful for others: it just needs a better (and exhaustive) description. I've never used a tablet before, so I didn't know what a notification area is.

I think there needs a bit more about what notifications are shown in the system tray..

There should be a hint that a reboot is necessary after the installation. When I installed this other items in the status area disappear. Also the notification panel itself does not came up until I did a reboot.

I like the idea but to be honest the practical implementation isn't that nice. Either you should wrap tray icons somehow and arrange them like status plugins or put them somewhere else on the screen. In my opinion something inside a menu defeats the purpose of a tray icon.

I have changed my opinion about user/ visiblity and being a depency of other packages. Because statusmenu widgets cannot be disabled (except by uninstalling), forcing installation of this package for example with pidgin would be bad. I for example wouldn't like systray to take one spot from statusmenu, but would still like to use pidgin for IRC.

So only better description is needed.

@Gabriel: this is not the point to pontificate on Fremantle Hildon Desktop design choices, so you are - in effect - wasting your breath there. maemo-developers might be more constructive.

As for "users will have to find [this] themselves" this is why it is critical for there to be a good description here, and possibly a reference to it in Pidgin's too.

If this package is only supposed to be a dependency of other apps, please don't put it into the user/* category.

I don't believe we have any mechanism of revealing to the user if a given package A /recommends/ or /suggests/ a package B, right? Thus, the user pretty much has to figure out on her own that she needs this package.

In GNOME, the system tray is a gnome-panel plugin shipped with the GNOME panel package, and configured by most distributions to be present on the GNOME panel by default.

In Windows, users have a system tray whether they like it or not.

For applications originating in the desktop world, this means that there's a good chance there'll be a system tray present. Having one in Maemo will make porting such applications easier. Too bad it's not turned on by default.

OK, I can change the description.

I believe that the package should be a dependency only for those packages that absolutely fail to work without a system tray. Pidgin will work without a system tray, but, for example, closing the buddy list window will quit Pidgin. Not good, especially if you're used to Pidgin on the desktop, where it has a system tray icon.

The system tray should never have been a package on its own, but during the development of Fremantle nobody thought about providing a place for system tray icons. In Diablo and Chinook, the developer of hildon-desktop was kind enough to build this fd.o standard in as an alternative to status area plugins.

In Fremantle, this standard has been ignored completely. In fact, I've had some success recently making a floating window into a system tray, which could address the basic requirement for a system tray - a requirement that's missing from hildon-systray-0.0.1: That system tray icons should always be visible /and/ clickable. Unfortunately, such a floating window would interfere with everything else on the desktop. This has simply not been considered.

Thus, I am faced with having to try different ways of implementing this standard, while dodging the existing desktop. But hey, I want to see system tray icons in Fremantle, so I'll keep trying. Hmmm ... I wonder ... what about hinting the window as a panel window ....

OK, I can change the description.

I believe that the package should be a dependency only for those packages that absolutely fail to work without a system tray. Pidgin will work without a system tray, but, for example, closing the buddy list window will quit Pidgin. Not good, especially if you're used to Pidgin on the desktop, where it has a system tray icon.

The system tray should never have been a package on its own, but during the development of Fremantle nobody thought about providing a place for system tray icons. In Diablo and Chinook, the developer of hildon-desktop was kind enough to build this fd.o standard in as an alternative to status area plugins.

In Fremantle, this standard has been ignored completely. In fact, I've had some success recently making a floating window into a system tray, which could address the basic requirement for a system tray - a requirement that's missing from hildon-systray-0.0.1: That system tray icons should always be visible /and/ clickable. Unfortunately, such a floating window would interfere with everything else on the desktop. This has simply not been considered.

Thus, I am faced with having to try different ways of implementing this standard, while dodging the existing desktop. But hey, I want to see system tray icons in Fremantle, so I'll keep trying. Hmmm ... I wonder ... what about hinting the window as a panel window ....

@Gabriel: the current description is not suitable for end-users. Repeating "'notification area' and 'system tray' are standard terms" is not a justification; as they are not standard terms on Maemo. There needs to be an explanation of WHAT this package does and WHY a user would like to install it.

Perhaps something more like: "Provide a centralised notification tray. This allows applications to present notifications to the user in the statusbar using freedesktop.org standards. It is not intended to be directly installed by end-users, but instead pulled in as a dependency by applications such as Pidgin."

On that last point, I agree with Mikko - if this is to be used by other apps, why does it need to be its own installable application?

The name "Notification Area" is from GNOME, and the name "System Tray" is familiar to Windows users. That's why I chose these names. I even stole the package icon from GNOME.

Well, Stskeeps seems to like that this package is available, because Mer contains NetworkManager, whose nm-applet uses a systray icon. Maemo 5 has Pidgin, which also has systray support. Of course, I'm the guy who maintains Pidgin, so make what you will of that.

The app name suggests that it provides a mechanism for Notification messages to be displayed to the user. But from your comment, it appears that it only displays icons. Wouldn't it then be akin to a task switcher?

Are there any apps out there that use this? It would be nice to see how the Notification Area behaves when used by a program? Does it only show icons or also some text?

The idea here is that the system tray is already available on every major desktop and there's a standard implementation of it in X11. Diablo implemented this. Fremantle does not. So, I figure it's best to provide this mechanism in Fremantle as well. I hope more apps will make use of it.

I guess the assumption is that some future apps will be ported to use a Notification-Area/System-Tray. In that case it is okay.

Wouldn't using the standard notification mechanism (Missed-Call, New-Message) be a better choice?

@Andre Klapper: That's exactly right. That's all it does. Now, when you install a program that wants to place an icon in the system tray, as soon as you run that program, the "Notification Area" dialog comes up and you will see the program's icon appear in the notification area.

I simply don't understand how it works. Installed it, got the button in the statusbar popup, clicked it, got a "notification area" window at the bottom of the screen which blocks the rest of the UI. Clicking somewhere else makes it disappear again. I'm confused.

I thought the description was pretty obvious. Windows has a "System Tray" (where the volume applet, system monitor, Pidgin, and a pile of other things go). GNOME (and KDE probably too) has a "Notification Area" where the volume control, NetworkManager applet, Pidgin, et. al, go. In Chinook and Diablo the notification area functionality was handle by the status area. In Fremantle it is not.

Of course I intended the notification area primarily to be used with Pidgin. Still, having a notification area will help people porting those apps that make use of it.

On a different note, I must admit that the implementation could be better. The whole point of the notification area is to always be visible. In addition, the icons placed therein are interactive, unlike the icons in the Fremantle status area. Interactive means that you can left- and right-click on them.

Thus, IMO the best implementation would be as a home applet. The current source package contains such an implementation, but it is disabled at configure time because of MB#6024.

I agree with Andrew.

I installed it but cannot see any purpose/function for it. Is this usable as a standalone applet or is supposed to be used with other apps? If it requires other apps, should this just be a depency for them and remove this from user/ category?

Needs a better description. "A notification area" doesn't give any information above the package name.

Needs a better description. "A notification area" doesn't give any information above the package name.