Okay, I’ve added the needed stuff in desktop-file-utils for the yum backend to pick up the virtual mime-type provides in rpm with the help of hadess. Now all we need is a new rpm version with support for this, and then for rpm based distros (e.g. Fedora) it should just work. For Ubuntu the data is already present in the ton of desktop files that are shipped in gnome-app-install – and I’m sure it will be easy to get at this data in the apt2 backend. Other distros will have to work out how to do this, although I’m sure one of the existing methods will be easy to adapt.
So, enough of the geeky. What do you all think of this:
Code about to hit master…
Comments?
Published by
hughsie
Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management.
Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.
View all posts by hughsie
Is there no way to pick a sensible default? The Ubuntu codec helper likewise thinks that presenting a user with a list of random gstreamer plugins is more useful than just presenting one.
– Chris
You know what… that’s somewhat excellent. Being able to offer users relevant applications on demand as needed as something I’ve wanted to see for a long time.
Any chance you could end up adding hooks into mugshot so that the applications are ordered by usage statistics pulled from mugshot?
I guarantee you when my wife runs into this for the first time on her desktop install..she’s gonna love it.
-jef
Excellent! Is it filemanager-independent? I’d love to be able to use this in Thunar.
>adding hooks into mugshot
Yes, I’m toying with this idea – or maybe just using comps. One to sleep on I think.
>Is it filemanager-independent?
Yup, you just need to add:
#include <dbus/dbus-glib.h>
DBusGConnection *connection;
DBusGProxy *proxy;
GError *error = NULL;
gboolean ret;
connection = dbus_g_bus_get (DBUS_BUS_SESSION, NULL);
proxy = dbus_g_proxy_new_for_name (connection,
“org.freedesktop.PackageKit”,
“/org/freedesktop/PackageKit”,
“org.freedesktop.PackageKit”);
/* execute sync method */
ret = dbus_g_proxy_call (proxy, “InstallMimeType”, &error,
G_TYPE_STRING, “text/plain”,
G_TYPE_INVALID, G_TYPE_INVALID);
if (!ret) {
g_warning (“failed: %s”, error->message);
g_error_free (error);
}
The rest you can leave up to PackageKit. You’ll have to be running the gpk-update-icon applet to make it do the right thing – without that you’ll have to use the system service and do all the EULA and GPG interactions yourself.
>Is there no way to pick a sensible default?
I’m thinking of using the popularity as the list ordering. Not sure how yet.
Looks great :)
.desktop files coming from Ubuntu app-install-data package have the X-AppInstall-Popcon field, which should be the popularity counter (but I can’t find any info on the web).
The actual filetype should be mentioned in the title instead of referring to it ambiguously as “this” file type.
comps hooks don’t get you a way to rank options.
mugshot’s application usage stats give you an intuitive way to deal with ordering the options.
I wouldn’t offer a one-click of the most popular unless you make some attempt to figure out if someone is most likely to want the qt/gtk/other application based on what they themselves currently run.
Long term vision:
There’s a lot of room to make better use of the data mugshot collects concerning application usage to help users find applications that best fit their usage pattern by correlating their usage to other mugshot users. So instead of just looking at what is most popular across the whole userbase, you can correlate your current usage to other users to end up weighting users who are most similar to you in the popularity metric. So KDE users would end up getting a list of applications weighted such that other KDE users choices more strongly influence the ranking. You could then end up presenting the most highly ranked app from this advanced mugshot correlation as the first app in the list or even the default app to install without a list. You could feel pretty comfortable that its the most likely app that a person would want, based on the correlation datamining from other users.
-jef
Looks great except for a few things. For the geekiest of us we like the package name and description but for someone who just want to open a file I think a name, a short description and a familiar icon whould help a lot. Maybe even a link to the programs website to read more. Lots of data I know, so not all of this would be in the list, below could work…
Also this dialog would be nice to have when doing “Open with” and to be able to install another program then the ones installed, ie you were not happy with your first choice…
M
Yeah… tying this functionality into “Open with” would make a lot of sense. A great way to help casual users explore the applicationscape without getting lost.
-jef
What is (i386) ?!
/me ducks
Cool. However what extra value does showing package names produce for end users? It’s not like if anyone understands what those mean.
I’d like to have access to the detailed metadata of the packages that are proposed in the dialog. At least the dependencies and the long description are essential, as they would let me decide myself the application I want to install.
Even if there was a way to find a sensible default, I think this would be useful.
Thanks for your work on this Richard. I have a couple of comments from a non-coder point of view:
1. The title bar should read “… type of file”, not “… file type”
2. Echoing the comments above, the name of the program is most important to users, followed by a description. The file name of the package is least important of all. Perhaps it could be displayed by additional action? Like a mouse click or hover?
Splitting apps into two piles, those that are read/view-only and those that can edit and save again would be nice, if possible.
People using the desktop generally want to do one of three things to a file : View(only) it, Edit it and Print it. It’s possible to do this with most applications at launch via the command line switches, so why not include View, Edit and Print buttons on the left side of each application choice entry.
Wow! Love it!
If the applications is ordered by rank, the dialog should somehow reflect this, to prevent normal users from “panicking”. E.g mark the top rated/ most used application with “most popular”, “default” etc.
A “details”-button would really help too..
In my opinion, the two lines should be “name”, “features”. Most people are not interested in the package name. That would belong in “details”.
Does it actually open the file once the new package has finished installing, or does the user have to double-click on it again?
>Does it actually open the file
At the moment, no. It could take quite a long time to download something like openoffice, so we probably shouldn’t randomly start opening something 20 minutes after the user tried to open it.
For Debian-based distros, the debtags data (see the Tags: in Packages) seems much more suited than using desktop files. I’m not sure how mime-types are mapped to works-with-format:: though.
Like a few other people have mentioned, you might want to suggest a sensible default. Within the gnome or KDE environments, you might want to have an option to toggle the display of non GTK+/QT applications for the sake of better desktop integration and all that.
I am thinking about music players especially here, there are a million in the repos, and perhaps suggesting the most popular for the current desktop environment would be the best for the user, who doesnt know their rhythmboxes from the banshees.
Debian has popcon.debian.org, IIRC Ubuntu has their own server for that. On Debian, libept can associate popcon data with individual packages.
How does this work when there is no network connection?
Will it just display the “Open With” window instead?
It would be simply wonderful!
@jef spaleta
Even assuming mugshot sampling was not hopelessly biased, popularity stats only give you the current state. Ordering by popularity would thus be a major drag when new features are introduced and the distro really wants users to move from application A to application B.
So you need a layer when the distro can explicitly specify “the preferred app for foo use is A B or C”. Currently our layer for this is comps (that’s what all the default required optional etc stuff is). Now current comps syntax may not be rich enough for PK use, but that just means comps must be extended (or replaced by something else. There is no room for X different package classification files in the distro.
Hi Richard, a little offtopic here. I’d like to help with Russian localization in my spare time but can’t find a POT file in the tarballs. Moreover, the POT file doesn’t seem to get built when I run make. Where can I get it? Can you make it available in the tarballs with future releases?
Artem:
cd po
make PackageKit.pot
Thanks, Richard!