Version: (using Devel) OS: Linux Installed from: Compiled sources I was trying to associate "JuK" with the audio/mp3 file type. Systemsettings -> Advanced -> File-Types (or similar, german locale here) Then type mp3 into the searchbox, then expand audio -> mp3 Now add "juk" to the applications, it will be added to the list. So far so good. But after clicking "apply", all changes will be lost and old settings are restored. If I call "keditfiletype audio/mp3" from the console and edit filetypes there it works as expected and the kcm module will show the new settings too.
Here using: Qt: 4.5.1 (qt-copy 971295) KDE: 4.2.92 (KDE 4.2.92 (KDE 4.3 >= 20090617)) kdelibs svn rev. 984425 / kdebase svn rev. 984427 on ArchLinux i686 - Kernel 2.6.29.4 I can reproduce the bug
Further tests: - "keditfiletype audio/mp3" works properly - "kcmshell4 filetypes" also shows this behaviour. Modifying the apps for "audio/mpeg" works properly, but not for "audio/mp3" Just note that "audio/mp3" is not a "real mimetype" but the extension for "audio/mpeg". (Also, when "audio/mpeg" is selected, the filename patterns show "mp3" and "mpga"; however if "audio/mp3" is selected, no filename patters are shown) @David: Could this be related then to this mixup of real mimetypes and extensions ?
Oh, I'm guessing something: When you have the complete dialog: if you edit the "audio/mp3" mimetype, if you add an application , then this is saved, but then the kcmshellApp will save the associated applications for "audio/mpeg" (as this is order by name ascending), and as "audio/mpeg" doesn't have this new added assoc application, it will delete it. And therefore, when the kcmmodule is updated after save, the "audio/mp3" "mime" will reflect the state of "audio/mpeg". That would explain the associated programs not being remembered in this weird case.
This bug still exists in 4.3.85 :-(
I don't even have a audio/mp3 mimetype. The mimetype for mp3 files is audio/mpeg. audio/mp3 is an alias for audio/mpeg Hmm. I'll have to look at what we do with aliases....
I have the same problem. But it is strange that, for example, mp3.xml is present in ~/.local/share/mime/audio/ (created by KDE for each first launch of a new user) and does not exist in /usr/share/mime/audio/ I use Kde 4.3.4 on a Debian sqeeze with shared-mime-info 0.70-1 version
Then there is a packages file that defines audio/mp3 for you. KDE doesn't define it, it must come from somewhere else (wine, maybe, or some distro hack). Please search for "audio/mp3" in every directory returned by the command "kde4-config --path xdgdata-mime --locate packages/" and tell me what you find. E.g. grep mp3 ~/.local/share/mime/packages/* but also any other directory returned by the command above.
Hi David, I am not Francesco, but I have that mp3.xml too, generated by gentoo's update-mime-database tool. mschiff@bart ~ $ kde4-config --path xdgdata-mime --locate packages/ /home/mschiff/.local/share/mime/packages/ mschiff@bart ~ $ grep mp3 ~/.local/share/mime/packages/* /home/mschiff/.local/share/mime/packages/application-x-nsv-vp3-mp3.xml: <mime-type type="application/x-nsv-vp3-mp3"> /home/mschiff/.local/share/mime/packages/audio-mp3.xml: <mime-type type="audio/mp3"> /home/mschiff/.local/share/mime/packages/audio-mp3.xml: <glob pattern="*.mp3"/> mschiff@bart ~ $
I have found the same result of Marc Schiffbauer, except of the record "<glob pattern="*.mp3"/>
The problem comes from this file, then: /home/mschiff/.local/share/mime/packages/application-x-nsv-vp3-mp3.xml From its name, I would say that it was created by a webbrowser plugin (also called "netscape plugins"). Can you confirm that this file says "<!--MimeType generated by nspluginscan-->"? Ah! And in that case, I found the bug: pluginscan.cpp uses KMimeType::mimeType() without "ResolveAliases" so it thinks the mimetype doesn't exist, and defines it. Pino is right, we really have to change mimeType() so it resolves aliases by default.
Hi David, bingo!: cat /home/mschiff/.local/share/mime/packages/application-x-nsv-vp3-mp3.xml <?xml version="1.0" encoding="UTF-8"?> <!--MimeType generated by nspluginscan--><mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info"> <mime-type type="application/x-nsv-vp3-mp3"> <comment>Nullsoft Streaming Video</comment> </mime-type> </mime-info> Great that you found the bug! Any chance to find a bugfix in 4.4.2 then? Marc
SVN commit 1097954 by dfaure: As discussed with Pino: make alias resolution the default in KMimeType::mimeType. There is just no good reason not to, aliases can be used anywhere, especially with shared-mime-info replacing mimetypes with aliases over time (e.g. image/ico). This fixes at least two bugs: 1) a bug noticed by Pino: if you set the old name as filter in kfiledialog, when updating s-m-i it won't work anymore (because aliases are not resolved) 2) the bug that nspluginscan would define mimetypes because "unknown" when they are in fact aliases. BUG: 197346 Fixed for: 4.4.2 M +1 -1 services/kmimetype.h M +8 -4 tests/kmimetypetest.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1097954