“Muon” is now the Muon Package Management Suite

Starting with version 1.1, “Muon” is now the “Muon Package Management Suite”. (Don’t worry, I won’t try everybody try to say that for the sake of branding :P) The Muon suite is made up of the following components:

The Muon Package Manager. (Which has heretofore been called “Muon”) Its focus has been and will remain hardcore package management with a sane GUI.

The Muon Updater, an update manager

Finally and with grand introduction, The Muon Software Center.

Yep, the application-centric Muon GUI I’ve been hinting about for the past few blogs will in fact be included in the 1.1 release. The Muon Software Center is designed for ease-of-use, so that anybody can search for and install applications without being bothered about “packages”. But I know that everybody just wants to see the shinies, so here they are:

Screenshot Tour

The Main View

This is what you first see when you start the Muon Software Center. The default view is a categorical view, and by clicking any of the software sources in the sidebar you can view the contents of that particular source, such as a PPA.

Application lister

This is the application list that you get when you enter a category/subcategory, a particular software source, or when you perform a search.

Showing a single PPA

PPA browsing is quite easy.

The search feature is a near-instant way to find the applications you want. Blazingly fast. Seriously.

When you click “More Info” for any application you are brought to this view. The screenshot thumbnails fade in with a nice animation and background shadow after they have been downloaded, and clicking on one brings up a full-size version in a dialog window. The details page is going under some renovation at the moment, so they layout probably will change.

Removing Amor

Installations and removals can be queued, much like in Ubuntu’s Software Center. The action button changes into a progress bar that shows the progress of the installation/removal.

Application Launcher

The Application Launcher allows you to run your newly-installed applications right away.

The History View

The History View is an easy way to figure out just when you installed that one game with a fully searchable and filterable history log. The Muon Package Manager will be getting an identical history viewer.

I plan to do a Muon Suite 1.1 beta release some time over the next two days along with a QApt 1.1 beta. I’ll give the technical rundown with the release announcements, but I thought I’d give you the good stuff early. (As a note for regular readers of my blog, the Muon Software Center is what prompted me to do my KRatingPainteroptimizations. Scrolling the applications list was seriously slow before them. It’s nice and smooth now, though. :)

I probably won’t work much more on the Muon Updater for 1.1. I’ll probably rework the GUI to make it more update-centric in 1.2.

Can you make it possible so that you don’t see old versions of applications (possible configuration for it). The reason why is. I don’t want to end up installing old outdated packages since packages managers won’t allow it.

Alos maybe add an option also to hide packages you don’t want? Like KDE3 ;P

Ah, not quite. ;-)
Not all applications provide an icon, and when they don’t the generic “box and CD “icon is used. I do plan on making an overlay to go over the right corner of the icons in the application list for installed software, but I’ve not gotten around to that yet.

Hey – I don’t mean to be a troll or anything of the sort, but why do you develop Muon instead of helping out packagekit/kpackagekit? I thought the idea was to cut down on new backends and integration points, and unify things. It seems like muon duplicates almost all functionality. What’s different in it? What motivates you to make it? I might be wrong here, so I write this response because I’m curious what the dealio is.

PackageKit is fundamentally flawed. QApt gets rid of one level of complexity/abstraction code-wise, meaning that there is less unnecessary machinery that can go wrong, and an increased level of integration. PackageKit is the jack of all trades, but a master of none.

Compared to KPackageKit’s app-install offerings, the Muon Installer is a lot faster at listing and searching through applications since QApt is a much tighter wrap around APT itself.

This is sincerely an awsome project, even thou it’s bit sad that it’s Apt-only.

However one thing that I would find nice is a possibility to toggle automatic updates that does everything in background with a single option. It would change policykit and QApt rules so that new updates would be checked once in certain time and when new updates would be found, it would automaticly download and install them without asking password. Preferably it should also notify when updates have been found and installed. It was possible with Charka’s Chase update manager which I think is now deprecated.

Ah, APT supports this already without the need for a package manager. :)
These options can be controlled from the “Software Sources” dialog. From there you can configure update frequency as well as automatic update settings. About the only thing that APT doesn’t do is notify of these automatic installations have occurred.

