AppStream for Apper

As some of might now: I did a GSoC project for OpenSUSE this summer. The goal was to improve AppStream and the Software Center stuff on all Linux distributions.

During my SoC project, I also created appstream-core, a small library and infrastructure to create & use the AppStream application database. This project enables all other tools to use AppStream data and combine it with PackageKit information.

So it was just natural to bring this stuff to Apper too, our favorite PackageKit-based KDE package manager 😉 Apper has had a function like this before, but it was limited to Kubuntu. Now, the AppStream stuff will work on all distributions which support AppStream and ship at least PackageKit 0.8.4 (currently unreleased).

The result of Apper+AppStream looks like this:

As you can see, Apper is showing applications now instead of packages. (All packages which don’t ship applications are still presented as packages) It also uses the Debian screenshot service to display a screenshot. This feature is experimental and still not completely finished on the AppStream side.

Additional credits for this go to Daniel Nicoletti, because I based my work on previous work done by him.

The new code is in Apper Git already. You will need PackageKit>=0.8.4 and AppStream-Core to test it, but because these changes are experimental at time I’d suggest waiting for your distribution to ship it. (many software is even unreleased at time)

So, this is just a sneak preview of the cool stuff to come. 🙂 Stay tuned!

12 thoughts on “AppStream for Apper

  1. After seeing the work on Muon (which now has an abstracted backend – they should’ve gone with PackageKit right away, huh?) I’m wondering if it’s worth it replacing Apper as PackageKit frontend for KDE with Muon…

    Apper somehow just doesn’t seem to get to the point of being a decent YaST software manager replacement and that YaST module, while powerful, is an usability nightmare.

    1. I need to talk to Jonathan again, but as I know the codebase, this will be impossible, as QApt and Muon use many Apt- and Debian/Ubuntu specific functions which will not work with a PackageKit backend. What I like to have is replacing the qapt-worker daemon with PackageKit, but this also only to kill another package-management-background-daemon which is a possible error-source.
      For all other stuff, QApt has to be used.
      What I think might be possible is porting the Muon-Discover tool from QApt to QPackageKit, but I haven’t looked at the codebase yet. (also, I don’t have too much spare time to start another new project ;-))
      Replacing Apper with anything is no good idea, because Apper does consist of many different parts, for example the session-implementation, a nice Sentinel-Integration, an update application which was far better than the one in Muon, at least a few months ago (Muon catched up now ^^) etc.
      The PackageKit interface is clean & simple, that’s what it is designed to be. More powerful functions which aren’t supposed to be used by non-technical users won’t be added to it that easily. (but we can try to convince Richard) – So there’ll be still a need for YaST for exotic actions. For everything else, Apper works great and super-fast (with PK 0.8.4) – Yust try it! (I don’t know which Apper version is shipped with OpenSUSE at time)

      1. Ok, understood. As we’re just about to release openSUSE I’m fairly sure we will come with an Apper/PackageKit version that won’t be too awesome but so be it…

        1. Yep 🙂 For the new stuff, the Zypper backend needs to be adjusted first, unfortunately.
          I had a conf call with some OpenSUSE people and AFAIK this will become a priority soon to support AppStream in OpenSUSE and improve PackageKit integration.
          Btw, I think we should talk about the AppStream stuff and application management – I saw your name way to often during my SoC work and even before when doing PackageKit/Listaller work, and it looks like we share the same “vision”. 😛
          I always like input on stuff I do, especially on cross-desktop/cross-distro projects, because it is very important most people are happy with the project’s direction.

    2. It’s not Apper that is not getting to the point of being a decent YaST software, the backend has several issues:
      – it’s case sensitive
      – it doesn’t do OR searches
      – it keeps reloading the cache so when you have a bad connection you almost can’t search
      First the backend needs fixing then if you have GUI ideas for improvements or usability cases please tell us.
      Putting Muon, USC or any other software running on top of PackageKit with the current backend you will have no different result.

  2. I do not think that the user is interested in the “architecture” column. It is a technical detail that (s)he should not worry about. Just drop that column and display the programs that work on their machine.

    1. Agreed – that’s why the architecture column is hidden by default 😉
      I just enabled it because I am on a Debian machine with multiarch-enabled and the architecture is important for me.
      Usually, this field is hidden 😉

  3. would be nice if a future release had ratings and maybe user comments, especially if the ratings could be generated by all users not just the running distro’s

    think lots of folks will appreciate seeing the app instead of the package(s)

    1. This is also part of AppStream and might be implemented step-by-step. Biggest issue at time is the lack of manpower. (As in every other project too ;-))

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.