[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-release-team
Subject: Re: Exception for Dolphin - KFileMetadataWidget
From: Vishesh Handa <me () vhanda ! in>
Date: 2012-12-21 21:48:50
Message-ID: CAOPTMKB-ZHNGB6wXZznWvh2V3aGAzNBQpssso1rcSr_qpBoWZg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Dec 22, 2012 at 3:03 AM, Albert Astals Cid <aacid@kde.org> wrote:
> El Divendres, 21 de desembre de 2012, a les 16:27:17, Vishesh Handa va
> escriure:
> > 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.
>
> What's the opinion of the Dolphin maintainer?
>
He says I should ask the release team.[1]
[1] http://lists.kde.org/?l=nepomuk&m=135601861024534&w=2
>
> Cheers,
> Albert
>
> >
> > [1] http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan
>
--
Vishesh Handa
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, \
Dec 22, 2012 at 3:03 AM, Albert Astals Cid <span dir="ltr"><<a \
href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br> \
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">El Divendres, 21 de desembre de 2012, a les \
16:27:17, Vishesh Handa va<br> escriure:<br>
<div><div class="h5">> Hello release team<br>
><br>
> As most of you must know for KDE 4.9, a new package nepmuk-core was<br>
> released, and with 4.10 we are now releasing nepomuk-widgets. The<br>
> nepomuk-widgets initially just contained the Tagging and Rating widgets,<br>
> which were adapted from kdelibs/nepomuk/ui. I use the word "adapted" \
cause<br> > their internals were ported to the new asynchronous APIs (which was \
the<br> > reason nepomuk-core was created)<br>
><br>
> One of the primary ways users tag and rate files is through the information<br>
> panel in Dolphin. The main widget in this panel is the KFileMetadataWidget<br>
> (kdelibs/kio/kfile/*). This widget has many problems -<br>
><br>
> * Uses the old Nepomuk Resource API from kdelibs - very buggy<br>
> * Uses the old Nepomuk widgets from kdelibs - slower and not maintained<br>
> * Had a multi-process architecture which involved spawning a new process<br>
> which provided the Nepomuk / Strigi ** data. This was done cause Strigi is<br>
> known to crash a lot.<br>
> * Cause of this multi-process architecture it was very slow - specially on<br>
> the Nepomuk side cause it would re-create the caches each time the process<br>
> was run. This was especially wasteful because Dolphin itself uses Nepomuk<br>
> and would have those caches. (The caches are not cross-application)<br>
> * Hacking on the widget was hard - Its entire architecture is quite<br>
> convoluted.<br>
><br>
> I wanted to fix this with 4.10, so I copied most of the widget to<br>
> nepomuk-widgets and named it Nepomuk2::FileMetadataWidget. This \
"new"<br> > widget was added in the feature plan [1]. It was never \
marked as completed<br> > cause it had some bugs, which I did not have the time to \
fix. It was<br> > however, still merged before the hard feature freeze.<br>
><br>
> I did not submit my patch to use this widget in Dolphin, as it had some<br>
> bugs, and I did not want to spoil Dolphin's experience. In hind-sight \
maybe<br> > I should have submitted it, and gotten all the bug reports.<br>
><br>
> Fast forwarding to present time<br>
> ----------------------------------------------<br>
><br>
> I finally squashed the last of the bugs in the widget, and made it support<br>
> displaying indexing results even when the file was not indexed or Nepomuk<br>
> is disabled. The old KFileMetadataWidget had the same capability - It used<br>
> Strigi, while we use the new file indexer that I've been working on.<br>
><br>
> I would like to use this new widget in dolphin for 4.10. I was told to ask<br>
> for an exception from the release team. We still have one more release<br>
> candidate to go, so it should get adequate testing, if not the full amount.<br>
><br>
> Other advantages -<br>
><br>
> * It is a LOT faster - and it feels like it (Patch attached, if you want to<br>
> try it out)<br>
> * Easier to maintain<br>
> * Uses the Nepomuk2 widgets which are actively maintained, and will thus<br>
> get the required bug fixes. They have been some bugs filed against Dolphin<br>
> and its tagging behaviour, fixing this would be quite hard in<br>
> kdelibs/Nepomuk, also I don't want to mess with that code base which \
barely<br> > gets tested any more.<br>
> * Since Dolphin also uses Nepomuk2, and the new widget does not spawn a new<br>
> process for the Nepomuk data, it can re-use the already filled caches.<br>
> * This gives a much better experience even when Nepomuk is disabled.<br>
> * This new widget's internal architecture is a lot better, and it's easy \
to<br> > modify - So it's easy to improve.<br>
><br>
> If we do not ship this new widget, I'll have to clean up the<br>
> KFileMetadataWidget cause it shows a lot of ugly data like "Resource<br>
> Created", arguably this isn't very hard. However it is not something I \
want<br> > to do. Ditto for kdelibs/nepomuk/*.<br>
><br>
> So, may I merge my patch into kde-baseapps 4.10? It will get tested more<br>
> thoroughly in RC2.<br>
<br>
</div></div>What's the opinion of the Dolphin \
maintainer?<br></blockquote><div><br></div><div>He says I should ask the release \
team.[1]<br><br></div><div>[1] <a \
href="http://lists.kde.org/?l=nepomuk&m=135601861024534&w=2">http://lists.kde.org/?l=nepomuk&m=135601861024534&w=2</a><br>
<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Cheers,<br>
Albert<br>
<br>
><br>
> [1] <a href="http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan" \
target="_blank">http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan</a><br> \
</blockquote></div><br><br clear="all"><br>-- <br><span \
style="color:rgb(192,192,192)">Vishesh Handa</span><br> </div></div>
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic