Selecting default application in System Settings does not present predictable results.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gnome-control-center (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Beginning with 13.04 I've noticed that Ubuntu has been a little unpredictable with selecting the default application, particularly for videos. I have Totem, VLC, and SMPlayer installed. I am not able to change the default video application properly. Earlier I had these findings:
Selected VLC to be default video player. Closed/reopene System Settings - Details - Default Applications. Totem was still default. I installed SMPlayer, and somehow was able to have success with setting SMPlayer as default. Once done, I tried to change the default away from SMPlayer. I changed it to Totem and closed/reopend System Settings. SMPlayer was still default. Changed to VLC and closed/reopend System Settings. SMPlayer was still default. I did an apt-get remove --purge smplayer, and now Totem was the default. I changed to VLC, closed/reopened, but Totem was still default.
I'd like to point out that if I right click on the file and go to Properties - Open With tab, I can successfully select the new default application for that file type without issue. (at one point I did have to hit "reset", as even then it wasn't allowing me to change the default, but since then everything has worked fine)
Bottom line, System Settings does not allow me to select the default video application properly, as it doesn't seem to accurately change the settings as an end user would expect.
ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: gnome-control-
ProcVersionSign
Uname: Linux 3.8.0-19-generic x86_64
ApportVersion: 2.9.2-0ubuntu8
Architecture: amd64
Date: Mon May 6 13:41:39 2013
InstallationDate: Installed on 2013-04-30 (6 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: gnome-control-
UpgradeStatus: No upgrade log present (probably fresh install)
usr_lib_
activity-
deja-dup 26.0-0ubuntu1
gnome-
gnome-
indicator-datetime 12.10.3daily13.
I think I worked out at least part of the problem, so might not be a gnome-control- center bug after all. gnome-control- center uses the mimetype "video/x-ogm+ogg" to determine the default Video app in Default Applications. SMplayer does not have this mimetype in its smplayer.desktop file, but instead has "video/x-ogm". None of the other video players that I see have that specific mimetype in their .desktop files, so when gnome-control- center sets the default for the mimetypes present in the .desktop file, a line: video/x- ogm=smplayer. desktop will still exist in ~/.local/ share/applicati ons/mimeapps. list.
The curious part is why should it care? It asks for "video/x-ogm+ogg", which is set correctly. The problem is that when glib loads the mimetypes from mimeapps.list, it calls a function xdg_mime_ unalias_ mime_type( ) on "video/x-ogm", and as it happens, /usr/share/ mime/aliases has a line "video/x-ogm video/x-ogm+ogg". So if "video/ x-ogm=smplayer. desktop" happens to appear later in mimeapps.list, it will end up overwriting the true default value in the hashtable.
I find that if I change the mimetype in smplayer.desktop to "video/x-ogm+ogg" and delete the "video/ x-ogm=smplayer. desktop" line from mimeapps.list, then gnome-control- center will again correctly let me switch between totem, vlc and smplayer as defaults. So that might be a fix, in smplayer instead. Might be a bit fragile though, since if another app comes along doing the same thing, it will expose the same bug.