Yeah, using a text character for the breadcrumb arrows is quite suboptimal. I’m really bad at writing paint() functions for widgets, though. I played around trying to get the standard arrow painting after the text for about an hour and couldn’t get it to work right. (If anybody reading this is handy with QPainter, I’d appreciate the help :))

The litmus test for whether this is “The package manager” is what happens when you search for “Java”.
This is a high-profile piece of software that lots of users want and that nobody can find.
It should give option to select the openjdk or sun java and it should allow you to select the JRE or the JDK – hopefully with better names.
The result in kpackagekit is that sun-java6-jre (thats a horrible name) is package number 4xx on the result list.

Thanks for the quick reply and screenshot.
Java is really a challenge. In my head when people search for only “java” they are thinking of one thing: A runtime environment – perhaps a JDK. Then they should be forced to choose if they want OpenJDK or Sun Java.

In the screenshot “OpenJDK Java 6 Web Start” is the first hit. It should probably just be OpenJDK JRE. Sun Java is not even present.
The reason I want Sun Java to be there is that lots of websites in Denmark (especially banks) does not work unless it is the Sun Java.

I think it is really cool that you are building this. And it seems to progress very fast. I reckon a large part of the problem is also the data-sets that you have to use – being somewhat limited.

And you’re right. The data set is what is causing the limitations. The Muon Software Center, the Ubuntu Software Center and even the Adept Installer all use a package called “app-install-data”, a collection of .desktop files for every app in the repository. (A script goes through each package and searches for .desktop files, and takes the upstream .desktop files and adds information such as what package to install to get this app, their Popcon rating, etc)

Names are dependent on whatever is in app-install-data, and this is usually controlled by the application’s upstream developers.

Unfortunately I don’t think the official Sun JRE package gets an entry as an application in app-install-data. Dunno why that is; perhaps the move to the Canonical parter repository as of late has something to do with this. Perhaps a bug against app-install-data-partner is in order.

This looks pretty awesome indeed. Can’t wait to see it land in Kubuntu~

I have one little request, though: Can you test (and develop, if possible) this using a non-default color scheme? Many KDE apps were written by people using the default one and, as a result, some colors are hardcoded in and look wrong on non-default color schemes/themes. If you do develop using an alternative color scheme (especially white-text-on-black schemes), such things become very apparent.
I am saying this because this application looks color-heavy and might suffer from it. If I had to blame anyone, though, it’d be the Amarok team…

I like the look of it. I did notice that lirc appears many times. This could be confusing. Perhaps the newest version should show up. Or if there is a preferred version, i.e. Kubuntu version, it should be shown.

The reason that 3 Licq’s show up is that there are three different GUIs that Licq upstream supplies. A Qt3 GUI, a Qt4 GUI, and some other one. Their .desktop files all provide the same name/comment, so they’re indistinguishable. This is unfortunately a problem in not only the Muon Software Center, but also in programs like the Adept Installer and the Ubuntu Software Center, which all use the app-install-data package for getting info about which packages are applications.

But since this program will mostly (almost only) be used from KDE 4, perhaps it would make sense when there are different packages with the same name, by default only the qt4/kde4 version is shown? Most KDE users won’t care for the other version and for the others, there could be a setting to show them all.

[…] QApt/Muon Suite 1.1 Beta released As promised, this weekend I am proud to present QApt and Muon 1.1 Beta. Most of the major changes can be found in the 1.1 alpha release announcement. But, of course, the major feature for version 1.1 of the Suite is the new Muon Software Center, which you can read all about here. […]

Screenshots look awesome.
Features: well I never tested muons.
One (tiny request) (asks the oxygen dev): would you consider droping the horizontal separator between the top-right toolbar and the right panel ? I really think it adds nothing (but clutter), and really does not look good if you ask the oxygen windeco to draw a separator between the window title and the window contents (because then both are pretty close, and not centered the same).

The horizontal separator is mainly there to provide a separator between the bread crumb and the contents of the application details widget. (The Application list view provides a frame that does this, but the details view doesn’t)

