Open with on folders was removed, Ubuntu should consider patching back

Bug #1026254 reported by Doug McMahon on 2012-07-18
244
This bug affects 53 people
Affects Status Importance Assigned to Milestone
Nautilus
Unknown
Unknown
nautilus (Ubuntu)
Wishlist
Unassigned
Trusty
Wishlist
Unassigned

Bug Description

* Impact:
the "open with" action is missing on directories

* Test case:
right click on a directory and see if "open with" is listed

* Regression potentiel:
check that the open with items work as they should

Doug McMahon (mc3man) wrote :
Sebastien Bacher (seb128) wrote :

Thanks, I think there is going to be a loooong list of such options dropped in 3.6, we need to think about it but I think we should consider added nautilus-3.4 as a separate source for users who want a featurefull filebrowser

Changed in nautilus (Ubuntu):
importance: Undecided → Wishlist
Sebastien Bacher (seb128) wrote :

added -> adding

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nautilus (Ubuntu):
status: New → Confirmed
Tobias Wolf (towolf) wrote :

> Thanks, I think there is going to be a loooong list of such options dropped in 3.6, we need to think about it
> but I think we should consider added nautilus-3.4 as a separate source for users who want a featurefull filebrowser

The problem with that is that the changes in this cycle are *very* hit-and-miss. Some things are cool, but some things are just baffling.

Doug McMahon (mc3man) on 2013-01-27
tags: added: raring
Doug McMahon (mc3man) wrote :

Now that Ubuntu is going with 3.6.x in 13.04 some re-consideration could be given to returning this, reasonably non-invasive & simple to patch back.
The idea that folders should only be opened from nautilus with nautilus is a bit shortsighted.

Sample patch attached

The attachment "open-with.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Jeremy Bicha (jbicha) wrote :

From the upstream commit: "The only thing that handles this by default is nautilus."

While the patch works, I don't think it works well enough with the Nautilus design. Right-clicking a folder shows four different Open buttons instead of two (screenshot attached). #1 and #3 do the same thing. #4 is useless if you don't have an alternate file browser installed (which the vast majority of users do not).

Maybe a better place for this option would be:
1. Right-click on a file and select Properties.
2. Switch to the Open With tab.
3. Repeat by right-clicking on a folder instead. There is no "Open With" tab.

However it's not clear whether it's Nautilus' responsibility to make it easy for users to switch to a third-party file browser by default. Why can't the alternative file browser handle this, similar to how web browsers offer to set themselves as default?

Doug McMahon (mc3man) wrote :

I have to disagree with most of Jeremy's comments
This is only a means to present an "open with" context menu option in nautilus which doesn't exist.
After actually using there are only 2 options, "Open" (nautilus) & "Open With", not 4

How the user populates the "Open With" sub menu is up to the user, that's what options are for (when they exist

The Open With sub menu is not just for alt. FM's, can be useful for A/V dir.'s & what ever else the user desires
Anything that appears in the sub menu that isn't desired can be user removed from the Open With menu with a r. click on > "Forget application"

Doug McMahon (mc3man) wrote :

Now if I did want the 'option' to open a dir. with an alt. FM again it's quite easy thru the context submenu

teledyn (garym-teledyn) wrote :

It isn't just VLC reading DVD images, but also Audacious, EasyTag and SoundConverter reading mp3 dirs, ImageMagick reading image dirs, Kino building a video clip collection, Emacs opening src dirs ...

Really it is the whole paradigm of modern data-driven (not 80's era app driven) workflow

Dare we consider a Unity-native browser that is a fork of Nautilus 3.4?

Please, tell me *where* and how I must apply this patch?

Milton (miltonlaufer) wrote :

I agree that this a very unpleasant change. I tried the patch, but I can't build the nautilus source (in the make, I get "fatal error: zeitgeist.h: No such file or directory", even if I have the zeitgeist package installed**).

Is there any other way?

** Reply to comment #13: In order to install a patch, you have to
1) Copy the patch file to a new folder
2) In that folder, do a "sudo apt-get source PACKAGE_NAME"
3) Copy the patch file into the new package folder in that dir
4) type "patch -p1 < patch_file_name"
5) sudo make (maybe you'll need to do a "sudo . /configure" first). Here you'll have to install all the dependencies that the package need to be build.
6) make install

#14 Thank you... but I do not understand "3) Copy the patch file into the new package folder in that dir"

