Version: 1.8.2 (using KDE 3.4.2, Debian Package 4:3.4.2-4 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.8 Scenario: 1. I get email with .pgn file attached (this is standard for representation of chess games in case anyone is interested) 2. I click this attachment. I am prompted whether to save or open (I select open and select not to be prompted anymore) 3. I am prompted which application to use. I enter /usr/bin/knights (KDE chess program) [ I can also search for this in displayed list, the result is the same ] and I click checkbox 'always use this program to open this' 4. There is noticeable delay while comment about updating KDE settings is visible. 5. knights spawns correctly with given file. 6. I open next email containing .pgn file. 7. I click the attachment. This time I am not prompted whether to open or save (right) but ... I am again prompted which application to use. Again I select knights, click 'always use this' 8. Repeat as long as you like, every time I open png attachment, kmail prompts me which program to use.
Amazing extra I just noticed: when I got email with '.txt' attachment (and clicked it) kmail offered me 'Open in knights' button! For .pgn files it still is not offered. Looks like some confusion between extension and mime-type is here. PGN files are 'text/plain' from the mime point of view... So I would bet that it is so: a) when I get PGN and ask kmail to always open it with knights, it sets this action for 'text/plain' instead of setting it for '.pgn' b) when I want to open .txt, 'text/plain' action set above is used c) when I want to open .pgn for some reason kmail finds the action above unsuitable Clearly, something is wrong and there are two separate problems: a) and c). a) is about design - looks like mime type itself is not enough to describe attachment type (there are plenty of 'special' textual attachments, apart of my .pgn I could mention even .cxx, .py, .pl, .sql, ... - one can wish to use different actions to open them) c) looks more like a bug, probably when file extension is not 'first' on mime-type list, it is not matched to the rule estabilshed
*** This bug has been marked as a duplicate of 81561 ***