[packagekit] gnome-packagekit flames^Wreview

[Richard Hughes]

On Sun, 2007-12-30 at 22:44 -0500, David Zeuthen wrote:
> So I just tried PackageKit 0.1.5 on Fedora; here are some more comments.
> Actually when reading it it's more like a flame or rant. Nothing
> personal, hope it's useful feedback.

Well, I took it pretty personally, but I'll address things one by one.
You have to bear in mind that I'm doing this totally in my limited free
time, and rely on other people to add requested features or fix my
fuckups - of which I admit there will be many.

>  o  Would be useful to have a date in the NEWS file; I guess, judging
>     from the timestamp of the file, 0.1.5 was released 12/21 2007.

I've added this.

>  o  The RPM package names on Fedora are just plain confusing. I mean
> 
>     - PackageKit
>     - gnome-packagekit
> 
>     Come on! By the normal way things are named, on Fedora, you should
>     use PackageKit-gnome instead. I guess it's because of bad naming
>     policy of upstream packages? Things like these are just annoying.

Annoying to you, but this make sense to me. Most GNOME packages are
gnome-foo i.e. gnome-power-manager, gnome-session, gnome-screensaver.
gnome-packagekit is a GNOME client for PackageKit, it is not the gnome
integration bits for PackageKit. It matches better with upstream
convention, so that the QT frontend and library is called QPackageKit,
not PackageKit-qt.

Anyway, I don't think this is an important point to debate about; we
have more important things to fix lower down this mail.

>  o  Maybe this is just a Fedora problem but the latest gnome-packagekit
>     package is 0.1.4 in Rawhide. Annoying. Oh, wait, it's in Koji
> 
>     http://koji.fedoraproject.org/koji/buildinfo?buildID=29487
> 
>     since someone else fixed the build. Annoying too; what if there
>     were ABI changes?

ABI and API changes are always mentioned in NEWS - and recently we've
been rather good at keeping to functional API and ABI.

>  o  You should probably do something like sending a HUP signal
>     to both the PackageKit daemon and the pk-update-icon daemon
>     to make them reload on package upgrades

Well, packagekitd will auto-quit if it's doing nothing, so I think we
just have to wait for that. I'm not sure how we could make
pk-update-icon restart (on all desktops) in a sane way - maybe we could
give a DBUS signal or something. Is there a sane way to detect "hey, my
binary has changed"?

>  o  There's an "Add/Remove Software" in the System->Administration
>     menu. This menu item should be in the bottom of the Applications
>     menu instead (just like pirut).

Well, I would argue that installing and removing software /is/ system
administration rather than anything special enough to get a menu root
position. What was the rationale to making pirut a root level menu item?
Surely we should just reserve that spot for the simple "application
chooser" that we have yet to built.

>  o  I have two items in the Applications->System Tools menu
> 
>     - Software Transaction Viewer
>     - Software Update Viewer
> 
>     which is just confusing. By messing around with it a bit, it looks
>     like the latter is what I want to use for updating the system. 

Well, the Transaction viewer lets you see what was updated or installed
in previous transactions. This is important as updates are now being
done in the background with no user UI or notification, and you might
want to see what was updated. The name does suck. What about "Software
History" - better ideas welcome.

The Update Viewer is only useful if you turn off automatic updates, and
need to apply them manually. It's only other purpose is to show you info
about the updates, although this doesn't work for me right now as I
don't think rawhide has the needed metadata from bohdi.

>     Oh, why did I even go searching for this item? Because I knew, by	
>     reading the daily rawhide reports there were updates, but... I
>     didn't automatically get a "there are updates available notication
>     icon when I resumed my machine after not using it for a couple of
>     days. 

Hmm. I think the fact you suspended and resumed is the reason why the
timeout wasn't triggered. We probably need to add a hook into pm-utils
to poke PackageKit when we do this so it can do its checks then. I've
added this to TODO.

>     Neither did I get it when I manually update the PackageKit packages
>     (since I wanted to try out an update via PackageKit instead of yum.)

Updating PackageKit in PackageKit is unknown waters. I've yet to test
that properly.

