gpk-log crap UI

gpk-log

gpk-log UI

This UI is really bad. Please suggest improvements. 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.

14 thoughts on “gpk-log crap UI”

  1. Just straight off I have some trouble telling what the icons in the bottom column does. What does the green arrow do, what does the broom do etc?
    Perhaps text is more suitable to convey the message instead.
    Also it seems the boxes don’t line up properly on the left side. Even thought it displays a inheritance (so I see why you did it), it would be more pleasant on the eye if they were equally wide.

  2. First thought was inspiration at gnome-system-log.

    It’s basicly just a “data view”, it should show information – tersely. So just a single list of “updates”. Treeview i guess in gtk.

    No icons that make the the list items be higher. There is already enough wasted whitespace with items in treeview… ick! ;).

    Maybe the grouping can be done with an expander, preferably with a custom renderer (correct name?) as done in the gossip/empathy chat list versus the standard in system-log which indents the the whole list.

    Secondary features could be filters and searching. Either by searching or selecting a date range or certain packages. I don’t know who would really need this, maybe admins?.

    You asked for suggestions, not patches :-)

  3. Hi!
    I prefer the top box at left, with two columns like ubuntu add remove software.

  4. Low level:
    * Imitate Epiphany’s History window. Get rid of the “Help” and “Close” buttons (perhaps have a menu bar instead), and get rid of the padding between the lists and the edges of the window.
    * Figure out what’s causing the bottom list to have a horizontal scrollbar, and fix it.

    Medium level:
    * What are you trying to show here? I can’t tell. If this is a history of past updates, why isn’t there a Date column?
    * What do the new-page icons mean?
    * Would it make more sense to arrange the lists horizontally?
    * Would it make more sense to have one list with expandable sections?

    Toolkit/Theme level:
    * Persuade whoever’s responsible to stop putting a silly gap between a scrollbar and the list being scrolled.

  5. I would put the package name next to the updated text, like this:
    “Updated package glib2-debuginfo”

    Also, I would hide the details using a GtkExpander (I think thats what its called, the one that can be hidden with a little triangle widget to show/hide).

    This would leave the important information always viewable, what was updated and when, with more information like the version hidden from view but easily accessible.

    You could also consider putting the version number in the main update text as well like this:
    “Updated package glib2-debuginfo to 2.16.3-3-fc9”

  6. Well, an package updated is surely a part if a system having been updated, so maybe a light-weight tree is helpful, i.e. system updates at the root and package updates on the next level. I’d also find it helpful if the list contained what package was updated — dozens of entries all looking alike aren’t really inviting. I won’t click on all of them to find out what was being updated ;-).

  7. I’ve two suggestions:

    1) Don’t put individual package updates and system updates on the same level, e.g. use a (by default unexpanded) tree where the system updates are on the first level and the package updates they comprise on a second level.

    2) Avoid “anonymous” package update entries, I’m surely not going to click on dozens of equally looking “Updated package” entries to find the one I’m interested in.

  8. Well, I wish the pup/pirut folks had the same dedication towards producing good UIs. I think this history UI addition is very useful, and nice enough as is.

  9. Thoughts:

    * I’d really like to be able to see a per-package history by clicking on the package names and then be able to initiate a rollback of that package along with the required changes.
    * Horizontal scrolling is ebil, use an expander widget, ellipses, grow rows vertically, anything.
    * Can we include time as part of the heading for days that have multiple installation events?
    * The vertical scroll-bar is already a time-line, no need to complicate.
    * I’d like user-readable names instead of package names, even though they are longer (as we can see even the package names are already too long).
    * We know deep down in our hearts that a search widget belongs here that will search by user visible description, actual package name, etc!

Comments are closed.