in the original KDE implementation it was used along with Nepomuk,
but Nepomuk support was dropped yet some semantic URIs are still
used across the KDE applications (e.g. dolphin, gwenview) for
info other than size, date of modification, etc. thus keeping a
local static mini-hash for the kfileitem properties is not very
good as knfotranslator has its own hash mechanisms thus the
translator items got merged into the translator and is now fully
utilized hopefully dropping the memory usage a little bit of the
metadata provider.
with bea1df1c the service file was removed but it is actually
needed, only the deprecated API is not since it is re-implemented
in another form as KFileItemActions (KAbstractFileItemActionPlugin)
From: Simeon Bird <bladud@gmail.com>
Date: Thu, 18 Dec 2014 03:54:32 +0000
Subject: Fix crash in KIO due to exposing inconsistent views of internal data.
X-Git-Tag: v4.14.8
X-Git-Url: http://quickgit.kde.org/?p=kdelibs.git&a=commitdiff&h=4288d7e7c81839d6bdb25b1197c6e614f0259036
---
Fix crash in KIO due to exposing inconsistent views of internal data.
This can be triggered by renaming a directory while one of the files in
it is open in gwenview.
It occurs because when KCoreDirListerCache::emitRedirections is called,
itemsInUse contains the old url. However, KDirLister::Private::redirect
changes lstDirs to the new url. Thus at this point lstDirs contains an
item not in itemsInUse, which causes an assertion if forgetDirs is
called.
In gwenview, the redirection signal is connected to openURL. This calls
forgetDirs, and causes the assertion.
The solution: update itemsInUse *before* emitting redirections.
This fixes the crash, but gwenview opens the first file in
the new directory instead of the file open before renaming.
This is probably an unrelated gwenview bug.
REVIEW: 117345
---
sometimes with metadata that has many small value entries the
widget rows were overlapping. in the process of fixing this a
minor cleanup was done - two less temporary variables are assigned
namely "Part of" and an extra "Type". The "Part of" filed is not
very obvious and in most cases just a null (empty string), the
extra "Type" refers to some sorta Semantic spec thing is not more
than useless as two other MIME information fileds are show - one
with a human friendly and one with programmers friendly string in
it and are more than enough in most if not all cases.