4 files in this folder:
nautilus_3.6.3.orig.tar.xz
nautilus_3.6.3-0ubuntu16.debian.tar.gz
nautilus_3.6.3-0ubuntu16.dsc
open-with.patch

when I type "patch -p1 < open-with.patch" Terminal say:

can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|
|--- nautilus-3.6.3.orig/src/nautilus-view.c
|+++ nautilus-3.6.3/src/nautilus-view.c
--------------------------
File to patch:

What can I do?

Doug McMahon (mc3man) wrote :

LP isn't the place for support & as far as Raring this bug is a dead issue.
Jean-Christophe Sekinger - you're at the wrong prompt & using wrong patch command for location of patch.
In any event I don't recommend doing a default configure & make install of nautilus to /usr/local, you'll lose extensions unless you move or link them.

For help taking care of I suggest Ubuntu forums, this thread deals with in a fashion.
Exact instr. for a package build & install using a debdiff are in this post But you now must use the *debdiff* & patch command in post 26
http://ubuntuforums.org/showthread.php?t=2132523&p=12594506&viewfull=1#post12594506
If inclined please read thru & ask first in that thread if unclear on *anything*

Doug McMahon (mc3man) on 2013-05-01
tags: added: saucy
Sridhar Dhanapalan (sridhar) wrote :

This appears to be related to Bug #1178697.

deivid (deivid-rodriguez) wrote :

I completely agree with comments #9 and #11. I used to have 'musicbrainz picard' configured as an alternative app to open folders and would use that a lot. Now I have to open it from a terminal as "the same effect is better done through select all in a folder." (comment in commit that removes this option) is obviously not true.

Thanks @mc3man for the patch and the support (in ubuntuforums) on installing it.

I Have to reinstall the patch but ubuntuforums.org is closed for maintenance. Is there another way to understand exactly how to patch nautilus please?

Doug McMahon (mc3man) wrote :

While I've got a patched nautius for open with in a ppa (Nautilus Improved), it contains several other adjustments, a couple that could be considered a bit sketchy (no issue here

So for just the return of open with on folders -
https://launchpad.net/~mc3man/+archive/nauty-open

Dmitry Zotikov (xio) wrote :

Doug McMahon, thank you-thank you.

Works well.

Doug McMahon (mc3man) on 2013-12-14
tags: added: trusty

I upgraded to the 14.04 alpha, and this regression-bug persists; you still cannot "Open With" on a folder in 14.04.

I've been using Ubuntu exclusively since version 7.04. Around Ubuntu 12.10 I started noticing this regression.

It is so convenient to use "Open With" on folders especially when they contain music or videos.

I like being able to right-click on a folder and then open with VLC for example. Without this feature, I have open VLC, and then position its window in a manner that I can drag and drop the folder into VLC. I miss the days when I could just right-click the folder and then > Open With > VLC

The same is true for music folders.
1) Right-Click the folder (containing music files)
2) Select "Open With"
3) Select your music application (Audacious in my case).

Very handy! We need to bring this back for 14.04 LTS!

A work-around, if you really need the "open with" (on a folder) feature, is to use Nemo (until Nautilus fixes this regression):
sudo apt-get install nemo

Doug McMahon (mc3man) on 2014-01-24
description: updated
description: updated

I've done my best to advocate the usefulness of this feature. The main thing I will tell you, is that after you've discovered this feature, you can't go back.

My own philosophy on software advancement places priority on two (potentially mutually exclusive) priorities:

1) For the sake of intuitiveness, always provide a contextual menu for each element graphically displayed. Doing so, allows the user to answers the question: "What are all the things I do with this thing?". Another way of saying this is: "Place functionality near as possible to the graphical representation of the thing that the functionality is about". Doing this is most intuitive, and will eliminate mouse travel.

2) Always strive to eliminate the number of steps required to achieve a task, and do this in a manner that does not compromise the intuitiveness (the obviousness) of how to perform that task.

In this use case, we have user browsing through their file system with Nautilus. They come across a folder containing a hierarchy of music files. The user decides he would like to recursively enqueue this folder's files into his favorite music player. Due to principle #1, the most intuitive way to do this (giving context and nearness) is to place an option in the context menu that will allow him to recursively enqueue this folder into the application of his choice.

This method also fulfills principle #2, because it eliminates these 3 steps: (1) Launch an application. (2) Position the window of that application so that is not on top of the Nautilus window (3) Drag the folder from the Nautilus window into the other application's window.

Even a new user, could easily discover the usefulness of this feature, due to intuitiveness of context menus, which always answer the question "What can I do with this thing"? And, any user who has previously discovered this, will prefer it in this exact use case scenario.

Additional use cases this serves:
- Open folder with k4dirstat, to see what within that folder is taking up the most space on your hard drive
- Enqueue Folder into VLC to watch multiple music videos one after the other.

Any application that can use a folder as a launching input benefits from this previously achieve (but now missing) feature.

This concept is the graphical representation of the "piping" which has made the linux command line so powerful. I'd love to see this same power at the GUI level.

Sebastien Bacher (seb128) wrote :

@Lonnie: you seem to be a power user and have your workflow, that's fine but that's just an anecdotic example ;-)

Just as a counter-example, I've been using Ubuntu for 10 years, I do use nautilus to manage files but I've used that feature.
- I access music albums or photo collections through rhythmbox or shotwell usually.
- If you double click on an image it opens in eog which has a "gallery" which lists all the images from the current directory
- you can easily dnd a directory to totem, or open the directory, select all and right-click/open with

Everyone has a different workflow I guess ;-)

Note that you wrote "For the sake of intuitiveness, always provide a contextual menu for each element graphically displayed", user testing shows that context menu are not "intuitive" for most users.

As written on one of the duplicate, there is no right/wrong there, but a balance between too many options making the menu difficult to parse/use and having the useful options easily available.

I'm unsure how used that feature is/how good the workaround are considered by most user (dnd, select-all -> right click on the selection) and I don't know if we have a good way to get useful datas on such questions...

@Sebastien: Excuse me Sebastien but what you wrote is bull*** in my eyes!!!

I don't know what users have tested the functionality of Ubuntu but most users in the Windows-World and growing number of users in the Apple Universe use right-click menus for exactly the reason of intuitive and fast workflow! that has nothing to do with "Power-User" or such!
that is no statistic, that is my own experience on working with many different user-types in my daily business!

and on the other hand is there really NO reason to completely remove features (even if only ONE person is using it!) with the argument that it confuses new users!! What does that mean?? I think in that case it would be much smarter to disable the feature by default and let the so-called "Power-User" enable it!

Again excuse my harsh words but i'm so upset about the changes in Nautilus, on the Launcher dodge window feature and on the global-menu!!

I use Ubuntu only for 8 years but the recent changes are the wrong way i think (for the first time)

Sebastien Bacher (seb128) wrote :

@Jan:

- let's not argue about usability, it's not my domain, I'm just relaying what I've read over the years (see e.g http://en.wikipedia.org/wiki/Context_menu#Usability)

- the argument there it's not that "it confuses new users", where did you get that? I wrote "but a balance between too many options making the menu difficult to parse/use and having the useful options easily available."

The point is that if you have 150 features in nautilus and you list them all in its context menu, then you end up with a menu with 150 items. That's a lot of information and it means it's getting very slow for anyone to find where the item they are looking for is.

Sure that number is an exageration, but it's not always easy to provide all the feature while keeping an interface pleasant to use

- the changes in nautilus are coming from GNOME, not from us, we are just providing the software and trying to respect those who write it, by not overwritting too much of their decision in the version we ship, while keeping our users happy ... that's not always an easy balance either

@Sebastien

I think all can intelligibly agree that the only reason a context menu could be considered non-intuitive is due to the fact that it often requires a right-click, instead of a left-click.

The studies you reference do not address the idea of making a normal left-click produce context menus (which could be used in touch interfaces as well).

In situations where the left-click produces the context-menu, even the newest users will find it incredibly intuitive.

Right-click-context-menus, are a very small price in intuitiveness for the benefits of always being able to answer the question: "What can I do with this thing"?

If I called the shots at Ubuntu, a lot more would be context-menu-driven. To address the non-intuitiveness of right-clicking.
You could remind the new user each session (until they disable the notification) the following:

"If you don't know what something is, or what you can do with it: RIGHT-CLICK it"

Or, another idea is, by default, make *left-clicks* display context menus, and give advanced users the ability move that feature to the right-click menu. Now you have perfect intuitiveness right off the bat, and users can take off their training wheels at any point.

This is huge idea for User Friendliness. One day someone is going to get this right. It just makes too much sense:

"Show me what I can do with what I'm clicking on".

Its that simple. Every UI should keep this concept in mind during design and upgrade. That's my opinion.

You make a good point about the confusion that can come from too many options being in a context-menu.

This can be addressed, however, by putting the numerous and rarely used option under one parent-option labeled "Advanced".

Doug McMahon (mc3man) wrote :

One question, 1 final comment (from me

Did Gnome accept/commit the return of type-ahead find or is this just an Ubuntu change, noting that if the latter it's an extensive patch compared to returning 'open with' which involves removing 2 lines, adding 3 in an area that remains virtually untouched in the last 18 months or so.

 Users also find this handy to open a dir. from nautilus in another file manager for specific purposes such as with one that is multi-pane. (again just a convenience

Sebastien Bacher (seb128) wrote :

@Doug: the issue there is not to have to carry the diff, it's just to decide on whether agree or disagree with GNOME on the benefits of the design decisions

tags: added: ubuntu-desktop-trusty

Sebastien, show them this:
http://www.youtube.com/watch?v=fQhihnb2PV0

When seeing these compared side by side, it may influence their decision for the better.

Changed in nautilus (Ubuntu):
status: Confirmed → Triaged
sokolov (daniel-sokolov) wrote :

This is still missing in 14.04 LTS.

Mathew Hodson (mhodson) on 2015-01-14
tags: removed: raring saucy ubuntu-desktop-trusty
Doug McMahon (mc3man) on 2015-02-06
tags: added: nosense utopic vivid

Could the 'open with' be made optional? Default off for the people who find it offending. And the ability to turn it on in preferences. I miss this option allmost daily.

Mark Edgington (edgimar) wrote :

One decent existing use-case for this feature is the "baobab" program (that is useful to a broad user-base, not just "power-users"), which helps people see their disk usage, and get rid of unneeded large files. It would also apply to any other application that operates on folders.

Without this feature in Nautilus, a user is forced to (1) locate / remember the name of the baobab program and run it, and (2) select an "open folder" item from within the application and navigate to wherever the desired folder to act on is. This is terribly inefficient in comparison with just right clicking on a folder that you are already viewing in Nautilus. The same would apply to any software that is developed to operate on a folder instead of just a file.

One other argument for this is in terms of consistency -- the way you do something with a file in Nautilus should be consistent with the way you do something with a folder -- then there's less to remember about how to do things.

Daniel Antonio (souliaq) wrote :

The only way to solve this problem is install "pcmanfm" and run:

 xdg-mime default pcmanfm.desktop inode/directory

This solution worked for me, because I have my main folders as .desktop entries in the Unity dash.

Doug McMahon (mc3man) wrote :

Even Gnome finally came to their senses & have re-enabled open-with on folders. So possibly Wily will be ok.
Utopic is almost dead so who cares but this should be officially fixed in 14.04 rather than just thru a ppa

https://bugzilla.gnome.org/show_bug.cgi?id=691479
commit upstream - https://git.gnome.org/browse/nautilus/commit/?id=5b197d1bf8123d4dac2be5f24b6f3fd168f50853

tags: added: wily
Changed in nautilus (Ubuntu):
status: Triaged → Confirmed
Changed in nautilus (Ubuntu):
status: Confirmed → Fix Committed
Sebastien Bacher (seb128) wrote :

great, that's a good news, the new version is being worked on for wily and I uploaded a SRU for trusty

description: updated

Hello Doug, or anyone else affected,

Accepted nautilus into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nautilus/1:3.10.1-0ubuntu9.9 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nautilus (Ubuntu Trusty):
status: New → Fix Committed
tags: added: verification-needed
Mathew Hodson (mhodson) on 2015-06-19
tags: removed: nosense
Doug McMahon (mc3man) wrote :

verified working as intended on 14.04 trusty

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nautilus - 1:3.10.1-0ubuntu9.9

---------------
nautilus (1:3.10.1-0ubuntu9.9) trusty; urgency=medium

  * debian/patches/git_folder_open_with.patch:
    - restore open with action on directories, thanks Doug McMahon
      (lp: #1026254)

 -- Sebastien Bacher <email address hidden> Tue, 16 Jun 2015 15:09:37 +0200

Changed in nautilus (Ubuntu Trusty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for nautilus has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Mathew Hodson (mhodson) on 2015-11-04
Changed in nautilus (Ubuntu Trusty):
importance: Undecided → Wishlist
Changed in nautilus (Ubuntu):
status: Fix Committed → Fix Released
Mathew Hodson (mhodson) on 2015-11-04
tags: removed: utopic wily
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.