PackageKit UI Improvements (and 0.2.3)

Well, I’ve just released PackageKit 0.2.3 (stable) into the world. I’m going to build this for Fedora 9, as it’s a massive improvement over 0.1.12 and should have no regressions and plenty of nice features compared to that old version. It’ll sit in updates-testing for a few weeks, and if there are no problems I’ll push it to updates.

Of course, declaring the 0.2.x branch as stable allows us to all do some cool stuff on master. We’re working on making the UIs look beautiful.
Two examples are below, for installing more packages to satisfy deps, and also removing other packages if you chose something with dependants.

We’re also fixing up the file viewer to be a treeview, as a long list of files to scroll though is pretty boring. We welcome newcomers if you want to have a try at this hacking thing.

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.

21 thoughts on “PackageKit UI Improvements (and 0.2.3)”

  1. OK, I’m going to be the sacrificial lamb here. I think it is ow time for the package name and architecture to go away. How about , “Upgrading from version 2.2 to 2.2.3” in its place?

  2. Minor petty nitpick:

    The dialog in the top screenshot has the wrong borders and spacing sizes. for example, the buttons are further from the window edge than the other widgets.

  3. sorry, this wording is … not particularly elegant: “5 other packages also have to be installed”. Might I suggest something more along the lines of “5 Additional packages must be installed”?

  4. @Rob:

    I tried to remove the package name, version and arch, but a large majority of users are techincal users that don’t want to be treated like kids. Plus, some of the package descriptions are not that good at all.

  5. @Vincent:

    That’s a gtk+ bug I think. I’m just packing the vbox of a GtkDialog box, so it should be all HIG correct.

  6. I hope to see the de.po translation shipped by Fedora this time instead of the buggy and aweful de_DE.po translation that was shipped by default in F9 and was full of typos. Thanks. ;-)

  7. About the spacings: when packing into a GtkDialog, you need to set a border width (5 pixels IIRC) to make up for the spacing around the button box on the bottom.

  8. Are the “large majority” of your users really “technical” users, even now? How long will this be true? If this software ships with SUSE, Fedora, or Ubuntu will this remain true?

  9. Rob J. Caskey:

    I’d certainly argue to keep the long-hand, fuller, more accurate and technical names of RPMs to be installed being prominent in the UI. It’s a vital descriptor.

    How vague is ‘Document Viewer’? It’s fine for the Fedora menus and the like, but I don’t think the majority of us identify our programs with baby names like ‘document viewer’ one-hundred percent of the time.

    As Richard said regarding pacakge descriptions, even in the example how is ‘evince backend for dvi files’ any more helpful than it’s full-long-hand package name? It’s not.

    Great to see the 0.2.x branch getting closer to general release on Fedora 9.

  10. Jon,

    You and I can find out what’s going on. We can go poke packag-kit from the command line, or bypass it and use rpm directly. In fact, for most people the whole “X other packages are going to be installed even though you didn’t ask for them” dialog is just a nuisance. When we do impose on users’ time, we should give them information that we expect to be most appropriate to them: an executive summary, not a technical briefing. We are trying to get in and out of their way as fast as we can with a good conscious (“Excuse me user, I’m afraid we do need to talk at considerable length regarding this SMART result”).

    When we are installing new apps the result should be “OK, here is where it is on your menu.”

    When removing apps, yes, users do want us to confirm that removing X will get rid of their web browser.

  11. another one: when you rollback changes, PackageKit uses the PolicyKit dialog with “remember password” checked. Should not display such a one, like it already does (right) with unsigned RPMs.

    A bad user could rollback a kernel update and use an exploit valid for older releases for example.

  12. I think I understand where you are coming from Rob, it’s a noble cause to want to make things as clean and easy as possible for new users. However if we completely remove the long-hand names from the primary UI I just don’t think it’s going to make the situation better. The long-hand names shouldn’t be the first visual indicator and in 0.2.x they aren’t anymore.

    I agree with what you’re saying about new applications in the menu being more visible at first install.

    The rest of the argument however, I think is larger. You’ve got to be asking who’s using Fedora? Who do we want to use Fedora? Who do we want to use PackageKit? Let’s face it, the majority of Linux users are at least technically-savvy and able to grasp things quite quickly. The long-hand filenames for RPMs are a lot more instructive than some windows executables. Version numbers aren’t alien to these people I speak of, architectures might be and the concept of a repository for software instead of downloading executables from the internet and running them, with a built in setup program is the big gap we have at least with regards to converted Windows users.

    I’m still a new Linux user myself. Personally, I don’t think PackageKit at present is being too technical. It’s purpose is inherently advanced, just as firewall configuration is. If someone can’t do it, they get someone else to do it. I just think you’re trying to solve a problem that not even Windows has solved properly. If a user isn’t comfortable with installing software then they’re not going to do it and they’re unlikely to be the type of user who is running Linux. How dumbed down, and how best to communicate vital information to the user, about very important things such as package installation, is such a wide debate. I just think it’s wholly out of the scope of this topic.

  13. And another couple of critiques:

    – On an x86_64 system, you can’t install i386 arch packages even though they’re visible in the UI. It will allow you to start the install and then will error out with, “package already installed.” They will show as installed in the UI after you install them via yum.
    – It should not be permitted to have a manpage that consists of “consult the website for documentation”.
    – The filtering and sorting options frankly suck when you return a large number of potential matches and need to scan through them for what you actually want. There needs to be some method by which you can sort them or otherwise filter down packages besides the current filters, which are frankly useless to most users.

  14. I agree with PackageKit as a backend, but as a frontend? Hm, no.

    How are these dialogs going to show anyway? You want to uninstall 1 thing, and you get a 2nd dialog with the dependencies? Multiple dialogs are the most annoying thing since popups.

  15. PackageKit should has an option for user to see details package downloading progress during install. I find current progress bar in f9 to be too dumb-down. I don’t know what it currently doing. why i take too longs. ETA it will finish. To cater for both kind of users, maybe a details button ala Synaptic is needed. Those who want to see the details can see it and those who doesn’t care will still be happy.

Comments are closed.