GNOME Bugzilla – Bug 569668
Don't allow changing default app for folders
Last modified: 2009-06-18 15:48:04 UTC
This bug report was prompted by https://qa.mandriva.com/show_bug.cgi?id=47372 . Say you have two bookmarked folders, Music and Images. You want Music to be handled by $MEDIAPLAYER so, using "Properties > Open with" you associate the Music folder with it. Now, when you activate the Music folder from Nautilus, it still opens in a Nautilus window, although $MEDIAPLAYER is in the context menu. This is probably the right choice in most circumstances. When you activate the Music folder from the Places menu, it tries to open it with $MEDIAPLAYER. This is inconsistent with Nautilus but still defendable, after all the user specified the different handler himself. Now, it gets really messy when you try to open Images from the Places menu. It will launch $MEDIAPLAYER for the Images folder as well! This is definitely undesirable behavior, and can cause serious cases of computer-induced anger. It should simply use Nautilus for opening that folder.
What does "gvfs-open Images" do?
(In reply to comment #1) > What does "gvfs-open Images" do? gvfs-open uses the same handler as the Places menu does, i.e. it tries to use the mediaplayer to display the Images folder.
So definitely not a panel bug :-) Moving to glib. Can you paste the output of gvfs-info here so we can see the content-type that we get?
Created attachment 127708 [details] gvfs-info output gvfs-info output for the Afbeeldingen (Images) folder. Output is identical regardless of the Open with association.
Interesting, nothing weird there at first glance. Maybe it's a feature?
Same symptoms as bug 553237, but if you assign an app to inode/directory (which you state that you did in the report), every application that launches a folder using the standard app launch machinery is going to open in that app. The panel could workaround this by always using Nautilus, but that might make some other people angry (e.g. those using Thunar as their file manager in GNOME, for whatever reason). To do what you want, you really need a subclass of inode/directory. We don't really support that. There's at least a theoretical capacity for it, see http://lists.freedesktop.org/archives/xdg/2008-June/009674.html, though I'm not sure that's a road we want to go down.
Oh, hadn't see the part where the media player was associated with directories. So I'd close it as a duplicate of bug 553237, indeed.
As far as I understand it, this is NOT a duplicate of bug 553237. That one is for Nautilus, and Nautilus indeed does the right thing in 2.25.5. This is about the Places menu (which in turn uses gvfs-open). @A. Walton: it sounds like you're suggesting to keep broken behavior in Gnome to accomodate people who choose to mix non-Gnome components with Gnome. Could we first make all primary Gnome components play together nicely and *then* worry about making it work with 3rd party software, please?
I suggested the panel would be able to work around it, but that it's not what we'd want to do, and gave a reason why it's not a good idea, but just in case I'll add another obvious reason why it's not a good idea: _any_ other launcher app will also launch the music player for every directory it attempts to launch. The panel is just the most visible in GNOME. Setting a media player as the default directory handler is generally a bad idea. If anything, the broken behavior is making it so easy to change. I then suggested a realistic way to resolve this, but I honestly don't think it wins us anything that a well-placed launcher wouldn't handle, and costs us more in terms of the extra I/O necessary to ask if a directory matches a content type on every lookup. And I can only imagine a much more ugly version of bug 553783 caused by another too general content type guess...
I don't think this is realistically fixable. The core problem is that Reinout wants to assign a specific file/folder with a specific application, and believes that "properties -> open with" does this. However, that is completely wrong. "Properties -> open with" sets the application handler for the whole mimetype, so you basically request all folders to open in this app. Nautilus itself has some special code for directories, so it won't consider launching apps for directories when browsing around, however all other things that lauch apps will. So, this is working as designed. Although you might consider it a feature request for specifying application settings on a per-file basis in addition to per type, but I'm not sure that is a particularly good idea.
(In reply to comment #10) > I don't think this is realistically fixable. The core problem is that Reinout > wants to assign a specific file/folder with a specific application, and > believes that "properties -> open with" does this. I know that, but the original bug reporter didn't (and can't be expected to, really). > However, that is completely wrong. "Properties -> open with" sets the > application handler for the whole mimetype, so you basically request all > folders to open in this app. Nautilus itself has some special code for > directories, so it won't consider launching apps for directories when browsing > around, however all other things that lauch apps will. From a user perspective, there is no difference between "Nautilus" and "Gnome panel". They should behave the same. > So, this is working as designed. I'm sorry, but then the design is wrong.
> "[...] Reinout [..] believes that "properties -> open with" does this. > However, that is completely wrong. " An end user is never wrong. It's a bug in the feature or it's a misleading UI. I've one golden rule : if a developper ever tell to a user : "You are wrong, you doesn't understand the software", there's a problem and an important one. Note that I don't say you have to change the software. Sometimes, simply changing the documentation or the way stuffs are presented is enough. > From a user perspective, there is no difference between "Nautilus" and "Gnome > panel". They should behave the same. Indeed. I can see a billion of valid reasons why they should act differently. But I'm sure I could not find one real user who will understand it when trying to access his bookmarks. After reading this thread, I see two possible solutions : 1) We don't allow changing the handler for folders. It makes a lot of sense and I don't see any usecase that are working right now and would be broken. Currently, that how I see a solution to this bug. 2) Implement a "Open this folder with". This should not be that hard. Putting a .hidden file in the folder with a command should be enough. Maybe there's even a XDG standard for that kind of stuff (or we can create one). The standard browsing would still be available with a right clic under nautilus and would be consistent in gnome-panel/nautilus/whoever implement the spec.
I was stumbling over this problem, too. At that time, I've changed the default handler of a directory back to Nautilus and went on working. But I still dream of an environment that would open different folders with different applications. So the first way proposed by Lionel, is perfectly ok for me, but the second one would be a little pleasant miracle. And yes I'm totally sure that this IS the bug (maybe an FR, but not NOTABUG anyway).
Ah, the "user is never wrong" card. How can you argue with that. Of course, I'm also a user, so I'm right! HA! TAKE THAT! :) The dialog says "Select application to open 'Music' and other files of type 'folder'". Furthermore, this is the way it works for all other file types, so its expected that users even if they don't read the dialog will eventually understand that it doesn't affect the selected file only. However, I agree that its kind of tricky if you get in a state where the default folder handler is changed. So, maybe we should forbid changing it.
> HA! TAKE THAT! :) Damned, I'm stuck like a rat ;-) On a more serious note, the "way it works for all other file types" is only understandable for true Unix geeks. Most people have difficulties to understand what a folder is so they *don't* consider a folder a file type. For Unix lovers like us, it's nearly impossible to understand their non-understanding because we found it simple, logical, and consistent. But remember that user interaction is rarely about engineering logic. It's more about "feeling". And this bug is the proof that at least some user have a feeling which is opposite to what we, developers, found logical. Telling the user : "it was written" it's not a good answer because this bug is the proof that it was not written in a way the user could understand the implications of his action. Also, most user simply cannot read when they are in front of a computer because "hey, it's a computer, it's freaky and it has virus and nazis on the internet but I want facebook". (My usability experiments show a lot of funny reaction but it's maybe out of scope here). "It was written, it's clear, learn to use the program correctly, dumb user" is what I call : "Git community support syndrom" and I really believe that gnome should avoid that at all cost. I must admit that, in my previous comment, I took for granted that it was the majority of users. Maybe it's true, maybe it's not. Only a poll and/or an usability study with real non-developer users can tell us.
2009-03-06 Alexander Larsson <alexl@redhat.com> Bug 569668 – Don't allow changing default app for folders * src/file-manager/fm-properties-window.c: Don't show "open with" tab for folders. Accidentally changing the folder handler causes all sorts of weird issues when e.g. opening folders from the panel.
to #16: I don't agree that this is the right solution. I think 'open with' is a very useful menu item, just changing the default isn't.
I'm not sure "Open with" tab should be hidden altogether. As far as I understand, a user won't be able to remove unneeded items from the "Open with" submenu. Is it possible to disable changing the state of the radio group instead of hiding the whole tab?
Answering to myself - it is. Patch will be ready soon.
Created attachment 130280 [details] [review] Fix the reference to a toggle_renderer This is a tiny fix that is worth to be applied in any case. It fixes toggle_renderer to really point to the radio toggle renderer, rather than to the pixbuf renderer. It was almost unused in the code, however, so nothing hurted. The next patch really changes things.
Created attachment 130283 [details] [review] Hide the radio buttons if the content type is inode/directory Here is the main patch. It hides toggle_renderer if we are dealing with directories and reflects it in the text on the tab.
Forgot to mention: this patch will only work if Open with tab is allowed for directories (i.e. without last Alexander's changes) :) Tested with Nautilus 2.25.92. Since the code freeze has almost come, and the patch adds new strings (let alone alters the code), I believe, this is for 2.26.1... It is possible to change the patch so that no new strings are added, anyway.
I agree with Comment #17 from Götz Waschk - unfortunately this "bug fix" has removed useful functionality. The original intent of this bug was not to allow changing the "default app to open folders", which was needed. However the "bug fix" now blocks users from removing unwanted entries from the "Open With" context menu entry for folders. I opened a bug for this, http://bugzilla.gnome.org/show_bug.cgi?id=580309 ... but Cosimo didn't like it (or didn't understood it) and closed it. Now users will need to resort to editing some cryptic configuration file in order to remove Open With entries added by mistake. It's a pity from the user experience perspective, like going backwards a few years in time.
*** Bug 546306 has been marked as a duplicate of this bug. ***
*** Bug 501409 has been marked as a duplicate of this bug. ***