My fear is that if I remove it there will not be enough separation between the breadcrumb and the details view. Is there another way to do this? (I tried putting a frame on the breadcrumb KHBox, but the styled frame didn’t seem to do anything, and the unstyled frame is pretty ugly.

From the screenshots and descriptions, this sounds like an awesome set of software; very nice work! :) I’ve been following this since I saw a post on Planet KDE, since I’m really looking to replace Synaptic on Debian Testing with something nicer (and this package manager even looks fundamentally better, more secure, and more useful than Synaptic). And I’m more interested in getting my non-technical friend up and running using Muon Software Center on a GNU/Linux/KDE system (either Debian Testing or Linux Mint Debian Edition) that I’ll be setting up for him soon (the only other easy-to-use option I’ve found is Linux Mint’s GTK+-based Software Manager).

I finally got around to trying to use this. QApt built fine once I figured out and installed its dependencies. But I’m having trouble building libmuon, muon, etc. I checked out svn://anonsvn.kde.org/home/kde/trunk/extragear/sysadmin/muon/, went to muon/libmuon/, and ran ‘cmake .’. I found an additional dependency (libdebconf-kde, which I had to get from SVN and built smoothly), and then I got some errors from CMake and Make/GCC about unknown commands and missing files. Ultimately, I found that adding these three lines to CMakeLists.txt (in each target subdirectory of muon) solves those:find_package(KDE4 REQUIRED)
include_directories(${QT4_INCLUDES})
include_directories(${KDE4_INCLUDES})
Now I’m stuck on errors like the following:[ 33%] Building CXX object CMakeFiles/libmuon.dir/DownloadModel/DownloadModel.o
/home/pj/src/muon/libmuon/DownloadModel/DownloadModel.cpp:120:29: error: DownloadModel.moc: No such file or directory
I’ve determined that moc files like DownloadModel.moc are in muon/libmuon/ and GCC is looking for them in (in this case) muon/libmuon/DownloadModel/. So I copied DownloadModel.moc to that directory, tried again, and got the following error:[ 4%] Building CXX object CMakeFiles/libmuon.dir/DownloadModel/DownloadModel.o
In file included from /home/pj/src/muon/libmuon/DownloadModel/DownloadModel.cpp:120:
/home/pj/src/muon/libmuon/DownloadModel/DownloadModel.moc:10:41: error: DownloadModel/DownloadModel.h: No such file or directory
I figured out that Make is probably working from muon/libmuon/DownloadModel/ at that point, so making a new DownloadModel directory under muon/libmuon/DownloadModel/ and copying DownloadModel.h to it fixed the errors for that object.pj@loki1:~/src/muon/libmuon$ ls DownloadModel/
DownloadDelegate.cpp DownloadDelegate.h DownloadModel.cpp DownloadModel.h DownloadModel.moc
pj@loki1:~/src/muon/libmuon$ mkdir DownloadModel/DownloadModel
pj@loki1:~/src/muon/libmuon$ cp DownloadModel/DownloadModel.h DownloadModel/DownloadModel/
pj@loki1:~/src/muon/libmuon$ make
[ 0%] Built target libmuon_automoc
[ 4%] Building CXX object CMakeFiles/libmuon.dir/DownloadModel/DownloadModel.o
[ 8%] Building CXX object CMakeFiles/libmuon.dir/DownloadModel/DownloadDelegate.o
/home/pj/src/muon/libmuon/DownloadModel/DownloadDelegate.cpp:125:32: error: DownloadDelegate.moc: No such file or directory
…So DownloadModel.o finally compiles, and the error recurs on the next compilation. I could repeat these file copies to compile every object file, but that’s tedious and hackish. The underlying problem is that Make is trying to compile from inside a subdirectory. Any idea why this is or how I can fix it?

The muon tarball is meant to be compiled from the root directory of the tarball. None of the folders’ CMakeLists.txt’s are designed to be the top-level part of the build. Running cmake, make, make install from the top level directory will build all the components without the need for hacks. :)

Well Muon 1.0.3 from Launchpad builds quickly and without problems (and without CMakeLists.txt modifications) on Debian Testing. It looks good so far; the reverse dependencies and support for multiple applied filters is great. Not to mention it just looks clean and pretty in KDE. I don’t have much time right now, but I’ll try it out more thoroughly and probably have some more feedback soon enough. :)

Any idea when the Muon PMS (my that’s a rather odd acronym, haha) 1.1.0 branch might be packaged for release? As an alternative until then, it’d be nice if I could get trunk to compile. No rush of course, but I’m anxious to see the Software Center in action, mainly as I said before as a solution for my friend. ;)