>     So this is just pretty confusing. Suggestions
> 
>     - kill the icon for the "Software Transaction Viewer completely" and
>       make the functionality available via a button or something in the
>       "Software Update Viewer".

What, make it launch from a button like "Past Transactions"?

>     - I'm not a native speaker but I'm pretty sure "Software Update
>       Viewer" is a pretty terribly name for what it does. 

Hmm. Valid.

>       Also, I'm pretty sure it shouldn't be in the Applications->System
>       Tools menu. Suggest to use a verb instead (it is really an action
>       and not a tool) and place it in the System menu. E.g. have a
>       "Update this system" right next to the "Lock Screen", "Log
>       Out davidz" and "Suspend System" items. 

Well, the point is that normal users won't ever have to use this tool as
the updates will just be done automatically.

>       For bonus points, make the icon in said menu reflect the current
>       state of the system e.g.
> 
>       - Green: system is updated
>       - Orange: updates available
>       - Red: security updates available
> 
>       You probably want to talk to GNOME upstream to make it easy to do
>       such menu items via e.g. desktop files and whatnot.

I think the icon name is hardcoded in the desktop file.

>  o  OK, so now I have the latest PackageKit and gnome-packagekit (and
>     am still annoying by the naming conventions). Let's go update my
>     system. So I go into Applications->System Tools and select 
>     "Software Update Viewer". It spins for a while (but not too long
>     and that is alleviated by a progress so that's fine). I am now
>     greeted by this window
> 
>     http://people.freedesktop.org/~david/Screenshot-Software%20Update%
> 20Viewer-1.png
> 
>     There are several issues here
> 
>     - What does the "Refresh" button do and why would I need to refresh
>       something? In the unlikely event that there are suddenly newer
>       updates while I have this window open it should just automatically
>       update itself.

It does, a refresh from PackageKit suggests to the session application
that it might like to get the new data and update the UI. The refresh
button lets you ask the daemon to drop all caches and get the new
metadata, like if you've just updated a local repo. Maybe we can punt
this button or give it a better name.

>     - I think I know what "Close" and "Apply" means here but I think it
>       would be much clearer if you called them "Cancel" and "Update
>       System".

Good point, I've done this.

>  Also, to please the HIG nazis and make it easier on the
>       eyes, move the Help button so it's aligned on the left, further
>       away from the action buttons, e.g.
> 
>          [Help]               [Cancel] [Update System]

Do I have to split these up in an hbox for this or is it button box
hint?

>       Also, nothing happens when I press [Help]. Maybe you don't have
>       comprehensive Yelp-docs yet, but then please do avoid showing a
>       help button if it doesn't do anything...

Valid point. I've made it non-sensitive until we have a sensible yelp
file.

>    -  The visual metaphor for the orange icons is not clear. Sure, they
>       look pretty and all but how am I supposed to know what that orange
>       icon means in terms of "Severity"? Suggestion; use a smaller icon
>       and include text; e.g. for example
> 
>       [Icon] Bug fix  |  eel2-2.21.1-1.fc9 (i386)
>                          Eazel Extensions Library
>       [Icon] Security |  kernel-2.6.24-1.fc9 (i386)
>                          The core of the Linux OS

Well, we don't know much about the update. We know if it's a low,
normal, high or security update - but I think the yum backend considers
them all "normal".

>    -  It would be useful to know how many updates there are in the
>       batch and how much time it would take to apply them. So suggest
>       to include a textual element in the top explaining to the user
>       what is going on (more on that later)

Like a summary at the top?, like:

[ security icon ] 2 security updates
[ low prio icon ] 3 low priority updates

>    -  It looks like a list I can click on (I know this because I know
>       about GTK+ but I'm sure my mom would know it) so I go ahead and
>       click. Then I get this
> 
>       http://people.freedesktop.org/~david/Screenshot-Software%20Update%
> 20Viewer.png
> 
>       Yikes, suddenly this grey goo appeared and my list is now much
>       smaller. The wording is bad and confusing too (more on suggestions
>       later). Also, the "Update this package now" just gets in my way;
>       what I [1] really want is to cherry pick updates. With the way
>       things work right now, I'd have to launch "Software Update Viewer"
>       multiple times and queue up dates. Talk about software punching
>       you in the face.

Well, we can't just cherry pick updates - I've explained on the list a
few weeks ago why this is very difficult and bad thing to do; you are
making the user work around the repository brokenness. It's better to
let the software work around it in a clever way like I can do with "yum
--skip-broken update"

>       Also, what I (see [1] again) really want is to see what the hell
>       changed with the updated package compared to the one I already
>       have installed, e.g.
> 
>       - You want to display Bodhi style advisory information [2]; you
>         perhaps already have this... but what happens if I'm two
>         advisories behind? Do I get to see two advisories? Assuming you
>         display advisories for some streams, at least the UI should tell
>         me about this even when using a stream (like Rawhide) without
>         advisories; e.g. an empty tab for advisory information (more on
>         that later)

Well, the metadata should already be being displayed for fedora 8,
although this doesn't seem to be working for me. I think the
GetUpdateDetail method just gets the metadata for that specific update,
although I'm guessing it would be possible to get it for all packages >
installed but < available. That's a backend thing tho.

>       - You want to display package changelog deltas; e.g. if I update,
>         say, hal from 0.5.10-0.git20070925.fc8 to 0.5.10-3.fc9 then you
>         should show
> 
>                 * Thu Dec  6 2007 David Zeuthen <davidz at redhat.com> - 0.5.10-3%{?dist}
>                 - Grant user 'haldaemon' an authorization to read authorizations of other users
>                 
>                 * Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 0.5.10-2
>                 - Rebuild against new dbus-glib
>                 
>                 * Thu Oct 11 2007 David Zeuthen <davidz at redhat.com> - 0.5.10-1%{?dist}
>                 - Update to latest upstream release

Yes, if we can get that data from the metadata then this is what I hope
we should get also.

>       - Ideally, I want to know what other changes an update of one
>         package causes; e.g. what packages that I have installed already
>         will be
> 
>         - required to be updated
>         - uninstalled (e.g. Conflicts:)
>         - replaced

Well, we show what we would obsolete and update.

>  o  Fine, so now I press "Apply" guessing that it will update my
> system.
>     Wow, the window just disappeared. Very confusing; did the
>     application just crash?

I figured once the update was underway we could just close that window;
if the update fails to be scheduled then the window is not closed. Did
you expect to have to close the window manually?

>  Oh, wait, there's something happening in the
>     notification area (thank god I have that running, huh?). So I click
>     my new icon in the notif area. It shows me a menu! Hmm.. with a
>     single item. Anyway, I get to see this window when clicking the
>     item
> 
>     http://people.freedesktop.org/~david/Screenshot-PackageKit%
> 20Progress.png
> 
>     which is another punch in the face. First, words like "Part" and
>     "Transaction" and "Task" are kinda technical and I'm not even sure
>     what you even mean with the former.

Better names welcome. I too am no good at this naming thing.

> The icon changes a bit; first
>     it has some wheels, then after that a green arrow pointing down;
>     am not really sure what those means. Oh, the icon in the
>     notification area tells me it's resp. "Setting up" vs.
>     "Downloading". I guess I could have guessed that already.. but..
>     why simply not include the text in the "PackageKit Progress"
>     dialog?

Where, in the status bar at the bottom?

>     Also, I'm annoyed that it doesn't tell me what the hell it's
>     downloading and how fast it's going; what if I were to catch
>     a flight? Oh, wait, sometimes it does show me something
> 
>     http://people.freedesktop.org/~david/Screenshot-PackageKit%
> 20Progress-1.png
> 
>     This suggests it's just a bug. It's annoying with such bugs
>     though; shouldn't release software with that kind of defects;
>     suggests you need to do more smoke testing before throwing
>     together a release...

Yes, this is a bug I've mentioned a couple of times on the list before:
sometimes the yum backend does not emit a "Package" signal telling us
what it downloaded or is installing. It's a yum backend problem.

>     Also, the title of the dialog is bad.. "PacakgeKit Progress"?
>     It would be more clear with something like "Updating System".

Seems sane, and then we could nuke "Task description"?

>     About the buttons; the [Help] one is greyed out; not sure why
>     you need a [Help] button anyway; it's not like GNOME has that
>     in other progress dialogs.

Well, taking you to the yelp file to explain the icons.....

>  It's confusing there's both [Close]
>     and [Cancel]; I'm guessing that [Close] will dismiss the dialog
>     but the update will keep going in the background while [Cancel]
>     will abort the transaction. Definitely need more text and better
>     names for the buttons. When I press [Cancel] I get this less-
>     than-useful dialog 
> 
> http://people.freedesktop.org/~david/Screenshot-pk-update-icon.png

Ahh, this means that when we asked yum to politely close it ignored us,
and we had to kill the process. Could you grab the packagekitd --verbose
log if you could reproduce this please.

>     and when dismissing it the "PackageKit Progress" dialog is still
>     being displayed; I have to manually hit [Close]. Annoying.

We should close the parent window automatically?

>  o  So now is the part where I actually make PackageKit run to
>     completion. Fairly uneventful, actually.. the icon with the
>     wheel/green button now changes to something that looks like
>     a refresh button and this time I'm somewhat getting feedback
> 
> http://people.freedesktop.org/~david/Screenshot-PackageKit%
> 20Progress-2.png
> 
>     When the update is done I'm greeting with a libnotify notification
>     that disappears again before I could screenshoot it. It said
>     something like "Task Completed - System is updated" and then I went
>     to check the "PackageKit Progress" window but it suddenly
>     disappeared.

Sure, it waits 5 seconds then auto-closes. Bad plan? The "Task
Completed - System is updated" message now has a "Do not show me this
again" button.

> However, one thing that is somewhat clear to me is that you probably
> want to integrate the now-called "Software Update Viewer" with the
> "PackageKit Progress" dialog. This suggests the latter should be
> available as a component that
> 
>  - can be embedded in the now-called "Software Update Viewer"
>  - can be embedded in "Add/Remove Software"

Updating is orthogonal to adding and removing.

>  - can be shown standalone by clicking the icon (suppose you
>    a) logout; or b) do f-u-s; or c) automatic updates;)
> 
> Just a thought. Also, it's extremely confusing that the tray icon is the
> main UI driver for what's going on; e.g.
> 
>  - it's how you get to the PackageKit progress window
>  - it's the one reporting a "Task" is completed

