KPackageKit 0.6.1 has received lots of love regarding it’s user interface, last KPK (KPackageKit) was released 5 months ago, after that release I decided to work on things that were also upsetting me like printer-manager (my last post), well it was a good exercise although I couldn’t make printer-manager for KDE SC 4.5 (due not being able to add printers yet). And because of that KPK got abandoned for a while (my mailbox had more than 1000 of bug emails), this was definitely good.
Why? Well I think that when you are too close to a project you stop seeing it’s defects, using KPK was so natural to me (since I knew it all) that I didn’t see a point in changing much of it, although I had some bug wishes most of them were minor fixes. After leaving KPK I started to close more attention on people using it, and started to take note of everything.
For example, a dude that works with me was going to update his packages, on the update ui there was a button written “Refresh”, this is not too bad for english but could be made clearer, in Brazilian Portuguese “Refresh” can be translated as “Update” which is ok for those who knows that it updates the list, but my friend thought it would Update his packages…
Another annoying thing was the search line edit, in small screens it get too small to type because of a check box next to it, which was too wide, I didn’t want to loose vertical space since it’s good to don’t scroll to list to much, but after making each item on the list a bit smaller I could change the view to a tabbed view, which allowed me to make it even prettier.
The check box that used to had package groups (wasting horizontal space) rests in peace now, I took it’s model and set it on the first tab, right when you start KPK, so you see the groups like in system settings. But most users open KPK and want to search so above it there is the search line with much more free space, when you search the groups are hidden and the results are shown, if you want to go back there is a back button.
The biggest problem was actually the Delegate of the package view, it is really hard to represent a list packages that can receive different actions. For example: if I add a checkbox to the installer/remover list, what would mean check? Probably installed, but if I uncheck it how do I know that this item is going to be removed and isn’t simply a not installed item? The current view showed a down arrow (trying to mimic a download), and an X icon to remove, but NO user (I’ve seen) using KPK for the first time realized what that means, probably because no visual feedback was used.
After thinking on this problem a lot I decided that if I changed some stuff on the delegate I would have more space to add buttons inside the list. Now if you click on a button labeled Install/Remove it goes to Unmark, you are now probably thinking how do I know if the Unmark button hides an Installed or Available item? The answer to that question is that at the left of the list there is an small checked emblem for installed packages, it is at the left because if you had to move your eyes to the right while you are reading the list it would become uncomfortable.
The next tab has all your installed packages, that are only loaded when you click on it (because some backends are very slow), with this tab a wish I had for some time could be completed, you can now export the package list to a PackageKit catalog that can be imported by clicking on the button next to it or even with gnome-packagekit. Yes, you can now make sure all your machines have the same set of packages or format your machine and have all your apps reinstalled again (Just make sure the file was correctly created before you want to kill me 😛 ).
And the last tab is the Pending Changes, which lists all the actions you are about to do. Unmarking items there make them go away. This makes reviewing changes easier.
I’ve said check boxes aren’t good for packages list, but actually they are perfect for the updates view, the user looks and knows that a checked update will be updated, it also wan’t easy to Understand how to select all packages, so I decided to do like my Y! mail does, I added a check box in the header list. It wasn’t so clear that clicking on the update would expand it and show it’s description, the alternative is not very clear, but it’s more consistent with KDE apps, I’ve added an arrow pointing right that when clicked starts pointing down and the item is expanded.
There are no more package grouping in any view, the reason is that the code was hard to maintain, it is not good when you want to type ‘k’ and go to the package that starts with k, and it’s really hard to go group by group in the updates view trying to find if X package is going to be updated…
The Settings interface did changed a bit but noting drastical, it just have one more item on it and the origins list is sortable now.
But the coolest change to me was the transaction interface, the old one didn’t resize correctly (KDialog’s fault) and was actually weird when the backend didn’t send sub progress changes (the details progress bar stayed spinning). So instead of showing the package name now I only show the busy icon, text and the main progress bar, when you click Details a list is shown and there you have a progress bar for each package emited by the backend, the current status (downloading/installing…), the package name and it’s summary. Clicking on Details does not shrink the view anymore, and your preferences are all saved. In the future I’ll try to make aptcc emits the repository it’s downloading if this works I’ll enable for others backends.
And just yesterday I fixed PackageKit to allow backends to emit download speed so if you are downloading you will see something like “Downloading packages at 400KiB/s” (if your backend supports this).
The next release will be 0.6.1, including many fixes, I’ve closed 92 bugs last week which has put me on the 4th place at https://bugs.kde.org/weekly-bug-summary.cgi“The heavens declare the glory of God; the skies proclaim the work of his hands.” Psalm 19:1