Libnotifytastic

Every now and then, somebody chastises me for abusing libnotify to display something to to user. I guess it’s easier to just spam a fire-and-forget notification that thinking about how to present the data properly to the user.

A classic example is the messages the PackageKit daemon passes to the client program. These messages are packets of data containing the message type and any specific details. An example of this might be a message telling you that a config file has been automatically merged, or that a non-critical error has been worked around. These also tell you when things like prelink fail, which is a pain when you’re running something like rawhide. These messages arrive as the transaction is running, and are designed to be shown to the user at the end of the transaction and not get in the way.

Now, due to some “just get it working as quickly as possible” design standards, I used libnotify to display these to the user. Bad me. My excuse is that I’ve been very busy with other stuff, and life seemed to get in the way over Christmas.

Now I guess the right way to show the user this sort of data is for an icon to appear, something like this:

When the icon is clicked, something like this would appear:


So comments and feedback appreciated. No code in git yet, until it looks nicer. Thanks.

11 responses to “Libnotifytastic”

  1. Patrys

    I seriously hope this is a joke :)

    Why would it need two icons? And who is supposed to read this if it does not pop up?

    What we really need is a better version of notification-daemon with history browser and urgency filter, not yet another notification system.

  2. rawsausage

    Spamming the user with irrelevant stuff the user does not have to ever be aware of.

  3. Vadim P.

    Yeah I hope this is a joke too. “oh, 5 messages eh?” *opens the dialog* “um… okay, now what? I guess I just press this ‘Close’ button and get on with my wasted 2 minutes”

  4. mike

    Is PackageKit using more than one TrayIcon?

    pls not ;)

  5. Joe Buck

    And the “solution” you suggest mixes together things that the user might care about, to things that the user should not care about and can’t do anything about. Bad metadata? Load it again from a different mirror and don’t bug the user. New packages available? Cool, but why provide that information as individual messages mixed in with messages the user doesn’t care about? Configuration files were changed? What is the non-expert supposed to do about that?

  6. Dylan McCall

    It would be nice if accessing the notification area was done /with/ libnotify, instead of having two differnent APIs intended for the exact same concept that we have to fight over.

  7. Achim

    I think the idea is not bad.

    It could fit very well to the concept that Mark proposed.
    http://www.markshuttleworth.com/archives/253

    Regards
    Achim

  8. twilightomni

    Aside from the possible question of duplicated functionality…

    With this “event viewer”, PackageKit is beginning to show the dark interiors of the package management system that it was trying to shield users from in the first place.

    Use cases! The _only_ role type that these messages would be useful for is a competent system administrator — which isn’t really one of your user profiles. Even the “hobbyist computer whiz” will find this dumping-ground obtuse and a buzzword blackbox.

    Handle with care for what messages are revealed. PackageKit would ideally be able to probe the user for assistance with any repository and metadata problems in a way that allows you to heal the system, with a minimum of deluging-the-user-with-complexity. That would probably mean you would never explicitly see the term “invalid metadata for [really-weird-name-here] repository”. :)

    Of course that can all be polished, and I understand you’re working on the interaction metaphor itself, as opposed to the content.

  9. Adam Petaccia

    Why not just use the system log? If they’re nonfatal then most users wont care, but a sysadmin can use Gnome’s log viewer to check it out.

  10. Patrys

    Adam:

    That’s exactly what I had in mind. An audit log similar to what Windows does with configurable verbosity for an admin.

    No hacky details for users (like mirror errors or config merges). They don’t care. And even if they did, they probably don’t have enough skill and – most importantly – privileges to even look at said config file.

    Let’s keep the old notifications for stuff like “new updates available” or “packages installed” but I see no point in developing a whole new notification system just to strike down upon the innocent user with great vengeance.

Bad Behavior has blocked 2769 access attempts in the last 7 days.