Just what the title says. :)
May I ask why not just right-click any .torrent file -> Open With, choose the preferred app and "Remember application association..."? Or you will have to do this for a lot of file extensions and mime types.
There is Applications -> file associations x-bittorrent If that isn't enough, please reopen and say why this isn't enough.
Because that's not a user-friendly user interface. We want to move in the direction of making this page the basic view that suffices for 99% of users, and putting the super nerdy super complicated file associations KCM a one-level-deeper advanced view
The current split is: URI handlers File associations that may be an implementation detail leaking into the UI, but it has some consistency to it I completely agree that file associations KCM needs some work, but I don't understand the report that seems to suggest we would treat choosing your .torrent files association differently to choosing your preferred editor for .stl files or whatever.
(In reply to David Edmundson from comment #4) > The current split is: > > URI handlers > File associations > > that may be an implementation detail leaking into the UI, but it has some > consistency to it It does, but it is. :) The problem is that it's a very developer-centric split. Think about it from a user perspective. To a user, configuring which is your default torrent client is in the same wheelhouse as configuring your default web browser or email client. In this line of thought, the File Associations KCM should be used for selectively and optionally overriding the default settings in the componentchooser KCM. Does that make sense?
Not really. I haven't heard a reason to make this one particular file a different case from all of the other file types.
In a nutshell, because the Component Chooser KCM now has a good UI, while the File Associations KCM has a bad UI. Part of the reason for the latter is because the File Associations KCM uses mimetypes as the base level of organization. Choosing a mimetype and then choosing a sequence of apps to associate with that mimetype is never going to be easier than choosing an app to associate with a user-friendly string (e.g. "Torrent client").
Then we need to clean the UI in a way that has user friendly strings for all the things.
Default Applications in my humble opinion has its use. E.g. if it handled media type with many subtypes. You have **Audio Player** there and instead of going manually and setting the default application for each one of aac, ac3, amr-wb, amr, flac, midi, mp2, mp3, ogg, realaudio, ... from `File Associations`, or by right-clicking each one of those types, it's a one-click away. The same applies for **Video Player**, **Image Viewer**, ... Does that make sense?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Comment 9 doesn't clarify why a special UI setting for torrent client is needed.
Basically, because the mimetype-based component chooser has a subpar UX, meaning that any given mimetype-to-app mapping is hard to find. The tree view is basically useless and you need to use the search, but the tree view has much more visual prominence then the search. It needs a redesign. Maybe that would be better discussed in a Phab task or the VDG channel than a bug report though.
Yes, UX can be improved. But that doesn't justify why torrent files need to be treated specially compared to, say, Office or Blender files. KTorrent for example, registers itself as a handler for torrent files, so if you have it installed, it works automatically. If other applications also register as a handler, then the new UI could automatically display combo boxes for all file types that have multiple handling applications registered.
(In reply to Christoph Feck from comment #11) > Comment 9 doesn't clarify why a special UI setting for torrent client is > needed. You misunderstood my comment. I am the first to reply and say not to treat torrent as a special case. The things I suggested adding to Default Applications are things like Default Video Player, and I already explained the reason. It saves tremendous time and this is the norm in other OS's. May be this should be a separate bug.
Feature to set default video player was already requested - bug 232545.