No, if you keep the application open then the application manages the
notifications and messages, not the tray. The tray libnotify messages
are only for when the calling program did not exist or has already quit.

> Being a software developer myself, I can almost guess why it's this way:
> you have a "potentially N clients" <-> "1 server" architecture and it
> just makes it easier to make a stateless icon drive the UI. It's just
> such a bad user experience; you really need to focus on the single task
> that is updating the system: it needs to happen from a single stateful
> dialog.
> 
> Anyway, reading this long mail again, I realize I sound pretty angry,
> harsh and dismissive. Sorry about that. I guess I'm just frustrated
> about the poor user experience / UI that is currently gnome-packagekit.
> In my view, it definitely needs a lot of work before it's ready for
> primetime.

I totally agree. Patches appreciated.

> And I think if you sat down and thought about the user
> interactions it would be straightforward (not easy) to come up with UI
> that is a lot better than this...

Thanks...

> Oh btw, I realize some of my suggestions are somewhat developer/geek
> focused; e.g. the suggestion of displaying pkg changelog deltas,
> conflicts, provides etc. Yes, these are a bit geek-centric but I'm
> confident they can be implemented in a way that won't pollute the UI for
> non-geek users like my mom. Also, keep in mind that to win the hearts
> and minds of both GNOME developers and distribution developers you need
> to make the software work for them instead of dumbing it down to the
> point where it just gets in the way. Finally, as alluded to in [1], the
> other category of users that really really care about these things are
> admins managing enterprise-ish systems and carefully review and
> cherry-pick updates.

Enterprise isn't something I was considering as a use case, although I
would be interested to hear how the use-cases are different.

> Sorry again for the flames. Hope it's useful though. 

Yes, thanks. Just a little blunt for my liking :-)

Richard.