QApt/Muon 1.0 released

I am excited to announce the immediate availability of QApt and Muon 1.0.

This marks the point where both QApt and Muon are ready for general use. Here is a list of changes from the release candidate:

QApt 1.0

  • Fixed a crash that occurred when trying to get the version of a package that lacks a version due to APT pinning rules. (Bug 246799)
  • General improvements to the LibQApt API documentation. All public functions and members should be completely and accurately documented as of this point.
  • Think forward a bit and make sure we can handle rare-as-of-now ultra-large packages, the size of which in bytes can not be represented by an int. (E.g. a couple of gigabytes) Use a double instead. (qint64 typedef)

Muon 1.0

Felix Geyer deserves a big thank you, as he is responsible for most of the improvements I am about to list. Thanks again!

  • Select the “All” item in the filter widget views by default for clarity’s sake. Thanks for Felix Geyer for the patch.
  • Improve reliability of clicking on the filters.  (Felix strikes again)
  • As a nice little convenience, if we revert all changes inside the preview widget, Muon will now return you to the main few. (Felix once again)
  • Improve the reliability of the changelog fetching code, reducing the risk of files not getting deleted/the wrong changelog being displayed when quickly scrolling through packages with the keyboard. (Felix)
  • My chance to shine ;) Only listen to progress reports from the QApt Worker if we are actually the one that asked. Otherwise we could try displaying progress from another application such as QApt Batch and crash since we don’t have the progress widget set up.

Packages are available from the usual location, with the exception of Maverick, where things are delayed a bit as I prepare to get Muon in the official archives for 10.10. They should be available by tomorrow if everything goes well. Source for QApt and Muon are available here and here, respectively.

The future

I have some ideas of what I’d like to accomplish for 1.1. Here’s a list of some of them:

  • Implement version locking support
  • Improve the download view, with per-item progress
  • Implement a history log viewer, now that APT has a consolidated history log. (Will require APT from 10.10)
  • Add a configuration dialog for configuring things like whether or not to treat recommended packages as dependencies or not, and other APT settings.
  • “Slow” search that does not rely on Xapian and can search in specific package fields. This would supplement fast search, which will remain prominently in the main GUI. (Slow search will probably only be accessible from a menu in the menubar)

Of course, I’d also like to write a more Software Center-esque custom GUI for application installation. For that I will have to write a parser for app-install-data, and use that parser to filter what is shown in a GUI that is geared towards the technically non-elite. I’ll also have to figure out a clever way to limit the Xapian quick search to the applications. I am a bit unsure how to accomplish this as of yet.

So, enjoy Muon. QApt will be getting a bit of use via QApt Batch in 10.10, but until 11.04 we really need to test the heck out of QApt and Muon to ensure that Muon will be a good choice for inclusion by default in 11.04. (It’s not that I doubt that they are good and ready now, but every single time we have jumped on the latest and greatest it’s come back to bite us, even if it was a popular decision beforehand.) If we can make sure that they are good, we will ensure that they rock for 11.04. :) Muon will be available for install in the official repositories for 10.10, so there is no excuse to go out and test it while waiting for 11.04. ;)

Thanks, and enjoy.

About these ads

