<br><br><div class="gmail_quote">On Thu, Oct 18, 2012 at 3:15 PM, Frank Reininghaus <span dir="ltr"><<a href="mailto:frank78ac@googlemail.com" target="_blank">frank78ac@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Hi Vishesh,<br>
<br>
2012/10/15 Vishesh Handa:<br>
</div><div class="im">>> > Maybe we could have a runtime check to see if Nepomuk is running and<br>
>> > accordingly use the new widget / KFileMetadataWidget?<br>
>><br>
>> The disadvantages of this approach are that we would have two widgets<br>
>> to maintain, and that it is not transparent at first sight to the user<br>
>> that enabling/disabling Nepomuk also decides whether he/she gets the<br>
>> 'old' or the 'new' widget. I see a lot of potential for confusion,<br>
>> subtle bugs, and bug reports that are unclear because we don't know<br>
>> which widget is in use.<br>
>><br>
>> Therefore I'm wondering how much work it would be to do the runtime<br>
>> check in the new widget and let it use the new "Strigi replacement"<br>
>> code retrieve the meta data from the file if Nepomuk is disabled?<br>
><br>
><br>
> It would be certain amount of work. I'll have to make some kind of data<br>
> provider class which would either fetch data directly from the database, or<br>
> run the indexers. Plus, as a general rule, since the indexers are plugins<br>
> and we do not control all o them. It would make sense to run them in a<br>
> separate process.<br>
><br>
> That would yield a fairly similar architecture to the one we have right now.<br>
> Maybe slightly more complex, cause in the case when Nepomuk is enabled we<br>
> would be using a thread, otherwise a process.<br>
><br>
> I'm not too keen on doing that right now. I think I'll just code a simple<br>
> replacement which only uses Nepomuk, and then start with the indexing<br>
> information. I'm more concerned with having a good user experience when<br>
> Nepomuk is enabled.<br>
<br>
</div>I fully understand that, but please understand that I'm trying to<br>
provide a good user experience to *all* Dolphin users.<br>
<br>
Would you be willing to accept patches for the new widget which enable<br>
it to retrieve the information on demand if Nepomuk is disabled, if<br>
someone volunteers to do that at some point? If that is the case,<br>
having a runtime check in the Information panel and using the 'old'<br>
widget from kdelibs as a fallback might be an acceptable temporary<br>
solution.<br></blockquote><div><br>Sounds like a plan.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
By the way, since the Nepomuk2 port, we get crash reports like<br>
<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=308520" target="_blank">https://bugs.kde.org/show_bug.cgi?id=308520</a><br>
<a href="https://bugs.kde.org/show_bug.cgi?id=308523" target="_blank">https://bugs.kde.org/show_bug.cgi?id=308523</a><br>
<a href="https://bugs.kde.org/show_bug.cgi?id=308525" target="_blank">https://bugs.kde.org/show_bug.cgi?id=308525</a><br>
<br>
The bt of the last one shows that we're having trouble because<br>
Nepomuk2::ResourceData::store() uses nested event loops. That causes<br>
an unexpected recursion of<br>
KFileItemModelRolesUpdater::resolveNextPendingRoles() because that<br>
function invokes itself using a single shot timer. The problem is that<br>
multiple recursed invocations of that function try to manipulate the<br>
same QSets, so we end up with corrupted iterators and crashes.<br>
<br>
IMHO, nested event loops are evil. This isn't the first time I see<br>
them cause a crash. Even the API docs of KJob say that you shouldn't<br>
do it:<br>
<br>
<a href="http://api.kde.org/4.9-api/kdelibs-apidocs/kdecore/html/classKJob.html#a03c768fad2f9eef7b72b068b389c42ee" target="_blank">http://api.kde.org/4.9-api/kdelibs-apidocs/kdecore/html/classKJob.html#a03c768fad2f9eef7b72b068b389c42ee</a><br>

<br>
This must be fixed.<br></blockquote><div><br>I'll take care of it.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards,<br>
Frank<br>
</blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br><br>