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.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

11 thoughts on “Libnotifytastic”

  1. 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.

  3. 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”

  5. 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. 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.

  8. 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.

  10. 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.

  11. New screenshot uploaded. In the worst case scenario (system restart required, messages present, critical updates remain) you’ll see two icons. In normal usage you’re see one icon where the most important thing is displayed and the others suppressed.

    I agree the messages are not useful for most users, but some people need to see the output. Debian users in particular need to be able to see what configuration files were changed, as sometimes an automatic merge will not be performed. If something doesn’t work correctly, and the user starts to debug, they do need to see the messages.

    Cheers for the feedback, hopefully we can keep refining the design until we’ve got something that keeps all of you happy :-)

Comments are closed.