[packagekit] PackageKit 0.1.3 comments / suggestions

[Richard Hughes]

On Wed, 2007-11-14 at 14:16 -0500, David Zeuthen wrote:
> Here's a few comments/suggestions about PackageKit-0.1.3-1.fc9 as
> shipped in Fedora Rawhide. Certainly not an exhaustive test or anything;
> just issues I ran into while playing around with. All in all PackageKit
> totally rocks; most of these things are cosmetic issues that should be
> easy to fix (except for the first one)
> 
> 1. Clicking around... if the yum metadata is out of date this totally
>    blows. I keep getting the bouncing progress bar for minutes. This is
>    especially the case when clicking on an uninstalled package; nothing
>    happens.

This is bad.

>    My suggestion on how to fix this is brutal and controversial and will
>    make the UI worse. Still, I think it's the right thing to do.
> 
>    Suggestion follows:
> 
>    PackageKit's yum backend should never decide when to refresh the
>    meta data. In the case of Rawhide the metadata (primary + filelists)
>    is in the 10MB range. This surely affects dial up users too. Here
>    on the RH Boston network I'm getting like 25kb/s.

That's not insane; we already have the RefreshCache method to do this
when the user is idle and the network is up. I'm surprised we are not
searching from the cache already. Tim, do we do everything from the
cache or just searching?

>    Anyway, for PK to actually be useful what I did was to manually
>    run yum(1) on the command line such that the meta data was current.

Sure, we need to do this better.

>  - The windows should be taller; both for the Add/Remove software and
>    the updater; am I the only one who always manually resize them?

Well, ideally I want a GtkVPaned, but I'm no GTK legend and everything
ends up the wrong size.

>    Suggestion: Make the windows taller.
> 
>  - Multiple feedback is bad
>    http://people.freedesktop.org/~david/packagekit-multiple-feedback.png
> 
>    Suggestion: use unicast signals for reporting errors and only
>    multicast if the initiating caller jumped off the bus

Yes, we need to fix this, and only handle the error in PkWatch if there
is nothing registered to catch it. I've added this to TODO, although I
think I'll need to add something to watch NameOwnerChanged in the
daemon. I've added this to TODO.

>  - Somewhat related: Heisenbugs; There's a few pretty apparent bugs here
>    and there. Sometimes I'm told dependency resolution couldn't be
>    resolved; for example press Depends on the hal package:
> 
>     http://people.freedesktop.org/~david/hal-dep-resolve.png
> 
>    I'm not sure what this even means; a modal dialog certain isn't the
>    right place; a better place would be to put this in the text field
>    on the tab

Sure, the error message blows goats.

>    Suggestion: Do more smoke testing and sanitize error reporting
>    paths and handling

Sure. This just needs real-world user testing I think.

>  - If I click on an uninstalled package it normally takes some time
>    for the description etc. to appear. If I'm clicking the "Homepage"
>    button while PK is spinning I am brought to the "homepage" of the
>    previous package I was looking at

Right.

>    Suggestion: Make the Homepage button insensitive if you don't have
>    the URL

We should probably hide the button if we haven't got the info just
yet... Or just make insensitive?

>  - Homepage is a weird name for a button; ; maybe use Website instead
>    (at least in in en_US)

Home website? Developer website? Ideas welcome.

>  - Depends and Requires tabs are ambiguously named; depends on the
>    point of view whether you're on the inside looking out or on the
>    outside looking
> 
>    Suggestion: Depends -> Depends On  ;  Requires -> Required By

Very sane. I've committed this.

>  - Would be nice to have a ChangeLog tab too.

Hmm. This would be useful to me also, can this be provided by other
backends? I think this warrants another method GetChangeLog() as it may
contain quite a bit of data and may not be supported - any volunteers?

>  - The list of packages should be sorted alphabetically. Would be nice
>    if search in the package list treeview worked.

Ohh, I'm rubbish at treeviews. Ideas welcome.

> Anyway, most of these things are purely cosmetic. Rock on PackageKit
> team. Hope this helps.

It does, thanks.

Richard.