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 KRatingPainter optimizations. 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.
Stay tuned for the update this weekend, and thanks for reading.
Jonathan's Blog 
[…] This post was mentioned on Twitter by Bobby and Hexley, Hexley. Hexley said: Jonathan Thomas (JontheEchidna): “Muon” is now the Muon Package Management Suite: Starting with version 1.1, “Mu… http://bit.ly/g0NY0t […]
Really nice work! do you know is this will be available in kubuntu 11.04?
Yep, it will be.
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
It does this automatically. Only the latest version of an application is ever shown.
You should move the items of the sidebar inside the widget that display categories.
“Installations and removals can be queued”
*squeals of girlish glee!*
Geez, I’m a geek! 😛
In the application lister, not installed softwares are represented by a “package and cd” icon ? It seems more difficult to identify a software.
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.
Awesome job! It’s look better than KPackageKit.
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.
Oh, that’s nice :p
Could Muon then provide those notifications or more importantly have you thought of adding such feature?
Looks awesome 🙂
Could you maybe replace the arrows in the breadcrumbs bar (->) by the ones used in other places of KDE (>) (if it makes sense to do so)?
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 :))
will be default in Natty?
This depends on the decision of the elected Kubuntu Council. (Though obviously I would personally like for it to be :))
I hope 😀
It is really nice, congratulations!
Awesome work, keep it up!
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.
Here’s what the Muon Software Center shows: http://i.imgur.com/NGbpt.png
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.
Perhaps if you got a result with something like a directory structure that could be folded out/in:
– OpenJDK Java
** OpenJDK Java Runtime environment (JRE)
** OpenJDK Java Development Kit (JDK)
** OpenJDK Java Webstart
** OpenJDK Java etc.
– Sun Java
** Sun Java Runtime environment (JRE)
** Sun Java Development Kit (JDK)
** Sun Java Webstart
** Sun Java etc.
* etc
* etc
–Pascal
I happened to be reading the comments just as you posted. 😉
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…
Nope, no hardcoded colors here. 🙂
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).
Just my two cents. Ignore if you have good reasons to keep it.
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.
Awesome. Can’t wait to see where this goes. Like where it is already.
Damnn, such a nice looking suite of apps 😀
I wish we could make this available for RPM package managers like yum and smart, that’d make this a whole lot cooler.
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.oIn 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?
Sorry for the long post, and if this should be posted to http://bugs.kde.org/ let me know.
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. 🙂
Thanks for the (quick) reply. I thought that was the case, and I did initially try building from the root directory. But ‘cmake .’ produced no Makefile. This is all I have:
pj@loki1:~/src/muon$ lsChangeLog CMakeCache.txt CMakeFiles CMakeLists.txt CMakeTmp cmake_uninstall.cmake COPYING COPYING.GFDL installer kded libmuon Messages.sh muon README TODO updater
pj@loki1:~/src/muon$ make
make: *** No targets specified and no makefile found. Stop.
‘cmake .’ in the root directory did complete with ‘Build files have been written to: /home/pj/src/muon’. There was one error though, but I’m not sure how relevant it is:
-- Configuring doneCMake Error in installer/CMakeLists.txt:
Cannot find source file "Transaction.cpp". Tried extensions .c .C .c++ .cc
.cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx
Any idea why no Makefile is produced? Should I be using the tarball (which I guess is Muon 1.0.3?) instead of the trunk source?
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. 😉
That looks fantastic. Great work.
Meh; it’s okay. I just feel that KPackageKit hasn’t failed its job. Hopefully it does hide indicators of progress like how KPackageKit does.
Having 1.2.1 in Kubuntu 11.10, I don’t see the history view anywhere? Is it there, did it ever make it in, or was it removed?
Pressing Ctrl + H, or going to View -> History should do it in the Muon Package Manager. Cheers!
Looks like I was opening Muon package manager, instead of the muon software center, so nevermind!
How can i get the muon software manager in 10.04?
I have added the ppa, and backports… Then installed muon but can only open and get the packet manager and not the software center.
How come?