Bug 88534

Summary: Lack of ability to change assoications to serval selected "known Types"
Product: [Applications] systemsettings Reporter: Alex <bornio>
Component: kcm_filetypesAssignee: David Faure <faure>
Status: CONFIRMED ---    
Severity: wishlist CC: karl.kjellgren
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Alex 2004-08-31 15:09:16 UTC
Version:            (using KDE KDE 3.3.0)
Installed from:    Gentoo Packages
OS:                Linux

I would love the ability to change Application Preference Order to serval File Types at once.
As opposed to creatine a new filetype, and adding all filename patterns, I think it would be  much easier to edit a whole bunch of files at once.
For example, selecting AAC, AC3, MP4 and MP3 in the Known Typed, under Audio, and then perhaps have it to list all application that all of them use and more importently, to be able to add an application to start them myself.

Taking the same four file types, and say I want them to open with Amarok, it would be great if i could just select them in the list, hit "add", type "amarok" and hit Apply, which would change it for all four file types at once.

Alex V.

bornio@gmail.com
Comment 1 Dotan Cohen 2007-11-29 13:05:23 UTC
As kcontrol groups filetypes by purpose (application/audio/text/video/etc) then it would be logical that one could select a group (say Audio) and then select a default application for that group (say Amarok).

I understand that there may be cases in which there is a specific filetype in a group for which the preferred application is not an option (in audio,for instance, ac3 files do not list Amarok as an option). In those cases KDE could do one of two things:
1) Do nothing. Just leave the unsupported filetypes as they are and warn the user that some filetypes could not be changed.
2) Ask the user if he wants to change the unsupported files as well, or not.
Comment 2 David Faure 2008-03-04 12:53:54 UTC
*** Bug 110392 has been marked as a duplicate of this bug. ***