First of all I’d like to thank every one that have put a word of friendship and sympathy due to my big loss. Also thank the KDE community for dedicating the 4.6.3 release in the memory of my loved daughter. It has been a hard time, thanks God we have been able to keep going and even trying to help others which pass through similar suffering. Thank you all.
After what happened I moved back to my old job on Brazil, but even now my time is short as I developed a commercial app (apart from the job), so have to divide my time between family, job, sort of 2nd job and open source coding. This means that Apper development is slow, but progressing. Some of you probably also know that KPackageKit is not going to be part of the main CD of Kubuntu, the reason I trully dunno (I wasn’t even told about that – a friend showed some blog post). As I wasn’t aware of it I can’t do anything about it, I can’t even know what should I improve to change their minds, the sad part of the history is that KPackageKit could been improved instead of replaced. But don’t be too sad, we still have KPackageKit in Fedora, OpenSUSE – as default since 11.4 :D, Kubuntu (optionally), Debian almost has it and many others…
KPackageKit name is a bit geeky and some people didn’t like it, I personally didn’t have anything against it but K* names are often hard to pronounce, so thanks to sheytan KPackageKit got renamed to Apper.
But this blog is not about the renaming, it’s about what cool new stuff will you find in it.
First Apper is based on my rework of packagekit-qt which is called packagekit-qt2, and this rework makes Apper much faster than KPackageKit was, the inner details is that we don’t use the huge QSharedPointer for packages and don’t create a bunch of useless stuff unless the user asks, I didn’t measured the time but first time you run it you will surely notice. This also means Apper is more stable since packagekit-qt2 has a cleaner code and a nicer API.
Second Apper has several user interface changes and a much nicer integration with KDE.
The first thing you will notice is that I finally got rid of the useless left selector (Get and remove SW, Updates, Settings), they are all in the main view. This is great since we can have an UI which better fits small screens and packages summaries can be better displayed.
The next and soo nice UI change is the package summary, it nows follow the package name with a less opaque font, this also makes better use of the screen and allowed me to make versions be shown by default.
Now I’ve received many requests asking me to integrate the transaction icon into the Plasma Jobs notification. This was hard to accomplish because I didn’t want to bother the user with the final pop up “Task Finished”. So I finally had an idea to the problem: instead of showing the job there for every transaction it will only show the transaction there IF the application that issued it is not running anymore. In other words if you have Apper open and installing things, nothing will show up on the tray nor the plasma stuff, but if you close the window it will automatically start a plasma job so you can still track the progress there 😀
Time has shown that people don’t like dialogs poping up all the time in your face, KPackageKit had many dialogs, especially one when installing that people didn’t like, so I decided to embed it into the main UI as well and show package details, but not only details, I’ve changed PackageKit spec so you will also see your repositories updating…
The settings UI is horrible (ideas welcome 😀 ), but it worth notice the new features, Apper is a green app, it does not check or install updates while on battery, and it also does not check for updates while on mobile network connection. I’m planning to change the way we select the check interval as some have requested to be on mondays or at 21h…
What is left before Apper can be released?
- I’m changing the PackageKit Session Interface (the one that is called to install local files, search for codecs, search for printer drivers, search for Plasma Applets thanks to Kevin Kofler and others) which used to popup a bunch of dialogs, the plan is to make it look like a wizard.
- Display the size of the packages in the updater UI, so one can have an idea of how much will that cost.
Dantti's Blog 
Hello it seems Ubuntu went with Muon have you looked into it, seems like both projects are doing the same things.
Yes, that’s what I said on the beginning of the blog post 😉
Hey there, I’m a Kpackagekit apper-git user with Arch Linux, after previously trying to compile what ever application they had for KDE to handle Arch packages I found this thing, the new changes look very nice! And as I enjoy keeping my system up to date, it’s nice seeing the nice new icon popping up from time to time 😉 Love it!
Hi, I’m also an arch user, but of the “old” kpackagekit. I really like the UI improvements, but I see one inconstistency: the settings button shouldn’t be in the list view, since it’s no a package list. I think something like the rekonq setting button would fit better (it would be easier to spot, and would remove this inconstistency – I really don’t like inconsistencies ;p). You could put it instead of the icon that serves (pardon me if I’m wrong) no purpose.
Anyway, keep up the good work, and thanks!
Nice to see KPackageKit being used on more distros 😀
and yes it is a bit inconsistent, though I didn’t had any better idea…
not too sure doing like rekonq would be nice in this case, btw what useless icon are you talking about when you said it could be removed?
Best
I think dieppe is asking why is Apper’s Settings listed under the “Lists” section. I think dieppe may be right as “Settings” is not a type of package list. dieppe is requesting that instead of finding the Setting’s icon under “Lists”, you put it near the search bar like how rekonq does it!
Yes, I got that, and it’s already changed 😀
Best.
joining the choire: i am happily using kpackagekit on archlinux, the shots look nice and since there appears to be something in aur i ll try it right away. thanks for your work, really appreciated!
“Some of you probably also know that KPackageKit is not going to be part of the main CD of Kubuntu, the reason I trully dunno (I wasn’t even told about that – a friend showed some blog post). As I wasn’t aware of it I can’t do anything about it, I can’t even know what should I improve to change their minds, the sad part of the history is that KPackageKit could been improved instead of replaced.”
My thoughts why Muon is a better choice right now:
The tasks that are performed using package management basically boil down to
a) keep the system up-to-date
b) install programs
c) work with packages
b and c are different use cases: b is for people who don’t care about their system, c is for people who do.
Now Muon has three different applications for those three tasks: a) muon-updater, b) muon-installer, c) muon. Apper, on the other hand, also has one part for a, but it has another part that sits somewhere between b and c without really being suitable for any of these tasks, and this causes most of the trouble.
Conclusion: to compete with Muon, you have to make Apper a lot easier to use, so that it covers a and b.
Apper does not have separated parts to handle similar tasks.
for b and c it has an unique user interface that the user don’t have to bother if
he is looking for packages or applications. Right now I’m trying to make this simpler but it does it job pretty well.
Apper is not here to compete with anyone, it’s here to provide users a good user interface for user of many distributions, so they don’t need to learn new tools every time he wants to try a new distro.
Apper also provides an easy and cross distro way of installing packages. With Apper you can do things in several distros which you can’t with muon.
IMO muon should be used by advanced users that understand that many options, but I’m not here to judge, users are free to choose though they will have to manually install Apper on the next release.
“Apper does not have separated parts to handle similar tasks.”
Apper squeezes unrelated tasks together. For example, every entry here https://dantti.files.wordpress.com/2010/09/kpk1.png filters the list of available packages – except for the history entry, which does something completely unrelated.
“Apper is not here to compete with anyone, it’s here to provide users a good user interface for user of many distributions, so they don’t need to learn new tools every time he wants to try a new distro.
Apper also provides an easy and cross distro way of installing packages. With Apper you can do things in several distros which you can’t with muon.”
It’s competing with Muon for the default installation in Kubuntu. The only way Apper can reach its goal of “easy and cross distro way of installing packages” is by being installed by default on as many distributions as possible.
“IMO muon should be used by advanced users that understand that many options”
You didn’t have a look at muon-installer yet, did you?
And please, don’t get me wrong, I am a big fan of packagekit – hell, otherwise I wouldn’t spend my time discussing Apper. 😉
Yes I know muon-installer the Ubuntu Software Center clone.
I’m not getting you wrong, I know you are trying to say Apper should be better in some tasks,
but please be more specific. For example I do agree the Settings entry is in the wrong place, but this was the first step to have more horizontal space so small devices can use Apper instead of creating another GUI for PackageKit.
Can you hang around on #packagekit? I’m really open to ideas, I just don’t have much time to make all of them happen so fast.
Maybe a tool button where we can have Settings, History, Export this list, import this list might be nice.
About the stars you have in muon, I’m planning to add that and the zgheist stuff after the fist Apper release as well as the comments on applications, but time is the issue here…
Best
Some thoughts on the updater:
The main tasks performed are
1) check for updates
2) install *all* updates
3) verify the system is up to date
The updater should be optimized for those tasks.
Also, people are normally not interested in specifics.
Based on these thoughts, a suggestion for an update ui:
This allows to perform task 2 with a single click (“Install updates”) and task 1 with a single click (“Check for updates”)
It is also possible to deselect updates using an extra dialog (“Select updates…”)
Consequences of the update action are described in the label
The progress indicator is shown when an update related action is performed, i.e. on checking for updates, downloading them and installing them.
Note that the progress indicator does not give away specifics (i.e. it does not tell which package is currently downloaded)
The green shield indicates that the system fully updated, and therefore provides an easy way of performing task 3
Automatic installation area: it allows to quickly configure automatic updates. Other update related settings seen in https://dantti.files.wordpress.com/2011/08/apper-settings.png are reachable via the “Advanced…” button. Reasonable presets ensure that this button is normally unneeded.
I quite like this idea. That updater looks simple and easy to use.
But it would be much better if it could be made a little smaller and become a plasma widget.
For users that don’t care too much about packages it would be the best way to update their system, and it would be convenient not having to open any programs just to do so.
Well what could be done, is to right click in the updater icon, cause imo adding a plasma widget just for updates is not very nice, and some users might remove by accident..
Another ArchLinux user here enjoying KPackageKit/Apper.
Thanks a lot for your great work! 🙂
I like it a lot better. A few suggestions, though:
1. Most users probably do not care about source packages. It would probably be better to hide these by default.
2. It would be nice if it showed an embedded progress meter instead of a spinning arrow when, for instance, looking for updates.
3. It doesn’t appear to let you change the repository for a package. This is a big deal for users with multiple repositories.
4. It would be nice if there were more filters, such as repository, package group and so on (if packagekit offers those features).
5. It would be nice if there were more searches, like requires and required by.
6. The details panel should probably have a title telling you what you are looking at (for instance you can’t really tell “depends on” from “required by” just be looking at it, or better yet use tabs.
7. It would be nice if it used a columns view with a header bar for sorting and the ability to select the columns you want.
8. If you do a search then change filters, the search is not automatically updated.
1. I want to hide by default but first I need to find a way to make users aware that something was hidden
2. I’ll think about
3. This is a hard thing to do, distros have very different ways to deal with this, that’s why Apper has a build option to call the distro specific tool to handle this
4. I’m working on filtering by repositories on aptcc IIRC fedora already has this filter, it’s up to the backend now.
5. these searches can be done when you click the “More >” button, I don’t see the point of searching by on the search line edit
6. I’ll think about either
7. I enabled back the header, just need to make sure soriting works now…
8. Yes, this is a requested feature I’m about to add it 😀
Thanks.
1. Do they really need to be made aware? How often do everyday users need to install source packages? Anyone advanced enough to do this can probably find it easily enough.
5. But there is no way to install packages from there. You would need to open that, find the first non-installed package, then do a new search for it, then re-do the first search and find the original package, and so on. You can’t even copy and paste a package name from those lists, nor can you click or double click on an item in the list to take you to that package.
And those were only examples. There is no way to search by summary, search by category (such as the location in the application menu), search by version, or search by repository.
1. IMO yes, but I plan to borrow the idea from USC that just has a status line saying that 3 technical packages where hidden
5. Sure, we can’t install the packages that are on the depends list, so what’s the use case? clicking on one of the items and being able to install it or right clicking on them and marking to install would be ok?
But there is a way to search by summary, you just change the search method to search by details which is summary + details.
Best.
The problem with searching by summary is that for many packages you can get a huge number of false positives because it would be searching for words in the summary, words in the details, depends on, and required by at the same time, with no way to tell them apart.
I see a few possible solutions, some of which are not mutually exclusive:
1. Have an “install” button on hover in the list
2. As you say, have install in the right-click menu
3. Double click on a package in the list to take you to that package and/or add that to the right-click menu, then hit the back button to return to the package you were on
4. A button and/or right-click menu entry to display all of the packages in the list in the search display
5. Add those entries to the search
Can I make a request (I’ll also put it on KPackagekit’s kde-apps page) that dependencies are clickable? When one clicks on a dependency a new search is done, using that dependency’s name. Also, a back button appears near the search bar. When, one hits the back button that person can go back to the original program he or she was looking at.
8. is done now 😀
Great
With my openSUSE packager hat on, we would love to get https://bugzilla.novell.com/show_bug.cgi?id=681592 fixed if possible. Switching to apper is not possible for the next release because feature freeze is in 1 week and apper is not stable enough yet
Hi Ismael, I’m starting to think that the problem Fedora and OpenSuse have with this kind of issue is related to some DBus limitation, on my tests some time ago I saw the same DBus error message saying it’s not allowed to add more connections. When that happens no DBus communication works you need to kill the application. I’m not too sure why this happens, packagekit-qt2 does probably a better job in this case as it creates less connections to talk to DBus, but this only means that it should take longer time to this kind of bug to happen.
Can you investigate is there are DBus limits set on Fedora that aren’t set on Ubuntu? because I don’t have this problem on my machine but I saw it on Fedora but couldn’t manage to get it fixed.
Best.
on openSUSE I see that dbus’ max_connections_per_user is set to 100.000 so that shouldn’t be a problem I think.
I think this is the problem, because especially with packagekit-qt1 it creates lots of connections when there are new transactions, and I’m not sure if this number is decreased when a connection finish or if it’s just grow. So try to remove the limit I’m pretty sure the problem will go.
Also with kpk open start doing lots of searchs, in Fedora after a while I got connections denied, I couldn’t test packagekit-qt2 in fedora or openSUSE yet, but I believe this might still happen though it would take longer…
I thought they made muon because KPackageKit was abandoned (At least, it felt like it could use some more love), which made me feel quite worried as I use it quite a lot in my Fedora machine.
But this post put those fears out of my mind – good to know it’s alive and kicking! 😀
Keep up the awesome work!
PS: Sorry to hear about your loss.
Hi and thanks for your work 🙂
I use apper on archlinux, tried to compile from git but it ask for packagekit-qt2 0.7.0 but last version is 0.6.17, I modified cmakelist to build against 0.6.17 and apper works well ???
Could you add an option to download update only for user configured hours ? I have poor satellite internet, and no quota only between 11pm and 7am so I would like apper to download new packages only between this hours
Sorry for poor english 😉
Did it build with 0.6.17? if so I should change this, it just that there was the plasma-widgets search addition on PackageKit but I was unsure it was available in 0.6.x series 😀
I’m thinking on making the automatic update more flexible, but haven’t had any good ui thoughts yet 😛
Oh, sorry – I guess I forgot to inform you that this feature was backported (but for some reason not mentioned in the changelog…) 😀
Oh by the way, could apper go to the dependencies I double-click in the slide on one package so I quickly could check if I really need those packages? 🙂
sure that’s a feature to be added on a future release
I’m really sorry for the Muon project, but I just removed the Muon software center from my freshly installed kubuntu 11.10. I REALLY like Apper :). If it only gets the comments section etc. of Muon…
It will get the comments section, just a matter of /me (or someone else) having time to do so… 🙂
[…] Plus d’infos sur Apper [en] : Blog de Dantti […]
[…] Apper […]
[…] Plus d’infos sur Apper (en anglais) sur le blog de Dantti. […]
[…] Plus d’infos sur Apper (en anglais) sur le blog de Dantti. […]
Please add more configuration options, esp. with regard to being able to skip non-responsive repositories, setting the time the updates occur (somehow it always happens to be when I need to quickly install some new software which I just downloaded as an RPM), and some more fine grain logic about interactive patches (e.g. so you could download all the patches, install the security, and wait for the rest, or install all non-interactive, or …).
Some more feed back with details while downloading with options to skip over balky repos, or options to download same version from another repo, etc. I just waited 1/2 hour only to find out that the Java repo was (again) not responsive, and had to go back to the start and de-select the Java update to go back and install the rest of the (unrelated) patches. Some logic to enable installing all the patches possible if repos don’t work properly would be most welcome. I ran into trouble when a dependency was not downloadable–but after I closed the window, I didn’t know which package was trying to install it! So maybe putting the dependencies under the various packages you choose would help some. Making these user configurable displays would likely avoid clutter when not needed.
Finally, not sure where you get the download speed, but it took an awful long time to download a few (31.6MiB) updates at “4.0 GiB/s” (my broadband is good, but not that good! I am happy to get 20 MB/s!
Showing the repository with some options (i.e. where it is coming from, where else you do/do not allow it to come from) and re-sizable column width would also be welcome.
I gave up when I received the message: “The package that is being modified was not found on your system or in any software origin.”
and under details
“couldn’t find package” (I was hoping for some more details at this point).
Otherwise, it shows a great deal of promise. I am probably going to stick with ugly old Yast2 until some of these get worked out.
Thanks again for the time and effort you have put into this project, and my sympathies for your loss.
I believe you don’t know how Apper works, so I’ll just show you a little background:
First there are backend plugins that can talk to disto’s package management (one for Debian, other for Fedora and another for OpenSUSE), theses plugins talk to PackageKit daemon process and on the end of the wire Apper talks to PackageKit.
If you understood what I’ve said you can see that most of your issues where about the backend plugins in your case the zypper one.
I’m the author of the aptcc plugin (for Debian/Ubuntu), this one shows status each package that is being installed/downloaded, the speed is also as acurate as the cmd line tools, the behavior is actually the same as the cmd line tools.
If I was an OpenSUSE user I’d probably improve it’s backend, it’s not a lot of work but it requires times to understand some internals, imo the worst thing about the zypper backend is that it refreshes your cache before each operation making simple searches dam slow.
If you can’t code, fill a bug in openSUSE asking these things, else improve zypper backend 😀
Best.
What apper is missing: tracking of automatically installed packages and removal of them when no longer needed and allowing to purge packages.
It’s just retarded to use it without those features when you have other tools that provide them. Just my 2 cents.
Hey!
I’m using Apper on Arch Linux on every 3rd-party installation I deploy, it’s just awesome:
1. it’s very fast.
2. looks awesome, clean and comfortable.
3. feels really responsive.
4. it accomplish its task of letting a user update their system and install new software.
5. definitely is a tool on which one can count.
Thank you!
On the other side, I looked at Muon and I don’t like it: it’s like the old Debian’s Sinaptics but… wait, there’s no ‘but’, seems to be a clone!
May be a bit slower, but a clone at least!
[…] Software Management As I noted earlier in the review, Apper is the latest and renamed version of KPackageKit. Apper promises to be faster than KPackageKit and offer greater stability as per the blog of its developer: […]