GNOME Bugzilla – Bug 747706
"Open with other application" will set selected application as default
Last modified: 2018-05-24 17:46:40 UTC
With update to 3.16 the context menu "Open with other application" was removed. Option is still there, but it was transformed into a dialog, which will set the selected application as a default for the selected file type. I see this behavior as problematic, for following reasons: 1. It greatly reduces the usability. Here's an example when working with photos: To view and browse image files Eog is a good default choice, but occasionally when photos are being edited, Gimp is used. For this purpose, "Open with other application..." was a great shortcut. 2. It's duplicated. Same functionality can be found in properties dialog, two clicks away. 3. It's a rarely used, advanced feature placed in a commonly used menu. Right click menu contains often used tasks like copying, moving, renaming and deleting. Switching a default application for particular file type is not exactly a common task. 4. It's inconsistent with other DEs and OSes. Both Windows and OSX have such menu, and in both cases the behavior is consistent: open with different application, but don't set it as default, hence... 5. ...it's a bit misleading. User could (and most likely would) think that this will open file with other application only in this instance.
I totally agree with Marko. I used this option nearly every day, especially for editing images. It's a big loss of usability and I see no benefit in the new behavior.
it doesn't make the application as default here... and it shouldn't afaik. The docs doesn't say so. Not sure what's happening there.
I've tested it again, and it's kind of a confusing right now, it seems something was fixed, because image formats now do behave correctly, however... Files with extension .md (markdown), current default gedit. I select Mousepad from the list. Default is changed to Mousepad. File with extension .png, current default eog. I select My Paint from the list. Default is kept (eog). File with extension .mp4, current default SMPlayer. I select MPlayer from the list. Default is kept (SMPlayer). File with extension .sh, current default gedit. I select Kate from the list. Default is changed to Kate. ... Version is: GNOME nautilus 3.16.1
Can confirm this. It's a PITA having to open up the same image twice just to have the damn default app correct.
PITA indeed. I agree with @Marko. Moreover, what he describe is of application to any file type.
It doesn't do that for me with any type of files. There is something odd here. I'm not even sure what to ask to be able to reproduce.
To reproduce: 1.- Create a new user and login (juts to be sure no old conf interferes). 2.- Open Nautilus/Files. 3.- Right-click on any file (.txt, .mp4, etc.); a contextual menu will appear. 4.- Click on "Open with another application..." (no longer contextual); a window will popup. 5.- Upon selection, the corresponding application opens AND the file association is set as default.
Any advance after the procedure I added?
(In reply to CedricMC from comment #8) > Any advance after the procedure I added? Working as expected here following your steps. The default app is not changed. What distro do you have? I really don't know what to ask to figure out what's going on.
@Carlos Soriano I'm using Arch
are all of you using arch? if so, arch or Antergos?
I'm on pure Arch
Yep, I'm using arch too (no derivate). On my machine the default app gets changed for all filetypes except *.png If i create a new user, the default app gets changed for all filetypes I tested. Including *.png files. Strange...
Yes, _pure_ Arch here too.
I tested on Ubuntu Opensuse and fedora 22 and fedora 21. It works as expected. So seems this is an arch issue. I took a look at the code both for nautilus and gtkappchooser. Nautilus just calls g_app_info_get_default_for_type for know the default app, and gtkappchooser has nothing that sets the default app. Are arch repos applying some downstream patch or something? Moving to gtk+ for now. But I guess we will need someone with arch to debug this I'm afraid.
Nothing on nautilus package... https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/nautilus btw, if it matters, I'm using Nautilus on another DE that is *not* Gnome.
No patches on gtk3 either: https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/gtk3 I'm running GNOME 3 and I have this bug. It's a pretty old Arch install; It's been being steadily upgraded since mid 2010.
Created attachment 303286 [details] screencast 1. I attached a screencast of my fully updated Arch that illustrates the bug. 2. I've tested Fedora 22 Beta 3 Live ISO. It behaves almost equally as my system except that it does not associate the selected application. 3. I've also tested a fully updated CentOS 7. Before opening the gtkappchooser, it shows the customary "Open with" contextual menu with the secondary file associations. At the gtkappchooser, it as well does not associate the selected application. 4. In both cases, Fedora and CentOS, there is a "Find more apps on the inet" button at the gtkappchooser which does not appear in the Arch scenario. 5. In both cases, Fedora and CentOS, I haven't seen a way to associate an application to a particular file type. 6. From all the scenarios, the best or nicer behavior would be a combination of CentOS+Arch, "Open with" contextual menu (for fast opening alternatives) with file association at the gtkappchooser.
(In reply to CedricMC from comment #18) > Created attachment 303286 [details] > screencast > > 1. I attached a screencast of my fully updated Arch that illustrates the bug. > > 2. I've tested Fedora 22 Beta 3 Live ISO. It behaves almost equally as my > system except that it does not associate the selected application. > as expected except the part of arch showing this issue. > 3. I've also tested a fully updated CentOS 7. Before opening the > gtkappchooser, it shows the customary "Open with" contextual menu with the > secondary file associations. At the gtkappchooser, it as well does not > associate the selected application. > as expected. > 4. In both cases, Fedora and CentOS, there is a "Find more apps on the inet" > button at the gtkappchooser which does not appear in the Arch scena That happens if you dont gnome-software installed, but I already make sure looking at the code that it has nothing to do with the bug. > > 5. In both cases, Fedora and CentOS, I haven't seen a way to associate an > application to a particular file type. yeah the problem is not with fedora or centos or ubuntu or opensuse, but with arch (maybe missing something in your installation? strange configuration? we overkill something? no idea). > > 6. From all the scenarios, the best or nicer behavior would be a combination > of CentOS+Arch, "Open with" contextual menu (for fast opening alternatives) > with file association at the gtkappchooser. Well, the decision was to just not duplicate functionality and not use a submenu, the gtkappchooser doesn't associate default application so it has the same as the previous "Open With" submenu.
(In reply to Carlos Soriano from comment #19) > > 5. In both cases, Fedora and CentOS, I haven't seen a way to associate an > > application to a particular file type. > yeah the problem is not with fedora or centos or ubuntu or opensuse, but > with arch (maybe missing something in your installation? strange > configuration? we overkill something? no idea). From here two questions arise: a) Why "Arch" saves the association (or selected app) as default while the others don't. b) How do you save an association as default in Fedora/CentOS? > > 6. From all the scenarios, the best or nicer behavior would be a combination > > of CentOS+Arch, "Open with" contextual menu (for fast opening alternatives) > > with file association at the gtkappchooser. > Well, the decision was to just not duplicate functionality and not use a > submenu, the gtkappchooser doesn't associate default application so it has > the same as the previous "Open With" submenu. I understand what you mean but, as Marko pointed out, many of us believe the current solution is not a good solution. Currently and beside of CentOS, there is no quick way to open a file with an alternate application. Up to now, a contextual submenu for the secondary file associations has shown to be the fastest and more practical one. The gtkappchooser may be a good solution to add further secondary file associations or select a new default. This would be the CentOS+Arch solution I mentioned before and I believe it should be a topi of discussion.
(In reply to CedricMC from comment #20) > (In reply to Carlos Soriano from comment #19) > > > > 5. In both cases, Fedora and CentOS, I haven't seen a way to associate an > > > application to a particular file type. > > yeah the problem is not with fedora or centos or ubuntu or opensuse, but > > with arch (maybe missing something in your installation? strange > > configuration? we overkill something? no idea). > > From here two questions arise: > > a) Why "Arch" saves the association (or selected app) as default while the > others don't. > That's the issue we are trying to figure out, but I think we need someone from arch to debug. As I said, could be something you are missing or some configuration, or something we overkill, no idea. > b) How do you save an association as default in Fedora/CentOS? > There's no UI for this afaik except the control center->details which is for some applications. > > > 6. From all the scenarios, the best or nicer behavior would be a combination > > > of CentOS+Arch, "Open with" contextual menu (for fast opening alternatives) > > > with file association at the gtkappchooser. > > Well, the decision was to just not duplicate functionality and not use a > > submenu, the gtkappchooser doesn't associate default application so it has > > the same as the previous "Open With" submenu. > > I understand what you mean but, as Marko pointed out, many of us believe the > current solution is not a good solution. Currently and beside of CentOS, > there is no quick way to open a file with an alternate application. Up to > now, a contextual submenu for the secondary file associations has shown to > be the fastest and more practical one. The gtkappchooser may be a good > solution to add further secondary file associations or select a new default. > This would be the CentOS+Arch solution I mentioned before and I believe it > should be a topi of discussion. This bug is not about that, so please report a new one for nautilus (gtk+ bugs are followed by far by more people than nautilus, so better to keep the comments as less as possible), althougth I can't see the advantage or a submenu vs dialog.
Before leaving this discussion, just the answer to your question: the advantage or a submenu vs. dialog is speed, agility and usability as pointed about my Marko in the 1st bullet point of his opening commentary or by myself in the last paragraph of my previous commentary. Cheers!
(In reply to Carlos Soriano from comment #21) > There's no UI for this afaik except the control center->details which is for > some applications. > The ui is in nautilus' file properties dialog, in the open with tab.
(In reply to Matthias Clasen from comment #23) > (In reply to Carlos Soriano from comment #21) > > > There's no UI for this afaik except the control center->details which is for > > some applications. > > > > > The ui is in nautilus' file properties dialog, in the open with tab. ah right!
Ok, I investigated a little more. So questions for reporters are: - Do you have installed the package shared-mime-info? - Can you locate where your default application list is? Generally is in /usr/share/applications/defaults.list or /usr/share/applications/gnome-mimeapps.list and the user config is determined by freedesktop standard as http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html and generally is located in $HOME/.config is that env variable is not set.
*** Bug 738855 has been marked as a duplicate of this bug. ***
$ pacman -Qi shared-mime-info Name : shared-mime-info Version : 1.4-1 Description : Freedesktop.org Shared MIME Info Architecture : x86_64 URL : http://freedesktop.org/Software/shared-mime-info Licenses : GPL2 Groups : None Provides : None Depends On : libxml2 glib2 Optional Deps : None Required By : blender brasero cmake gnome-mime-data gtk2 gtk3 kcoreaddons kdelibs keepass libmirage libreoffice-fresh vinagre Optional For : None Conflicts With : None Replaces : None Installed Size : 4,24 MiB Packager : Andreas Radke <andyrtr@archlinux.org> Build Date : Dom 15 Fev 2015 16:23:39 AZOT Install Date : Seg 16 Fev 2015 02:55:43 AZOT Install Reason : Installed as a dependency for another package Install Script : Yes Validated By : Signature I don't have a "system" application list (no defaults.list nor gnome-mimeapps.list). I only have $HOME/.config/mimeapps.list
$ pacman -Qs shared-mime-info local/shared-mime-info 1.4-1 Freedesktop.org Shared MIME Info $ find {/usr,/home} -name "*.list" 2> /dev/null /usr/share/doc/gnupg/examples/pwpattern.list /usr/share/gdm/greeter/applications/mimeapps.list /usr/share/applications/defaults.list /usr/share/autoconf/autoscan/autoscan.list /home/cedricmc/.local/share/applications/mimeapps.list /home/cedricmc/.config/mimeapps.list $ pacman -Qo /usr/share/applications/defaults.list error: No package owns /usr/share/applications/defaults.list $ find {/usr,/home} -name "mimeinfo.cache" 2> /dev/null /usr/share/applications/mimeinfo.cache /home/cedricmc/.local/share/applications/mimeinfo.cache $ pacman -Qo /usr/share/applications/mimeinfo.cache error: No package owns /usr/share/applications/mimeinfo.cache $ pacman -Qo $(which update-desktop-database) /usr/bin/update-desktop-database is owned by desktop-file-utils 0.22-1 As stated in Arch's wiki, mimeinfo.cache is generated by update-desktop-database upon package (un)installation. I do not know who is in charge of the deprecated defaults.list. https://wiki.archlinux.org/index.php/Default_applications
I have the same situation as comment above (Carlos Silva) described: shared-mime-info-1.4-1 is up to date ➜ ls -la /usr/share/applications/ | grep .list (No results) ➜ ls -la .config/mimeapps.list -rw-r--r-- 1 marko marko 1406 May 16 00:03 .config/mimeapps.list ➜ ls -la .local/share/applications/mimeapps.list -rw-r--r-- 1 marko marko 5287 May 14 13:30 .local/share/applications/mimeapps.list
Any news here? It has been over 6 months now, and that horrible… awful… catastrophic change has landed in Debian testing (nautilus is 3.18.1 here currently). I have exact same symptoms as reported in april by Arch users - no more 'Open With...' menu entry, and the horrible two-steps 'Open with another application' entry which always changes default app for some file types and not others. nautilus: 3.18.1 shared-mime-info: 1.5-2 $ ls -la /usr/share/applications/ | grep .list [nothing] $ ls -la .config/mimeapps.list -rw-r--r-- 1 i74700deb64 i74700deb64 908 déc. 14 19:26 .config/mimeapps.list $ ls -la .local/share/applications/mimeapps.list -rw-r--r-- 1 i74700deb64 i74700deb64 378 sept. 21 2014 .local/share/applications/mimeapps.list
No news, it works fine here in Fedora...no idea what can it be. Probably the best option is to someone in those systems to debug the issue... You can debug using the test on gtk+ named testappchooser. And test if it changes your default app with different file types, and why. Also, fwiw seems in Ubuntu it works fine as well.
*** Bug 757960 has been marked as a duplicate of this bug. ***
Created attachment 326711 [details] [review] gdesktopappinfo: don't consider associations for default app When we request a default application for a mime type, the associations are taken into account as well. That means, if an app doesn't have a default application, will take the first application that appear in the list of applications that handle the mime type. This is problematic though, since the order of the associations change. Not only that, but clients of this function has no way to check whether there is really a default application set for the mime type or not, making impossible for the client to handle this situation. This causes issues like users opening a file with some application, and that application becoming the default. This patch removes the associations from the default app handling.
So there are two problems here: One is that glib returns a default app when there is none associated, I guess for convenience, and when the user opens the file with that app, it puts it in the top, becoming the default. The previous patch removes that, so the users will see no default application and they will have to set them manually. Then another problem is that arch users don't have a good set of default apps, like i.e. fedora provides downstream as can be seen here http://pkgs.fedoraproject.org/cgit/rpms/shared-mime-info.git/tree/ since a KDE environment would want a different default app than a GNOME environment. With the previous patch the user in nautilus will need to set a default app upfront. Maybe we can do something smarter on Nautilus with the previous patch when we detect there is no default app associated, but without a good set of default apps by the distribution we cannot do more than just show the first app (alphabetically probably) that is found to handle the mime type.
Review of attachment 326711 [details] [review]: I don't see why client should 'handle' there being a default or not. What handling do you have in mind ?
Review of attachment 326711 [details] [review]: I don't think this is right. You didn't describe at all how the application is 'becoming the default'. What is nautilus doing ? And why is that a problem ? Being the 'default' is not like some blessing that users need to explicitly manage. The default app is simply the one that you will get offered first when asking for the list of applications that can handle a given file.
(In reply to Matthias Clasen from comment #35) > Review of attachment 326711 [details] [review] [review]: > > I don't see why client should 'handle' there being a default or not. What > handling do you have in mind ? In case of Nautilus I can imagine requesting the user to set up the default app when no default app is found. Or just simply show the appchooser and let the user check the "set as default" checkbox. Currently Nautilus makes the button of "Set as default" for the application returned as default by glib. This has the issue that there is no way to set it really as default. The current default app when no default app is found is just by alphabetical order, which I believe is more random than some heuristic, i.e. like how many times the app was used to open that mime type.
(In reply to Matthias Clasen from comment #36) > Review of attachment 326711 [details] [review] [review]: > > I don't think this is right. You didn't describe at all how the application > is 'becoming the default'. What is nautilus doing ? And why is that a When an app that was not used to open that mime type is used to, a file inside .local/share/mimeapp.list is created with an association. That association just mean the application can handle that mime type. That makes the order of the list retrieved from the associations change, and therefore change the "default application". > problem ? Being the 'default' is not like some blessing that users need to > explicitly manage. The default app is simply the one that you will get > offered first when asking for the list of applications that can handle a > given file. Yes, and this is changing because there is no specific order, which is one of the issues. But I believe the real issue on glib is reporting that there is a default app, when there is not, neither set from the distribution or the user, and instead providing the first app that can manage that file as default app. If one wants to list all the apps that can manage the mime type and select the first one provided, that's fine, it can use g_app_info_get_all_for_type and select the first one, but I believe reporting an app on g_app_info_get_default_for_type when there is none set is misleading.
* let me clarify a mistake. The order it's not alphabetical, but just how happen to be in any of the mimeapps file.
* ugh another mistake. "Currently Nautilus makes the button of "Set as default" for the application returned as default by glib" I mean, Nautilus makes the button insensitive.
*** Bug 766753 has been marked as a duplicate of this bug. ***
The upstream package is https://freedesktop.org/wiki/Software/shared-mime-info/ which Fedora and other distros install by default. Arch users should create this file, although I agree this bug report could be better managed, as in the patch I proposed on comment 33.
Specifically, fedora distributes something like http://pkgs.fedoraproject.org/cgit/rpms/shared-mime-info.git/tree/ which includes the file that goes to /usr/share/applications/mimeapps.list which set the default applications for mime types.
Can GNOME please ship a gnome-mimeapps.list file? This would be very useful. Perhaps it belongs with gnome-session, since it also contains the "gnome" session definition.
Same problem in Gnome 3.24... This is not fixed yet. Any workaround?
I am little confused by these comments. Where does the issue lie? Is it with Arch's implementation of Gnome, or are other distros now seeing this with newer versions of Gnome?
Under Ubuntu-Gnome 16.04 LTS, I can't even set VLC as default player for MP4 files...
As far as I can tell, Gnome 3 in Arch repos is pretty much vanilla. I think something is wrong in Gnome's behavior when there's no mime association (it picks the first available app). It should open the app selection dialog instead, or save the automatically selected default on first file open so that it can be changed later. When you open the open with other application dialog and choose an app, the order of the list is changed (the selected app becomes the first choice) and that's why it seems that the default app was changed.
(In reply to Andy Pastuszak from comment #46) > I am little confused by these comments. Where does the issue lie? Is it > with Arch's implementation of Gnome, or are other distros now seeing this > with newer versions of Gnome? Arch doesn't manage that you install the right things, and it's its nature. In this case, if you are using arch, you forgot to include and integrate something similar what comment 43 says. If you want things to work properly ootb you will need a distro with integration built-in. Apart of this, there is this issue where we could manage better the case where these mimeapps list is not present. But hardly a priority enhancement since all distro with integration does this properly.
I guess there is also the cases where the filetype is "not common" which is affected by this. Even Fedora's mimeapps.list hardly handles every single mimetype in existence (I see 97 entries) and doing so sounds like an impossible endeavour anyway, hence the relevancy of handling this.
(In reply to Bastian Ilsø from comment #50) > I guess there is also the cases where the filetype is "not common" which is > affected by this. Even Fedora's mimeapps.list hardly handles every single > mimetype in existence (I see 97 entries) and doing so sounds like an > impossible endeavour anyway, hence the relevancy of handling this. Well, remember that mimetypes are a hierarchy, so I think e.j. fedora handles most common supertypes. But right for those uncommon types, the thing is that for those you most probably will have a single app that manages them, so it's not that problematic. Of course still a bug. The patch I provided is still here, but it is rejected. I don't know what else could be done.
Workaround that you need to repeat for every file type: - Right click the file and click Properties - Go to Open With tab - Choose an app and click Set as default Now that a default is specifically assigned, it won't change the file association when you choose another app in Open with other application dialog.
The option "Set as default" does not appear, at least in Ubuntu-Gnome 16.04 LTS (Xenial Xerus). The "Open with other application" dialog will simply do what is says. So, in this distribution, there is no (graphical) way to set the file association. When I wrote comment #7 above, in Arch Linux, the pop-up window would set directly the association as default. This was my main concern, because it was not stated anywhere and confusing. I don't know how things are now in Arch. In any case, both things are "wrong".
The is no "Set as default" for me either in Arch Linux in the "Open with other application" dialog. It's onlg there in the "Open with" tab of the file properties Dialog.
Running Arch Linux. I was able to right click, choose properties and set a default. I had to change the default and change it back, if the app i wanted was a default. Once I did that, I was able to use "Open With Other Application" and still have the original default stick.
In summary, for both, Arch Linux and Ubuntu-Gnome: * The properties window dialog work fine establishing file associations as default. * The "Open with other application" will simply do what it says. In my opinion, it would be better to add a tick option to establish a default file association. Cheers.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1026.