Exception for Dolphin - KFileMetadataWidget
Vishesh Handa
me at vhanda.in
Fri Dec 21 10:57:17 UTC 2012
Hello release team
As most of you must know for KDE 4.9, a new package nepmuk-core was
released, and with 4.10 we are now releasing nepomuk-widgets. The
nepomuk-widgets initially just contained the Tagging and Rating widgets,
which were adapted from kdelibs/nepomuk/ui. I use the word "adapted" cause
their internals were ported to the new asynchronous APIs (which was the
reason nepomuk-core was created)
One of the primary ways users tag and rate files is through the information
panel in Dolphin. The main widget in this panel is the KFileMetadataWidget
(kdelibs/kio/kfile/*). This widget has many problems -
* Uses the old Nepomuk Resource API from kdelibs - very buggy
* Uses the old Nepomuk widgets from kdelibs - slower and not maintained
* Had a multi-process architecture which involved spawning a new process
which provided the Nepomuk / Strigi ** data. This was done cause Strigi is
known to crash a lot.
* Cause of this multi-process architecture it was very slow - specially on
the Nepomuk side cause it would re-create the caches each time the process
was run. This was especially wasteful because Dolphin itself uses Nepomuk
and would have those caches. (The caches are not cross-application)
* Hacking on the widget was hard - Its entire architecture is quite
convoluted.
I wanted to fix this with 4.10, so I copied most of the widget to
nepomuk-widgets and named it Nepomuk2::FileMetadataWidget. This "new"
widget was added in the feature plan [1]. It was never marked as completed
cause it had some bugs, which I did not have the time to fix. It was
however, still merged before the hard feature freeze.
I did not submit my patch to use this widget in Dolphin, as it had some
bugs, and I did not want to spoil Dolphin's experience. In hind-sight maybe
I should have submitted it, and gotten all the bug reports.
Fast forwarding to present time
----------------------------------------------
I finally squashed the last of the bugs in the widget, and made it support
displaying indexing results even when the file was not indexed or Nepomuk
is disabled. The old KFileMetadataWidget had the same capability - It used
Strigi, while we use the new file indexer that I've been working on.
I would like to use this new widget in dolphin for 4.10. I was told to ask
for an exception from the release team. We still have one more release
candidate to go, so it should get adequate testing, if not the full amount.
Other advantages -
* It is a LOT faster - and it feels like it (Patch attached, if you want to
try it out)
* Easier to maintain
* Uses the Nepomuk2 widgets which are actively maintained, and will thus
get the required bug fixes. They have been some bugs filed against Dolphin
and its tagging behaviour, fixing this would be quite hard in
kdelibs/Nepomuk, also I don't want to mess with that code base which barely
gets tested any more.
* Since Dolphin also uses Nepomuk2, and the new widget does not spawn a new
process for the Nepomuk data, it can re-use the already filled caches.
* This gives a much better experience even when Nepomuk is disabled.
* This new widget's internal architecture is a lot better, and it's easy to
modify - So it's easy to improve.
If we do not ship this new widget, I'll have to clean up the
KFileMetadataWidget cause it shows a lot of ugly data like "Resource
Created", arguably this isn't very hard. However it is not something I want
to do. Ditto for kdelibs/nepomuk/*.
So, may I merge my patch into kde-baseapps 4.10? It will get tested more
thoroughly in RC2.
[1] http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan
--
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20121221/febd46bc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dolphin-nepomuk-widgets.patch
Type: application/octet-stream
Size: 6663 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/release-team/attachments/20121221/febd46bc/attachment.obj>
More information about the release-team
mailing list