Notifisation

Fire Notifier

Listen to this.

Launchpad bug 124326 requests a new titlebar button which minimises an application to the notification area rather than ordinary minimisation. Mostly this is currently done with the close button on the apps which support it, but some people feel it would be cleaner if these two functions were distinct. This action has been given the name “iconification” by some, but since this is the name the X specification gives to what we now call minimisation, I propose the ugly word “notifisation”.

There are four problems with this idea.

  1. Adding new titlebar buttons is always problematic for reasons given earlier.
  2. The EWMH specification is going to have to include a way to tell which apps may be notifised, and a way for the WM to tell an app to notifise itself.  This is going to require arguing out on wm-spec-list.  In itself, this is not a major obstacle, but it’s important to be aware of.
  3. It is unclear what the real difference between minimisation and notifisation is in practice.  And if there is one, why shouldn’t all apps be notifisable?
  4. Using the notification area for things other than ephemeral notifications– that is, using it as a cheap way to make panel applets– is contrary to the Human Interface Guidelines.  Perhaps the HIG is wrong, but then we need careful thought before we give the practice a stamp of approval by enshrining it in the EWMH.  Besides, there is talk of enforcing notification ephemerality.

Photo by The Joy of the Mundane, cc-by-nc.

Published by

Thomas Thurman

Mostly themes, triaging, and patch review.

15 thoughts on “Notifisation”

  1. “Using the notification area for things other than ephemeral notifications– that is, using it as a cheap way to make panel applets– is contrary to the Human Interface Guidelines.”

    That issue is really irrelevant to this one. Since the notification area is a major sticking point for some people, just pretend that we’re only talking about panel applets. The functionality is the same whether you’re HIG-complaint or not.

  2. I believe “notifisation” is a thing people have come to expect because many applications on Windows do it; many applications on Windows do it because managing a large number of open windows using the taskbar is frustrating, and it’s helpful to be able to shunt some lesser applications across into the notification area where they take up less room (in XP and above they get automatically hidden, taking up even less room).

    Another factor that makes ‘notifisation’ popular in Linux is that it’s the only way to show status in a way that works on both KDE and GNOME. There’s a few applications I’d much prefer to have as GNOME panel applets (hello, Transmission and Quod Libet!) that only support notification-area icons for cross-desktop reasons.

    I think in an ideal world there would be a nice organised way to deal with long-running background services (maybe something like the MacOS Classic ‘control strip’), distinct from notifications and minimised windows, but by now there may be such a critical mass of people expecting Windows-like behaviour that it’s not feasible to do it any other way.

  3. This feature is not needed in Metacity, it is responsibility of applications to provide a tray interface and minimize to the tray when the close button is pressed. A “go to tray” icon could be demanded to distinguish from closing and iconizing to the tray.

    There is a tool that puts an application in the tray: http://alltray.sourceforge.net/

    I agree that it could be very helpfull to have some applications in the tray but they should provide an interface that lets them to be used from the tray, not just be minimized to the tray. I’m talking about functions like empathy/gaim, liferea, banshee, brasero… To promote this behavior there should be a library or an extension to gtk+ providing helpers to do so.

    Regards,

    Pedro

  4. It is interesting that Windows 7 downplays the system tray and essentially molds its functionality into the taskbar. I’m not saying that this is the way forward, but it indicates that the distinction between the two was somewhat arbitrary and a usability hindrance.

    I’m not sure the HIG are wrong on this one. Applications abuse the notification panel mainly due to windows-influence and because there is no cross-WM applet spec. As the previous poster said, Transmission, Deluge, Gaim, Banshee should actually be applets instead of notification icons.

    Maybe the real solution is to write and implement such a spec?

  5. “As the previous poster said, Transmission, Deluge, Gaim, Banshee should actually be applets instead of notification icons.”

    Again, this is irrelevant. Regardless of whether they are implemented as applets or notification area icons, they still have an “icon” state that is different from “closed” and “minimized”. How do we manage all four of these states?

  6. Oh $god, please no. I like the current state of things as most apps that behave this way can be configured not to fsck with my notification area. If you stick the feature in Metacity, apps will learn to expect it. I don’t want to see GNOME get an “unused notification icons” arrow next to the notification area like you do in Windows XP. I actually want to use the tray for notifications.

  7. “Again, this is irrelevant. Regardless of whether they are implemented as applets or notification area icons, they still have an “icon” state that is different from “closed” and “minimized”. How do we manage all four of these states?”

    One possibility: merge the “minimized” and “icon” states into a more advanced taskbar, taking hints from the Avant Window Navigator (or OSX dock) and Windows 7 taskbar.

    Another: implement a cross-platform spec for panel applets (so you don’t have to (ab)use the notification panel for this functionality).

    A third: change the HIG to remove the line between notifications and applets, effectively turning the notification panel into a windows-like system tray.

    From these, I believe #2 tackles the real issue. #1 would be nice to have, but requires *significant* interaction testing. #3 (what we currently have) is the worst possible solution (a usability nightmare, which is why Microsoft turned away from that in Windows 7.)

  8. Stephen:

    For that matter, reducing the task bar to bare icons would be enough of a solution for many users. Just place iconified windows as bare icons (no title on the button) aligned to the right side of the task bar applet.

  9. On second thought, what makes “iconify” so special? It’s just sticky + minimize but many users seem to think that minimize sucks. Just make the above suggestion default for minimized windows and everyone should be happy.

  10. “For that matter, reducing the task bar to bare icons would be enough of a solution for many users. Just place iconified windows as bare icons (no title on the button) aligned to the right side of the task bar applet.”

    How is this any different from an applet? You can place an icon-style applet anywhere you want, including next to the window list applet.

    The issue under discussion is how to get the window into this icon applet form. Currently some apps let you do it by pressing the Close button, some by pressing the Minimize button, and some by pressing the applet icon itself. I don’t think any of these is the correct way to do it.

    The proposal is to add a control in the window itself that lets you command the window into icon form.

    Minimized: Window is active, but not displayed on screen. Shows up in Window List and Alt+Tab.

    “Iconified”: Window is not present at all, app is in a daemon-like state, does not show up in window list or Alt+Tab

  11. Not all applications should support to be minimized in/to the tray so a new button in the window manager is not a point. A good approach is to provide a place for application dependant icons so it can add actions to the window and it will receive the events when those icons are clicked.

    For minimizing to the tray, an application should provide two view/interfaces: [Window] and [Icon] so the window manager can use the [Window] view and the tray can use the [Icon] view. With this approach, those applications providing the two intrfaces can be automatically minimized to the tray, and those that don’t provide it are minimized to the task-bar. This behavior should be implemented in the graphic toolkit (GTK, QT…), not the window manager.

    Regards,

    Pedro

  12. “Not all applications should support to be minimized in/to the tray so a new button in the window manager is not a point.”

    No one’s asking for all apps to go into icon mode, and no one’s asking for a new button that exists in all windows. The button would only be present with windows that support the functionality:

    http://launchpadlibrarian.net/16937009/4th%20button%20mockup.png

    If there were really no difference between minimized mode and icon mode, apps wouldn’t support both… but they do.

  13. This is a bad idea. The notification-area should only be for applications who give out notifications, like network-manager, power-manager and applications which you normally not close but runs in the background still doing their thing like a music-player, instant-messenger, voip, mail-application, bittorrent client.

    For them it is natural that the close button operates as a close of window but not of the application. Maybe changing the X for these applications to something different is a option.

Leave a Reply

Your email address will not be published. Required fields are marked *

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.