Re: application indicators

[Matthew Paul Thomas <mpt postinbox com>]

Nathaniel McCallum wrote on 19/02/10 07:39:
>...
> I'd like to take the opportunity to talk about apps that may not fit
> the AppInd model.

We have two basic goals here in replacing the notification area:

1.  Make interaction with panel items more consistent. Clean up the
    swamp where some items behave like buttons, some disappear when you
    click them, some open menus on left click, some open menus on right
    click, none of the items opening menus highlight like real menu
    titles do, etc. Achieving this is relatively easy: just make
    everything a menu.

2.  Reduce the number of panel items, period. Establish a culture where
    developers choose to add a panel item less often than they do now.
    Achieving this is harder, especially in the short term -- because if
    we succeed, some existing programs that have been in the panel won't
    be there any more. Some of those panel items might even have been
    pretty handy. But the overall goal is bigger than they are.

> I agree this is an area of much needed clean-up, so I appreciate the
> work. Unfortunately, I'm also the developer of Zapplet
> (http://sourceforge.net/projects/zapplet/) which I suspect doesn't
> cleanly fit the AppInd model.  Zapplet provides notifications for
> Zenoss (http://www.zenoss.com <http://www.zenoss.com/>) events.  When
> an event shows up in Zenoss, Zapplet displays a notification for this
> server.  Clicking on the notification icon brings up a window near the
> notification icon where someone can view all outstanding events and
> modify them easily without having to go to a browser.  See the
> attached photo for an example of the status icon.  See
> https://sourceforge.net/project/screenshots.php?group_id=244523 for
> more screenshots.

You're right: this does not fit the everything-is-a-menu model. It looks
like a window that happens to be hanging off the panel. ;-)

> Currently we generate a StatusIcon on the fly by rendering into a
> pixbuf.  This icon contains the color of the highest event severity
> and the number of events of this severity.  Using the AppInd model, we
> would be required to generate roughly 5k icons just for this display
> (5 status colors x numbers 0-999).

Even if Zapplet shouldn't be in the panel, there are other items (e.g.
keyboard layout) that need to use text in their titles. Perhaps that
should be added to the API.

> We also have the problem of event storms (100s of events).  Rendering
> events in a TreeView allows us to show lots of data in an easy,
> scrollable way.  Using the AppInd model, we'd be required to have a
> menu, which is entirely unwieldy for events as a whole.  This is true
> for a number of reasons:
>   1. Menus with 100s of rows (events) suck
>   2. Events show a bunch of data (severity, count, hostname,
> component, summary, first time, last time, etc).  I can't really fit
> this crucial info in a single menu item.
>   3. With a menu I can't perform actions on multiple events
> simultaneously.  This is a critical feature.
>   4. Menu's can't perform sorting (for instance if I wanted to sort
> based on event time)

Yeah, that really would work better as a window than as a menu. We're
experimenting with adding simple controls to menus (for example, Ubuntu
Lucid's new sound menu has an embedded slider, and the "Me menu" has an
embedded text field), but we almost certainly wouldn't add something as
complex as a treeview.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/