(*** This bug was imported into bugs.kde.org ***) Package: kcmfiletypes Version: unknown (using KDE 2.9.0 1 (CVS >= 20011012)) Severity: normal Installed from: compiled sources Compiler: gcc version 2.95.3 20010315 (SuSE) OS: Linux (i686) release 2.4.10-4GB OS/Compiler notes: The last filename pattern being removed from the list of patterns in kcmfiletypes won't get removed from the configuration file in ./kde/share/mimelnk/foo/bar.desktop. I'll demonstrate it with the 'all/all' MIME type here: 1.) Make sure that the box labelled Filename Patterns is empty. 2.) Add a pattern 'foo' to the list. 3.) Press 'Apply'. [The pattern now gets saved in the list (which can be verified by loading .kde/share/mimelnk/all/all.desktop in the editor of your choice.] 4.) Remove the entry 'foo' from the list. 5.) Press 'Apply' again. [The pattern opposing to my expectations won't get removed from the above configuration file.] This can be especially unfortunate if it's the '*' pattern which can't be removed. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
Subject: Defeated The problem is that the variable TypeListItem::m_mimetype returns the same (original) list of patterns regardless of whether we had synced or not. The problem lies with KMimeType. It needs some sort of refresh() operator, without which this bug cannot be solved. When you add foo, m_mimetype->patterns() returns original, while m_patterns has original+foo, so the comparison in isDirty() fails and the new mimeType is written. Now, if you remove foo, m_mimetype->patterns() still returns original(!), while m_patterns has original, so the isDirty() comparison succeeds and we don't sync again, even though we should. An ugly hack would be to use a local variable m_oldpatterns, but that simply hides the problem in KMimeType. Anyone have an idea? Regards, Ravi
Subject: kdebase/kcontrol/filetypes Get an updated KMimeType::Ptr from ksycoca after it ran. Ravikiran: thanks for the investigation, it helped.