[packagekit] Initial impressions from 0.1.1 on rawhide

[Richard Hughes]

On Fri, 2007-10-26 at 10:43 -0400, Matthias Clasen wrote:
> Killing tasks sounds right; but the (small)  delay is not what I'm concerned
> about. It is that the details pane can get out of sync with the selection
> in the list, permanently, until I make another selection. Maybe it
> wouldn't be so bad if the details pane had a heading telling me what
> package it currently refers to. But it doesn't, and so the selection
> in the list is the only way to infer it.

Sure. We need to fix the bug and stop them getting out of sync.

> > Yes, I was thinking of putting these two in a treeview in the tabs,
> > although we would have to duplicate the whole package listview in a tiny
> > window. Ideas welcome on how to solve that.
> 
> Putting them in details tabs makes it impossible to "navigate deeper"
> though, right ? Also, it means you need to always get these lists, which
> may make things still slower.

Indeed, although I was thinking of defering the action until the user
clicked the tab, but that's a bit whack.

Do we need a "back" button or something?

> What might help for the "tiny" part is to make the list/details vbox a
> vpaned so that users can adjust the relative size.

Sure, that's sane. I've played and tried to do this, but I can't seem to
get the text description to shrink back down. glade legends welcome.

> > You'll get many thousands of replies and your CPU usage will go through
> > the roof. Why would you want to?
> 
> It just seems like unnatural restrictions. When the treeview is really
> filled incrementally, I wouldn't worry so much about this taking a
> long time to complete. The user can always cancel...

Sure, but what's the point displaying 30,000 packages?

> > > pk-update-viewer:
> > > - pretty slow to start up
> >
> > To show the window, or to show the packages?
> 
> Slow to show the packages. But acutally,  now that I try again, it is not
> as slow.

Sure, if you try when the daemon is alive it takes a few hundred ms - if
the daemon has to be started and yum forked then a couple of seconds.

> > > general:
> > > - the progress bars in the status bar make the ui look too busy, imo.
> > > In most places a wait cursor would probably be more subtle, and enough
> > > to indicate activity.
> >
> > Sure, I just wanted to show the user how much of the total transaction
> > was complete - and I quite like them now :-)
> 
> I think part of the problem I have with them is that they are a) too big and
> b) the spacing is not quite right. Compare to the nicely done progress bars
> in epiphany.

What about the attached?

Richard.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-statusbar.png
Type: image/png
Size: 1797 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20071026/1fe3b549/attachment-0004.png>