Fixing 35071 - mimetype regeneration

David Faure dfaure at
Thu Mar 27 21:26:15 GMT 2003

Hash: SHA1

On Wednesday 26 March 2003 17:48, Ravikiran Rajagopal wrote:
> Hello,
>   I am trying to fix without much
> success. KMimeType::Ptr's pointee does not seem to update even after the
> system configuration cache is rebuilt. How do I force it to update?
Getting a new KMimeType::Ptr from ksycoca, using KMimeType::mimeType(...)
The tricky bit is to do it at the right time, i.e. after kbuildsycoca ran...
KOpenWithDialog does that by launching kbuildsycoca itself, but this blocks
the GUI for a long time before it can proceed (it needs the updated KService object).

In kcmfiletypes I just fixed it using the "databaseChanged()" signal, which tells
us kbuildsycoca finished running. With isChanged() we can check the mimetypes
have indeed been changed (there's still a risk here, that something else is
modifying mimetypes at the same time... but that's rather theoretical IMHO).

Waldo: I noted that kbuildsycoca rebuilds the vfolder stuff even when --incremental
was given and only mimetypes were modified. Can it skip that in such a case?

> Should I add a method to KMimeType asking it to update? 
I'd rather not. This would only work properly with "kmimetypes that come from ksycoca",
not for "KMimeType created from a .desktop file" (see the various constructors).

>   I can generate new pointers to the same mimetype (via KMimeType::mimeType)
> which point to updated data. If that is the only way, how do I delete the
> pointer?
You don't need to. A KMimeType::Ptr is a KSharedPtr: it deletes the KMimeType
object once there is no more reference to it. This is the whole reason why we don't
use KMimeType *.

- -- 
David Faure -- faure at, dfaure at
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions
Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list