Introduction
============

The origin of this feature request is at https://bugs.kde.org/show_bug.cgi?id=279786#c2 The linked report is the result, in my opinion, of a usability issue with Dolphin’s Properties dialog’s General tab’s Type field.

When you look at that tab, the Type field shows the description of the filetype Dolphin (or the system) guessed the file was. But imagine Dolphin guessed the wrong MIME type, imagine it is a new filetype Dolphin knows nothing about. What will the user do then?


The Problem — Use Case
======================

Imagine — as reported in #279786 — Dolphin detects a *.graphml file as an XML file. But the user wants to open the *.graphml file with a different application that the one he uses for XML files. What will the user do then? Have in mind that most users won’t know about the File Associations settings module; in fact, they might not even know what a MIME type is.

As things are currently in Dolphin (see Screenshot 1), our user would likely click the tools icon with the tooltip “Edit file type” and change the application to open the selected file, changing the setting for all XML files as a side effect. Something he will not realize right away, but eventually. Once he does, he will be frustrated by his apparent inability to choose a different application to open “*.graphml” and “*.xml” files.

But it might get even worse. If the user, who does not understand of filetypes, thinks the changes in the dialog to change the file type will only affect the selected file — as opposed to all XML files — he might end up removing “*.xml” from the extension list (“Of course!“, he thinks, ”I don’t want *.xml files to get mixed up with this filetype — that is, *.graphml’s”), changing the description, and of course the application to run the files with.


The Cause
=========

And I think a user might end up doing things like these because, the way the Properties dialog puts it, it seems the more logical course of action. That is, when the user sees the filetype description in the Properties dialog, and he wants to change because it is wrong (“Mine is not a simple XML file, is a GraphML file!”), the only thing that makes sense is to click the button that says “Edit file type”. There is no other way.


The Solution
============

The best solution I can think of is:
- Turn the MIME type description in the Properties dialog (besides “Type:”) into a button.
- When that button is clicked, a dialog just like File Associations opens up with the current file’s filetype selected in the tree.
- The purpose of this dialog would be to “Edit the filetype of the current file”, as opossed to manage all the known filetypes, so once closed, whatever filetype the user has currently selected must be associated to the current file. So, when the dialog is closed by clicking Accept:
    - If the selected file (e.g. “test.graphml”) matches one of the patterns in the selected filetype, everything went as expected, so just get back to the Properties dialog, and update the filetype button label to reflect the changes.
    - If the selected file does not match any of the patterns of the selected filetype, prevent the dialog from being closed, and show a new (warning?) dialog over it:
    
        Legend: <Replace Me> {Button} [ Option 1 | Option 2 ]
    
        The filename “test.graphml” does not match any of the patterns of “<MIME type of the selected filetype>”.
        
        Current File Pattern: <Input field with a pattern guessed from the filename, “*.graphml” in this case>
        
        {Add Pattern to <MIME type of the selected filetype>} {New Filetype for Pattern} {Cancel}
        
        - The first button would add the pattern defined in the input field to the selected filetype, and take the user back to the Properties view.
        - The second button would open a dialog like the one that pops up when you click the Add button in the File Associations module. Once the user enters a code for the new MIME type, he is taken back to the File Associations-like dialog, with the new filetype selected and with the previously selected pattern already added to the list of patterns. The rest of the data for the new filetype could be filed with the data of the previous filetype — the one that was automatically (and presumably wrongly) associated to the current file in the first place.
        - If the Cancel button is clicked, just get back to the File Associations-like dialog.
        - NOTE: The first and second buttons should be deactivated (grayed out) while the pattern entered does not match the target filename (“test.graphml”), and a message in red should be displayed below the input field explaining this.
        - NOTE 2: If the pattern in the input field matches any pattern in an existing filetype, add a warning below the input field about it. If the user clicks the first or second button under this circumstance, print the following dialog:
            
            Do you want to remove the “<pattern>” pattern from “<MIME type using the pattern already>” to use it in [ “<MIME type of the selected filetype>” | the new filetype ] ?
            
            {Remove} {Cancel}
            
            - {Remove} would remove the pattern from the filetype currently using it, and would continue with the action of the button pressed in the previous dialog, first or second.
            - {Cancel} would get back to the previous dialog, preventing the actions associated to the clicked button (first or second) from being triggered this time.
- If the user clicks Cancel in the File Associations-like dialog, the filetype button label in the Properties dialog should be updated anyway, since the user might have performed changes in the File Associations-like dialog (by clicking Apply instead of Accept) that might affect the filetype matching the file selected in Dolphin.
- Regarding the “Edit file type” button, there would be no change. Users would likely click the button with the filetype description before trying the tools button.


Closing
=======

I really hope, if anyone finds the time to read them, that these “specifications” can be correctly understood. I really think this would be a good approach from the user’s perspective, although I understand that — from the technical point of view — this would be a rather large change, not trivial at all.

Reproducible: Always