31 Responses to QApt/Muon 1.0 released

  1. binarylooks says:

    Great. I’ll test it.

    The “usual location” link is wrong

  2. David says:

    First off I am delighted with Muon and have already made it my own default. Many, many thanks!

    I have only one issue with it which isn’t really a bug as such hence mentioning it here rather than via a bug report. The timeout for some repositories to respond seems too short…for instance multiverse often times out for me. Perhaps a user selectable way to vary this would be the best option?

    • This is determined totally by APT itself, so I don’t think there’s anything that can be done from the QApt end of things. :(

      • David says:

        Odd…as when I run KPackageKit to do the update of any medibuntu items there is no timout. Unless I’m missing something then they’re both front ends for APT yet one times out on almost every run and the other works.

  3. David says:

    Actually it’s medibuntu.org that always times out for me…kKubuntu user.

  4. Anonymous says:

    Looks nice – finally a reason to switch away from apt-get? :)
    Could you maybe improve the status bar a little bit though, getting rid of this ugly border?

    Somewhat off-topic: which plasma theme are you using?

    • I think the border looks nice. (At least in Oxygen) It could be a bit visually “heavy”, I suppose, but I would need to find a better way of grouping the persistent data and the data that shows up in the second grouping once a package is marked for install/removal… I will think on it. :)

  5. tidbeck says:

    I’m reading the planet from time to time. I often find announcements about some new release of an application, in this case QApt. In 80% of the case I don’t know what kind of application this is, maybe it would be a good idea if all blogs of this kind started with a small summary of what kind of application it is.

    Just a thought. Keep up the good work!

    • Ah, you are totally right. Perhaps I should have linked to the first blog I did on the subject: http://jontheechidna.wordpress.com/2010/07/05/introducing-qapt-and-the-muon-package-manager/

    • Kubuntiac says:

      The number of times I’ve wished people would do that in every blog post about a project… Heh, maybe planet.kde.org needs a plugin to automatically detect project names from a list and link the appropriate url if there isn’t one already there…

      Now that would be cool… :)

      • skierpage says:

        Here’s the boilerplate message I submit to developers whenever they breathlessly announce “QuakkGitozonkon 1.3.3 is out with lots of bug fixes and a new fromulgat engine from BarryO.”

        1. You are the marketing department for your app. 2. You never know who will come across your announcement, and you never get a second chance to make a first impression.
        So the second sentence of every announcement and blog post HAS to be a one-sentence overview of what QuakkGitozonkon does. It’s a good exercise to come up with a crisp meaningful overview and no one will begrudge you the repetition.

  6. g says:

    Thank you very much for this nice software. The GUI is much better than that of adept or kpackagekit. It looks as if I am finally getting rid of synaptic.

    I would like to suggest the following improvements:
    – when clicking an item in the list of packages a panel with details, dependencies, … appears. It would be nice if there would be a way (other than restarting muon) to collapse this panel again.
    – I like in synaptic that there is a column in the list with the number of the currently installed and the latest available version. These columns don’t need to be visible by default, but I would like to be able to right click the list header and add those columns. I know this information is available in “Technical Details” but it is harder to lookup than when the information is on the same line in the list.

    • - Yeah, a way to close it would really be helpful. I’ll put it on the todo list.
      – A lot of neat info could go there. I’ll put that on the list, too. (Though I think I will keep what’s currently there as the default view)

  7. Kubuntiac says:

    Seems beautifully fast! Nice work!

    a) Doesn’t seem to add itself to the KDE menu (Kickoff?)

    b) Vertical tabbed left column is sweeet :0) (and fast!)

    c) Re-ordering the top menu buttons could increase usability as users tend to:
    1. Update 2. Choose Upgrade 3. Preview changes, and then 3. Apply

    Where it’s currently ordered:
    1.Preview Changes 2. Apply 3. Update 4. Upgrade

    d) Being able to browse by origin is a neat idea, so you can actually tell whether that version of the kernel you’re using came from Main, or ppa:/dodgy-bob/extremely-unstable ;)

    e) When updates are available, I expect to be notified in the app somehow. I’d suggest automatically switching to “By Status” -> Upgradable automatically when an update first finds upgradable packages.

    f) I LOVE that it says *with text* what has been requested for packages. I’m a designer, but even I had trouble seeing the difference between the blue “request install” and the grey “do nothing” arrow icons in Kpackagekit.

    g) With the Glide Kwin effect turned on, the authentication window often appears behind the main window, which makes it look like the app hung as the dialogue is modal, but you can’t see it. (Kpackagekit does the same)

    e) Warning you before uninstalling system-critical packages is an _magnificently_ good idea!

    f) Wishlist: Queing. eg the ability to tell Muon – when it’s busy installing 30 other packages – to also install package foo and remove package bar when it’s done.

    I’m really curious where the name Qapt comes from, but Muon? Anyway, considering how new it is, it looks like Muon / Qapt are going from strength to strength. Looks like you’ve created a very solid base to build on, and I look forward to helping test it out!

    • a) It’ll show up once you run kbuildsycoca4 or restart KDE. This is something that must be done after installing any KDE app, and has been so for as long as I can remember. :(
      b) :)
      c) I’ve been pondering rearranging things, stay tuned.
      d) :)
      e) An update-centric GUI is a really big item that I forgot to add to the list. Some sort of notifier would also be in order…
      f) Yeah, that’s been a peeve of mine too.
      g) This is a problem with the KDE PolicyKit GUI. Fixed in trunk, and will be available whenever the PolicyKit-KDE-1 maintainer does another release.
      e) Something really major that neither Adept nor KPackageKit never did/does, but quite vital, I agree.
      f) Might be tricky. Probably would go quite low on the todo list as far as things go.

      Q = Qt, Apt = the APT package library. Muon is a subatomic particle, as is the current fad for naming KDE applications. Cows also go “moo”. (Though “Mu” is pronounced more like “mew”) ;)

      • Kubuntiac says:

        re: a) I’ve *never* use kbuildsycoca after installing an app, and I usually see most apps appear in my menu about 2 seconds after the package manager says it’s installed… I have a habit of opening Kickoff and starting to type the name just as it’s about to finish installing. It’s usually not visible until the 5’th-7’th character. I wonder if other packages run kbuildsycoca or something as a post install script…

      • Typing in the name is different than it being in the internal menu structure, where you can find it without searching. In 4.4 and beyond, Kickoff uses Plasma Runners for searching. When you search for an installed application in Kickoff/KRunner, you will usually get two results. One is when the .desktop file of the application is registered with KDE’s sycoca cache. The other basically checks /usr/bin/ (well, technically $PATH) for a binary matching that name. If you typed within seconds of installing the package, you’d see the executable Runner give results for /usr/bin/muon (with the generic gear symbol) but you would not see the Muon entry in the menu structure until the sycoca was refreshed.

  8. Kubuntiac says:

    That last paragraph should have read:

    >>I’m really curious where the name Muon comes from. Qapt is pretty obvious, but Muon?<< Anyway, considering how new it is, it looks like Muon / Qapt are going from strength to strength. Looks like you’ve created a very solid base to build on, and I look forward to helping test it out!

  9. takanowaka says:

    congratulations to the first stable release ;)

    i’d like to know what’s the connection between qapt/muon and packagekit. is there any or does this mean that (k)ubuntu is leaving packagekit behind?

    and one ui thing: muon seems to rezise itself (just a little) randomly when i’m changing between the packages or repos etc.

  10. jonsi says:

    I’m really excited at Muon, finally I can get rid of Synaptic (maybe ;) )

    But the real deal is a KDE implementation of the Software Center concept, I just can’t wait for that!

  11. Many thanks for working on this, KPackageKit is one of Kubuntu’s weaknesses and it’s great to read that Muon could possibly replace it in 11.04 (if I interpret it correctly).

  12. AdeBe says:

    Aaahhh… fantastic :-)
    One question though: when will it be available in Debian repositories (or at least Debian packages will be provided)?

    • Somebody will have to step up and provide a Debian repository. The Kubuntu packaging should build just fine in Debian Sid, but I do not have the setup necessary to provide Sid packages that are guaranteed to work. :(

  13. Alejandro Nova says:

    This shows that Kubuntu is less and less a third rate KDE distro. Congratulations. It was hard, but it’s paying off. Surely I’ll test the Meerkat. Also, that MacOS-like menu looks great.

  14. Stimpson J. Cat says:

    G R E A T package manager ui

    btw, just tried 1.0 and the “Package” column has a fixed size making that the program need to be a bit wide (wasting space in the center) if dont want to squeeze the filter part, can be a problem for small screens

  15. contrast says:

    A million thanks to you for your fine work, kind sir. I’m practically giddy right now over this– FINALLY, a native package manager that doesn’t suck. Well, that’s an understatement; Muon is arguably the second best Debian-based package manager out right now, and in such a short period of time. Keep up the awesome work! :D

  16. Yuri sss says:

    Hi, please take a look at my suggestions in the Kubuntu forum thread:

    http://kubuntuforums.net/forums/index.php?topic=3113145.msg237945#msg237945

    Imo it is a very poor design choice to waste two colums on *text* descriptions of “Status” and “Requested”, this would be much better done with icons. Clear, concise icons of course, not bad ones as in Kpackagekit. I’ve done some icons for that purpose, see the forum link above.
    The space freed up by that would be much better to be used by columns for “Dowload size”, “Installed Version” and “Avaiable Version”, which current Muon is still lacking.

    I’ve photoshopped an image of how I think it would look best here:

    http://img801.imageshack.us/i/muonmockup.png/

  17. […] apropå KPackageKit, det ska ju bytas ut i framtiden mot Muon Package Manager, fast förmodligen inte förrän i Kubuntu 11.04 (som för övrigt ska heta Natty […]

  18. […] Here’s a list of what’s changed since 1.0. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 25 other followers

%d bloggers like this: