This is a feature request. As I have come to understand it, the program Exo is the one that keeps a list of application associations for various file types, AKA "Preferred Applications". Right now we have just three; browser, email client and terminal programs. I would like to see a simple interface that allows the user to assign a simple relationship between file types and associated programs for more than only three. Thanks.
Well that's not really the case, the preferred applications set in Exo are only for internal usege and not connected to any file types. The relation between file-types (mime) and applications is handled by Thunar(-vfs) or GIO in Xfce 4.8.
What is GIO?
The new virtual filesystem in glib.
Is there an implication that GIO will replace Thunar and/or Preferred Applications (Exo)?
Next Thunar release will use GIO as filesystem backend. Exo's preferred applications will stay because this is something independent.
Then I guess I'm confused about the purpose of Exo. Why is it even user-accessible if its purpose is internal to the DE? Further, why not have a mimetype preference table that is user configurable in the first place, and simply remove the misnamed "Application Preferences"? Thunar doesn't really do that either, and so is no substitute for a preference table.
We use it in places where we "hard-code" specific kinds op applications. For example which terminal is handled internally when you check a "Run in terminal" check box. The other preferred applications are used for specific uris: Web browser: http(s):*, Mail Reader (mailto:), File Manager, new in exo 0.5 (file:). For users this might be a bit misleading, but there is no other way, since there is for example no terminal mime-type (usage is different then the "shell script" mime type). Now I assume you want to choose which terminal is used by default, same for the other 3, so removing it from exo is not an option. That is also the reason why a preferred text editor is not a possibility: there are zillion mime types and there is no guarantee 1 text editor can support them all (and you probably don't want that: *.c file you open with an IDE, *.txt with a simple text editor). So don't confuse mime-types and uris (+ terminal). The naming is also correct, because they are preferred applications for specific tasks. The mime types you configure are types of files(!) you want to open with a kind of application.
From what I can understand, there has been an artificial division created between the settings of various software components. Thru-out the software industry, this is generally represented by the applications which handle file associations and those which specify default applications. Interestingly, they are actually almost the same thing, because they deal with default applications in both cases. So the first artificial division is between the apps which are used by other processes, and the apps which are associated with file and/or mime types. Because mime types are not quite all encompasing as of yet, the more ubiquitous "file extension" is a better indicator of the various types of content which needs to be handled by separate programs. So let us simply say that the user may wish to handle a particular file type with a particular program. Simple file association. The next artificial division is the one where a difference is shown between URI's and file extension types. From the standpoint of the average user, those are the same things, and from the standpoint of usability, they must be handled by the same settings application. An additional confusion is automatically created when the user must open a Thunar window, right click on the file, and create an application association to make it open as desired. Depending upon the myriad applications one may use, there may be no listing of applications to associate with the file type unless the user goes thru those particular steps. Not only is the process difficult for programmers (because their application tie-ins are pointed all over the place), but the user is confused by the lack of intuitive design (where everything is reasonably expected to be in one setup utility). It is interesting to note that KDE, for example, uses that basic division as well, not realizing that the one interface could have handled all the settings in one place. But on the other hand, KDE offers a very wide range of file types to associate with preferred applications, and it allows more to be added. Such arrangement displays a lot of insight into good software design. A preferred text editor is indeed possible by focusing upon file types. This would allow a particular file type, say .txt, to be associated with a particular editor, say ted. Further, there is no reason to have only one editor. The proper one for the proper file type can be associated separately. This way there can be a wide range of preferred applications for different specific tasks. So, just keep the name "Preferred Applications" and add a tabbed section for file type associations, as is most commonly done. No need to reinvent the wheel, and no need to leave out necessary and common tools.
Maybe in the future we could have a central dialog for associating mime types and applications in addition to the special cases we already allow to be customized via the preferred applications dialog. With g_content_type_get_registered(), GIO provides a function to get a list of all mime types known to the system. There are other functions for determining the display name and icons for those types, so this would be a rather easy task. I entirely understand that some people prefer a centralized GUI for these associations in addition to Thunar's Open With dialog. With GIO, this additional feature would be compatible with Thunar, so I don't see any problems.
Yes, thank you. There is a preference there by many people, I believe, to handle things that way. But I would make it a part of the Settings Manager rather than Thunar. Many of us don't want to use Thunar and would like to see it more as a separate app that can be removed in favor of a better file manager. Thanks again.
(In reply to comment #10) > Yes, thank you. There is a preference there by many people, I believe, to > handle things that way. But I would make it a part of the Settings Manager > rather than Thunar. Many of us don't want to use Thunar and would like to see > it more as a separate app that can be removed in favor of a better file > manager. exo-preferred-applications is a standalone application, so I guess we're in agreement here.
I don't feel like adding a mime editor in exo. Exo has nothing to do with that. Either put it in xfce4-setting or Thunar.
Look at it this way. The exo Preferred Applications is a type of setting, which can be set by the user. File/Application associations is a listing of user-preferred settings. Mime-type/program relationships are also a setting choice (when it is necessary to think of them separately). So, place everything in xfce4-setting. This keeps things neat and clean, and easy to use. It becomes completely intuitive. It is also easily expandable since it is primarily a front-end. If exo is a necessity, the settings manager can become its front-end. No problem there. I also like the idea of how this path allows for a future view that automatically maintains a beneficial design plan on behalf of the users. Also, everything is funnelled into the right category automatically when the coders know that anything having to do with settings will have a necessary front end already provided. There will be no need to create yet another program front-end for the purpose. GUI design duplication will be eliminated and more standardized by being in one place. With a little thought, one might even see more things that can be handled by the same GUI front-end.
From a users point of view, it makes sense to add the mime editor to the preferred applications dialog. Since this is not part of libexo, I don't actually see the problem with adding it here.
Yeah, I don't see any problems either. exo-preferred-applications is integerated into the settings manager in the same way all other dialogs are and it's the only dialog we have that deals with default applications for something. Feels like the right location to me.
Then, from a user's standpoint, can we agree to see the settings manager as a sort of simple front-end dialog for the other components that do things with the settings?
*** Bug 6535 has been marked as a duplicate of this bug. ***
So what is the consensus here? And what is the status of this feature request? Thanks.
Will look at this for 4.10, if time permits it.
Thanks for the response and target version number. By the way, I just realized that it would be nice if there was a place where users could see a list of features being worked on at the present time, along with a way to vote for their preferences. Regardless of the coders own preferences, it would seem that they would appreciate knowing what their users prefer in order of importance. Thanks again.
Bug #6800 contains some related info about this.
Probably relevant to this discussion is how to remove such an association if it is wrong or needs changing to a new choice? It seems the gui allows the setting of a choice but not its removal.
Would it be possible to have the user be able to select a null setting from a drop-down list? If the user makes her preferred association from a list of available choices, wouldn't null (or similar) be on the list? Each time the user edits her list of association preferences, the dialog would require a "Save" action before closing; else "Cancel".
Added to xfce4-settings, ready to be merged in master.