"As an example, there is no way for me to make .lyx documents open with Lyx
since Lyx doesn't appear in that list of applications"

Sorry, I meant there is no way to open them from within Nautilus (obviously I can open the documents if you manually open Lyx and open the document from within Lyx)

-> gtk+

I'd argue this is a bug of the application (Lyx), which should advertise all the mimetypes it can handle in its desktop file; I believe the new application chooser dialog doesn't allow custom applications by design.

*** Bug 657503 has been marked as a duplicate of this bug. ***

Have the same problem with Grisbi. I can't open my .gsb files with Grisbi because there is no way to associate it, meaning that I have to open Grisbi and then to open the files from there.

@Cosimo: I don't think that's a bug in the application, because for instance, I have a script that opens my video player on another desktop (:0.1 is TV output). This script can't "advertise MIME types".

This is definitely a bug, and a very important one.

*** Bug 661712 has been marked as a duplicate of this bug. ***

(In reply to comment #4)
> Have the same problem with Grisbi. I can't open my .gsb files with Grisbi
> because there is no way to associate it, meaning that I have to open Grisbi and
> then to open the files from there.

If Grisbi defines its own file format and its desktop file doesn't claim to handle it, it's definitely a bug in Grisbi.

> @Cosimo: I don't think that's a bug in the application, because for instance, I
> have a script that opens my video player on another desktop (:0.1 is TV
> output). This script can't "advertise MIME types".

Opening a file is done with an application, which has a desktop file by definition. What Nautilus did was indeed creating such a desktop file with the custom command you provided. You can do that yourself by putting your script in a location in your $PATH and placing a desktop file in ~/.local/share/applications (followed by 'update-desktop-database ~/.local/share/applications') that has your script as value for the 'Exec' key.

I don't realistically see this feature going back in GtkAppChooser, but it would be a perfect fit for an advanced "desktop file editor" external application (also if you your video player needs a command line switch to work properly with multihead, this is probably a bug in the video player).

> If Grisbi defines its own file format and its desktop file doesn't claim to
> handle it, it's definitely a bug in Grisbi.

Please allow me to quote Wikipedia (even if it's not a scientific definition):
"A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways."

Grisbi does not have an error, flaw, mistake, failure or fault and there is also no unexpected result produced by Grisbi. The unexpected result is caused by Gnome/Nautilus because it doesn't allow me to open a file with Grisbi (important: even if Grisbi WOULD have a Desktop file and the association would be correct in Nautilus, I could STILL want to open it with another executable).

I also think that this would conform to the Gnome Interface Guidelines:
http://developer.gnome.org/hig-book/stable/principles-user-control.html.en

> Opening a file is done with an application, which has a desktop file by
> definition.

I suggest to:
1) Re-think the definition of an application (I have seen many definitions of applications in computer science, but never that an application has to have a desktop file) OR
2) Create a desktop file or whatever is needed automatically and without the user's knowledge, because when I want to open a file with Grisbi or a script, Gnome should make that possible (if it has to create a desktop file to make the executable to an "application", well, why not).

> What Nautilus did was indeed creating such a desktop file with the
> custom command you provided. You can do that yourself by putting your script in
> a location in your $PATH and placing a desktop file in
> ~/.local/share/applications (followed by 'update-desktop-database
> ~/.local/share/applications') that has your script as value for the 'Exec' key.

Thank you for your advice. I will do this as soon as I have investigated the format of desktop files, how the whole thing works etc. I will do this and I know how to do this because I'm a developer, but I don't think that you can expected an average user to do this (and there will always be applications without desktop file, for instance, non-Gnome applications, scripted applications etc.).

> I don't realistically see this feature going back in GtkAppChooser, but it
> would be a perfect fit for an advanced "desktop file editor" external
> application (also if you your video player needs a command line switch to work
> properly with multihead, this is probably a bug in the video player).

I don't know how this can be solved, but the solution should enable a user who doesn't know anything about "desktop files" to open files with the application of his/her choice.

I have got the same problem. How do I launch my files with custom applications?

(In reply to comment #7)
> > Opening a file is done with an application, which has a desktop file by
> > definition.
> 
> I suggest to:
> 1) Re-think the definition of an application (I have seen many definitions of
> applications in computer science, but never that an application has to have a
> desktop file) OR
> 2) Create a desktop file or whatever is needed automatically and without the
> user's knowledge, because when I want to open a file with Grisbi or a script,
> Gnome should make that possible (if it has to create a desktop file to make the
> executable to an "application", well, why not).

for the past 7 years, all major Linux environments (KDE, GNOME, and virtually everyone else) have adopted (machine-readable) desktop files to define applications and allow them to be identified, launched, associated to other pieces of the stack like the shell and the MIME type system. well-behaved applications should conform to the desktop entry specification, as hosted on freedesktop.org:

  http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

Grisbi should conform to this specification in order to work properly in any modern environment. the desktop file has to be shipped by Grisbi, and the user has no interaction whatsoever with them. if Grisbi is not shipping a desktop file, and is not registering itself with the shared MIME type database to associate itself with its file type, then it's a bug in Grisbi, and users of Grisbi should not ask Gnome to handle something that well behaved applications should do in the first place. that's the whole reason of having specifications in the first place.

(In reply to comment #9)

It's fully OK and I understand the necessity and benefit of desktop files for the system and for developers.

I also agree that Grisbi should ship a desktop file.

However, I don't agree that my script that starts the media player on another desktop should have a .desktop file.

And I still say that it is very important that users are allowed to choose an application of their choice to associate files. There will always be applications that don't use desktop files (for instance, you can't expect third-party applications written in Java for platform independence to ship a desktop file, neither will batch-processing shell scripts do, and last but not least there are "bugged" applications like Grisbi which should have a desktop file but don't have one), and the file manager (Nautilus) should allow users to start files with such programs. Otherwise, the file manager is an obstacle for handling such cases (and they are real, otherwise I would post here).

*** Bug 662644 has been marked as a duplicate of this bug. ***

Setting ui-review keyword.

I have posted this bug first on Ubuntu's launchpad, which pointed me to the bugtracker here.

Firstly: 
I must agree with Andreas Mayer. 
I can give you another example. I frequently use Blender but Ubuntu does not ship with the latest version of Blender. I, like many linux users who want the latest and greatest features, use svn or git and build these applications from source.
Working on a huge project, like an animation movie, requires me to browse easily through hundreds, if not thousands of files, and opening them with the application I want and need. Since Ubuntu ships with an older version of Blender, through Nautilus I can only open it with the version provided by them. Right now, selecting my custom built version of Blender to open the file with, is impossible. This seriously hinders my workflow and slows me down.

Of course you can respond : why not opening it from within Blender, but I don't always need blend files. It might be Gimp files, or inkscape files, which also are under development, and for which I might need more recent builds then the ones shipped with the distro I use.

Secondly:
It was possible in Gnome2. Since Gnome3 it is not possible anymore. In my opinion this is a regression, and a serious one.

*** Bug 663865 has been marked as a duplicate of this bug. ***

To be honest I am deeply frustrated since I updated to Gnome3. It's always the same: You kill some basic functionality of a Gnome program an than you argue, there might be an other, more stringent way to do what that function once did. Frankly, I don't give a dam of your idea of cogency. 
Since I switched from Windows to Gnome/Linux I always appreciated that freedom to do like I want to. If I want to start a file with my own script I always could open this file with some single scripts with exactly that script in a very intuitive way. Now, with Gnome 3, you are telling me, I have to go to the folder ~/.local/share/applications open a text editor create a desktop file save it, turn back to the file I wanted to open to find than the desktop file in Nautilus' list? I mean, are you kidding? This policy makes Gnome to be more and more like MacOs. That means: Do what the developer want you to do, ore get the hell out!
If that simple action is that complicated, it would be thousand times better to use the command line to open my file. But if nautilus does not make it more comfortable to me, to browse my files, as to do this with command line, what the hell is this program good fore?
If Nautilus needs a desktop file to open a specific file with a specific program, don't make this my problem. Just tell me please, how I should explain to a normal user, that he has to create an desktop file, to open a file with a specific program that is not – for what reason ever – listed? 
Ans are you serious about the idea, that the feature to search the internet for the application is more important than to have an opportunity to use a specific command?

I wonder if this bug is really an "enhancement" or just a normal bug, but I think it is a bug (because it's not about a new feature but a feature that was already here). Could you please adjust the importance?

Sometimes I am asking my self why I get that angry sometimes discovering that one feature that in my opinion is important, has vanished. I think it is because I don't see a good alternative for Gnome. It's the lack of an perspective that makes me angry...
But that is not the point here. I rather prefer to be constructive. Let me make tow further point's why I am thinking that this feature is that important an then provide an idea how to solve that problem.

1.) One of the major advantages of using Linux and Gnome were in my opinion to have the freedom that is provided by the Shell not being dependent of design decisions an, on the other hand having a got UI like gnome that provides you the opportunity to have shell like freedom like using an address bar instead of the breadcrump thing start a graphical program or an file or an command with the F2 dialogue and so on. In Gnome3 it feels that we are loosing step by step this big advantage. The UI becomes more and more closed like this one of Windows and MacOS. 

2.) There are many many standard Linux programs not having a GUI and almost all of them don't have an desktop file either. Like Vim or thousand others. If a file manger does not provide you a feature to choose one of these applications that make Linux so rich in an easy why it looses some of Linux' main advantages

And here is my suggestion:

The »open with« dialogue should look like old Gnome2's F2 dialogue: That means at the haed of the list should be an filed, witch works as:
  1. Filter for listed applications .
  2. Filter for all applications in /usr/bin and /usr/local/bin
  3. Addressbar to auto complete addresses to specific files
  4. And maybe as filter for programs that are available in the repositories (so you don't need the »look online« thing any more)
An »open in terminal« option would be very useful too

What to you think, folks?

I agree very much with Gunwald, and have the same frustration, thoughts about where Gnome seems to go to with Gnome 3. Freedom is essential for a linux application, and certainly when it is Open Source. 
I want to add something to this. 
I have the distinct impression everything is being done to make the use of linux easy, and it is being exaggerated to the point where instead of easy, it becomes more difficult to achieve things like described above,  by over simplifying tools, assuming the user would not be able to use it anyway. This issue is, I think, an illustration of what happens when things are oversimplified: its use gets limited. 
Again, this is a regression, not a request for a new feature. The status needs to be changed indeed (is there actually 'regression' in the list of importance?).

Everybody please keep in mind that this is not a forum.  If you have some *technical* additions feel free to add them, but every comment triggers bugmail.
NO INTEREST in generic "easy linux" blah - Please stay on-topic.

*** Bug 653871 has been marked as a duplicate of this bug. ***

(In reply to comment #9)
> (In reply to comment #7)
> > > Opening a file is done with an application, which has a desktop file by
> > > definition.
> > 
> > I suggest to:
> > 1) Re-think the definition of an application (I have seen many definitions of
> > applications in computer science, but never that an application has to have a
> > desktop file) OR
> > 2) Create a desktop file or whatever is needed automatically and without the
> > user's knowledge, because when I want to open a file with Grisbi or a script,
> > Gnome should make that possible (if it has to create a desktop file to make the
> > executable to an "application", well, why not).
> 
> for the past 7 years, all major Linux environments (KDE, GNOME, and virtually
> everyone else) have adopted (machine-readable) desktop files to define
> applications and allow them to be identified, launched, associated to other
> pieces of the stack like the shell and the MIME type system. well-behaved
> applications should conform to the desktop entry specification, as hosted on
> freedesktop.org:
> 
>  
> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
> 
> Grisbi should conform to this specification in order to work properly in any
> modern environment. the desktop file has to be shipped by Grisbi, and the user
> has no interaction whatsoever with them. if Grisbi is not shipping a desktop
> file, and is not registering itself with the shared MIME type database to
> associate itself with its file type, then it's a bug in Grisbi, and users of
> Grisbi should not ask Gnome to handle something that well behaved applications
> should do in the first place. that's the whole reason of having specifications
> in the first place.

I think this is a poor argument. Consider this evidence from openSUSE 12.1 which provides Gnome 3.2.1 and KDE 4.7.2. Under KDE 4.7.2 you can easily associate Audacity with .mp3 files using a GUI file association tool. Unfortunately there is no equivalent tool in Gnome 3.2.1. Under Gnome 3.2.1, if you right-click on an .mp3 file and choose properties then click on the "Open With" tab, even if you then click on "Show Other Applications" you will not be able to see Audacity listed until you edit the "audacity.desktop" file and make the Exec= line read "Exec=audacity %U". The bottom line is that KDE provides a means of handling this lack of compliance in a much more user-friendly way.

*** Bug 675891 has been marked as a duplicate of this bug. ***

Created attachment 214667 [details]
OS X "open with other application" dialog

FWIW, the way OS X deals with this is to let you choose any application from the "Open with other application" dialog, but to warn you with an inline message if you select an app that doesn't advertise any ability to open that kind of file. But it will still let you try, and even gives you the option to "Always Open With" in future, if you're sure.

There's also a "Show All Applications/Recommended Applications" filter in the dialog, but it's not clear to me exactly how that works. I think "Recommended Applications" is only supposed to show apps that advertise the ability to open that type of file. But as you can see from this screenshot, that seems to be a bit broken here.

*** Bug 678232 has been marked as a duplicate of this bug. ***

*** Bug 681174 has been marked as a duplicate of this bug. ***

I think this bug is still mis-categorized (see comment #16).

It is important to have the possibility to open files with own arguments. And it is no easy-to-use when I have to create a mime type and desktop file in order to have my onlinetvrecorder-application started when clicking an *.otrkey file.

I do not understand this vanishing-options-thing in gnome. Who minds about that option when he/she does not need it. But I miss it when I need it and it vanished.

Please do not make gnome like osx. Or implement expert-mode..

*** Bug 692630 has been marked as a duplicate of this bug. ***

*** Bug 697383 has been marked as a duplicate of this bug. ***

If I write a patch for Nautilus adding a "Browse" button in the "Open With" dialog, eventually adding the chosen executable to the list, does it have a chance of being integrated upstream ?

Or is someone already working on it ; or even a complete oppositon to the whole idea ?

Doesn't nautilus scripts functionality[0] already cover the "open with script" use case?

[0] Executable files on the folder ~/.local/share/nautilus/scripts/ are shown in context menu.

(In reply to comment #31)
> Doesn't nautilus scripts functionality[0] already cover the "open with script"
> use case?
> 
> [0] Executable files on the folder ~/.local/share/nautilus/scripts/ are shown
> in context menu.

Just tested ; it works.

Are you suggesting to write a script that opens a GtkFileSelector dialog, then opens the right-clicked file with the selected executable ?

Although it would definitely work, my suggestion is actually to integrate such a feature directly in Nautilus, targetting users who install Vanilla GNOME without having to know about any additional "nautilus-script-openwith" package (thus making the presence of this feature a distro's choice).

(In reply to comment #32)
> Are you suggesting to write a script that opens a GtkFileSelector dialog, then
> opens the right-clicked file with the selected executable ?

No. I'm suggesting to directly add your custom executables to ~/.local/share/nautilus/scripts/, so that nautilus can pick them up automatically.

The two use cases mentioned in this report are: (1) open with application whose *.desktop file doesn't claim to handle the file format; and (2) open with custom script.

It has previously been argued why (1) is a bug in that specific application, and, if I understand it correctly, nautilus scripts functionality already covers (2).

(In reply to comment #33)
> It has previously been argued why (1) is a bug in that specific application,
> and, if I understand it correctly, nautilus scripts functionality already
> covers (2).

OK, there was a misunderstanding here. I was covering (1).

While I agree that the application *should* ideally advertise its mimetypes, and that we can consider it a bug, my suggestion was indeed to add a workaround by allowing to choose a non-listed app (using a File Selector, autocompletion, ... whatever).

Or are previous statements on this subject (specifially Comments #6 and #9) a definitive decision ?
I need to know before writing any code on my side.
Please note that we're some people asking for this feature ; hence my comment.

Created attachment 240876 [details] [review]
gtk364-appchooser-openwithcustom.patch

Please find a patch attached in previous post, so you can see what I mean.

The patch does not add functionality yet, just provides new graphical widgets.

The patch adds a "Custom command" expander under the main list, so it does not consume unnecessary space :
http://www.tarnyko.net/repo/gtkappchooser-openwith_a.png

When clicked, the expander slides down to reveal "Command" entry and "Browse" button :
http://www.tarnyko.net/repo/gtkappchooser-openwith_b.png

The entry uses GTK+3 autocompletion capability to automatically complete text with system-wide executables names (using the PATH variable) :
http://www.tarnyko.net/repo/gtkappchooser-openwith_c.png

(PS maybe the "Browse" button is too much and old-school ; so here is a screenshot with only the entry :
http://www.tarnyko.net/repo/gtkappchooser-openwith_c_altern.png)

Reviews and opinions are welcome.

(In reply to comment #36)
> Please find a patch attached in previous post, so you can see what I mean.
> 
> The patch does not add functionality yet, just provides new graphical widgets.
> 
> The patch adds a "Custom command" expander under the main list, so it does not
> consume unnecessary space :
> http://www.tarnyko.net/repo/gtkappchooser-openwith_a.png
> 
> When clicked, the expander slides down to reveal "Command" entry and "Browse"
> button :
> http://www.tarnyko.net/repo/gtkappchooser-openwith_b.png
> 
> The entry uses GTK+3 autocompletion capability to automatically complete text
> with system-wide executables names (using the PATH variable) :
> http://www.tarnyko.net/repo/gtkappchooser-openwith_c.png
> 
> (PS maybe the "Browse" button is too much and old-school ; so here is a
> screenshot with only the entry :
> http://www.tarnyko.net/repo/gtkappchooser-openwith_c_altern.png)
> 
> Reviews and opinions are welcome.

It is a very nice proposition : hidden for peoples who dont need it, and efficient for those who have to use it (for exemple some software from wine cannot be associated, …)

Review of attachment 240876 [details] [review]:

I see people already commented on this patch on gtk-devel; I agree, I don't think this is something we want actually: in GNOME 3, applications are first-class citizens you install through a package manager, or ideally an app store, and they should have an icon and a sensible name (which are not easily possible to do with this kind of UI).

I can see two cases where you would want to specify a custom command:
- when the application is correctly installed, but its desktop file is buggy and doesn't claim some mimetypes. In this case, the desktop file of that  application should be fixed.
- when the user wants to have a custom script/binary being launched for specific mimetypes. As mentioned, Nautilus already has scripting functionality, independent from the application database, for this; in case that's not sufficient, what you're really looking for is a "create a custom application for my script/binary" feature. I think the Alacarte menu editor, or another external tool, should be used for that purpose, and not the "Open With" dialog.

Hope this helps clarifying the bug here.

Hello, 

I have to confess that I don't understand this opinion.

What is wrong if there's the possibility to open files with any user defined command? It is nothing that has to be used and it is not disturbing anybody if it is hidden just as suggested by "tarnyko".

In fact this is the way Nautilus had this feature implemented for years before Gnome 3 came. 

There are many reasons for this feature to be needed. You have mentioned the buggy desktop file. In fact this is a very common problem and a user cannot be asked to fix this I think (at least it is easier for a user to specify a custom command to open a file as to fix a desktop file I think). Especially self-made scripts or Windows applications installed and run with Wine often have missing or buggy desktop files.

I'm begging anyone to implement the requested feature as I was missing it since Gnome 3 came.

Best regards, 

Lucas Sichardt

(In reply to comment #38)
Cosimo,

Thanks for the clarification.

Hey tarnyko, 

I think your patch would be a big improvement. But I know that it is absolutely impossible to convince the Gnome folks of that idea. The discussion is always of the same type, and form my point of view arguments as in #38 are completely wrong. But I am sure, that the Nemo folks would appreciate your idea an work. Look here: https://github.com/linuxmint/nemo/issues.

Best regards,
Gunwald

I agree with 41. I dont want to start Programms/Scripts with no or corrupt desktopfile over an Contextmenue and alwas search an entry in an substructure... I´m user and just wanna dubble click and dont wanna wait until any developer fixed a desktop file. i dont understand this frustrating decision. I think its an basic feature of an DE.

Regarding Comment 38, I understand that in theory, applications are first class citizens installed from official sources with properly created .desktop files but in practice, applications are oftentimes shell scripts, custom made, or come from unofficial sources.

Therefore, I believe this is a regression and that specifying custom applications is an essential feature of a file manager's "open with" dialog. 

Windows and Mac OS have this functionality even though they are closed systems marketed towards non-developers. Free software like GNOME 3 which advertises itself on its front page as "A press of a button is all it takes to...launch applications", "Having everything in one place", providing "a focused working environment that helps you to get things done", and "Puts you in control" should set out to actually fulfill these aims.

*** Bug 704136 has been marked as a duplicate of this bug. ***

*** Bug 704836 has been marked as a duplicate of this bug. ***

A rough look at which applications are offered shows a funny relationship:

< The apps that are shown are those declaring *any* MimeType, whether it's relevant or not. >

In my specific case, I defined text/x-wxmaxima-batch for use with wxMaxima, and the dialog offers me every app capable of handling *some* MIME type (VLC, Clementine, even AptURL!), but not wxMaxima because /usr/share/applications/wxmaxima.desktop doesn't have a MimeType entry.

Does this make sense? What I think logical is: after having offered those applications that handle the specific MIME type ("recommended"), show *all* known applications (those with a .desktop file).

Here is a small hack to circumvent the "feature" of not being able to select an application: https://github.com/JanBessai/OpenWithHack
It can be used without patching any executable in your system and just requires python3 + pygobject

comment 6 has the verdict on this.