KDE 4.13.1 Dolphin Information Panel, No Meta Data

Well, you definitely had libstrigi0 installed, since that is required (as package dependency) by the openSUSE 13.1 libkde4 package.

But the metadata extractors are in the “strigi” package.
And I checked now: when I uninstall “strigi”, no metadata is shown any more in the rename dialog. But it still shows the filetype, size and preview:
http://wstaw.org/m/2014/05/21/dolphin3.png
This makes sense, as it apparently uses/needs strigi to get the metadata.

But what doesn’t make sense is, that it does show the metadata if you copy an (with Baloo) indexed file. So somehow this does seem to use Baloo (I find that surprising actually, but it is definitely the case, since I deleted my Nepomuk database already so the file cannot possibly be indexed there, and Nepomuk is not running anyway), but falls back to strigi for not-indexed files (as before I suppose).

And apparently building without any strigi (or Nepomuk?) support also removes the code for the basic file information.

Nepomuk/Soprano were definitely installed.

Yes, the packages required it.

But I thought the rename dialog would not have used NepomukV2 anyway. Apparently it has, and is using Baloo now (with a fallback to strigi for not-indexed files).
And what I still don’t get: if they could port the rename dialog to NepomukV2 and Baloo, why did they have to remove the “Information” tab in the “Properties” dialog completely and could not port that as well? Hm…

:\ … I’m beginning to get the feeling something is amiss with my setup here …

Currently neither strigi or libstrigi0 are installed. Yast2 > update unconditionally (libkde4) > dependencies (check now) - reports package dependencies OK

I have now installed strigi / libstrigi0 and (this time) will leave them in place. System re-booted…

But the metadata extractors are in the “strigi” package.
And I checked now: when I uninstall “strigi”, no metadata is shown any more in the rename dialog. But it still shows the filetype, size and preview:

That’s when you compiled without '-DKIO_NO_STRIGI=ON ’ ?

Leaving aside baloo and metadata, all I see in the rename dialogue is path/filename.

Because:

And apparently building without any strigi (or Nepomuk?) support also removes the code for the basic file information.

I’m losing the plot again … rotfl!

I’m talking about the 4.11 package included in standard 13.1.
The 4.13 libkde4 does not require libstrigi0, as it is built without strigi support.

I have now installed strigi / libstrigi0 and (this time) will leave them in place. System re-booted…

The libkde4 from KDE:Current doesn’t use it at all at the moment.

That’s when you compiled without '-DKIO_NO_STRIGI=ON ’ ?

Yes.
With that option all the code that uses strigi is removed, and apparently also the code that shows the file type/size/preview (that could also be because of “-DKIO_NO_NEPOMUK=ON” though, I haven’t checked yet, rebuilding takes over an hour…).

Leaving aside baloo and metadata, all I see in the rename dialogue is path/filename.

Because:

Yes. The package in KDE:Current is built with -DKIO_NO_STRIGI=ON and therefore also the code for showing file size and type is missing. (I think, could also be “-DKIO_NO_NEPOMUK=ON”)

Regarding baloo: the package doesn’t have any build time or package requirement on baloo (or even Xapian), so shouldn’t use it actually. I have not investigated yet how it gets the indexed metadata then.
For unindexed files it uses/needs strigi obviously (for the metadata like width/height that is, the basic file information is shown even when strigi is uninstalled).

Thanks Wolfi - all much clearer now. :slight_smile:

Small update:
It’s the “-DKIO_NO_NEPOMUK=ON” switch that causes that metadata/filesize display to disappear.

In retrospect this makes even more sense of course.
It is Nepomuk that provided that filemetadata widget, first in kdelibs, then in nepomukwidgets, and now in ballowidgets.

So kdelibs has to be compiled with Nepomuk-support to have that widget.
And it needs strigi to show additional metadata.
Both is missing at the moment in KDE:Current.

Excellent, all is much clearer now. :slight_smile:

Hopefully various bug fixes will eventual filter through to the openSUSE repos.

Thanks once more for your efforts investigating this.

Thanks Wolfi appreciate your hard work in getting to the bottom of this one.

What I don’t understand is, what are the plans to get Baloo widgets to obtain it’s metadata from non indexed files without using nepumuk considering it is supposed to be depreciated ?

Suppose I’ll have to ask Vishesh that question.

Baloo widgets does not use Nepomuk. And AFAIK all (well, most at least) stuff that used NepomukV2 has been changed to use Baloo.

But kdelibs is in feature freeze since 4.8 and therefore is not allowed to depend on/use new external libraries (i.e. NepomukV2 or Baloo). So it still uses NepomukV1 which is actually part of kdelibs itself as I wrote already.
And this will not change until KDE5.

But openSUSE’s 4.13 packages are compiled without Nepomuk(V1), so that old file information widget, which is used by the file rename dialog, does not exist (on openSUSE with KDE 4.13).
Btw, this also affects the information panel in KDE’s file select dialog as I now noticed, which is also part of kdelibs of course.

This issue is not directly related to the switch to baloo though. And it’s not at all related to the original topic of this thread, i.e. the missing meta data in dolphin’s file information panel for not-indexed files. (Dolphin does use Baloo widgets, it is allowed to because it is not part of kdelibs or kde-workspace and therefore not in feature freeze…)

But openSUSE’s KDE maintainers apparently wanted to clean up the packages and get rid of build dependencies.

I’m not sure yet whether they just thought the NepomukV1 stuff is not at all needed/used any more and overlooked those problems, or they decided to get rid of it none-the-less.

I’m going to file an openSUSE bug report later today, we’ll see then…

Sorry, that’s wrong.
The “information panel” in the file dialog is actually only a preview panel.

It only showed a file preview in earlier versions as well, no metadata/file information.

I’m going to file an openSUSE bug report later today, we’ll see then…

https://bugzilla.novell.com/show_bug.cgi?id=879506

I also closed the KDE bugreport, as it is no KDE issue.

We’ll await the outcome … a ‘WONTFIX’ wouldn’t surprise me though. :expressionless:

Well, apparently it’s no WONTFIX… :wink:
https://bugzilla.novell.com/show_bug.cgi?id=879506#c1

So I guess we will find an acceptable solution for this.

This has been going on in one form or another for the last five years and IMHO makes KDE development look very unprofessional and amateurish, can’t even do meta data properly after 5 years and three attempts. Nepumuk (and now Baloo) has been a crisis which has lurched into a disaster, finally stumbling into a catastrophe for far too long. We’ll I have plenty of solutions and none of them involve KDE

Apologies for the rant here folks but this basic function (or lack of) is just a joke.

Thanks for your efforts Wolfi.

Sorry, but that’s not true.

In this case it is because openSUSE removed the necessary support from the packages. You can’t blame KDE or Nepomuk/baloo for that.

In the end I only really see one real baloo problem in this thread, and that’s the issue you originally asked about.
I have a proof-of-concept patch for that.

I don’t see a catastrophe.

:slight_smile: Just read that a few minutes before reading your post here…

We all have our own thoughts and possible ‘solutions’ - personally I think it would have been better if nepomuk was retained for the duration of 4.x. Baloo could have undergone more thorough development/testing and have been introduced with frameworks 5 …

It did happen 5 yeas ago and took nearly a year to fix:

http://forum.kde.org/viewtopic.php?f=15&t=62458

I’m probably being a bit melodramatic here :rolleyes: but the irritations I’ve had over the years with Nepomuk and now Baloo are spoiling KDE for me.

I can forgive many things apart from a desktop GUI that doesn’t give me meta data :slight_smile:

You’re mixing things up now.

The problem you asked about (i.e. no meta data displayed for not-indexed files) happened 5 years ago.
And as I said, I have a patch for that, it is working on my system. So I don’t think this will again take a year to fix.
Btw, back then Vishesh Handa (Baloo’s main developer) did not even contribute to KDE yet AFAIK… :wink:
Sebastian Trueg (of k3b fame) was the main Nepomuk developer back then.
Vishesh joined and took over afterwards and tried to improve it since then. He was the driving force behind NepomukV2 (and Baloo now of course).

The problem with missing metadata in the file rename dialog is caused by openSUSE removing Nepomuk support in the kdelibs packages.
And that’s not the fault of KDE or Baloo’s developer.
The main problem in that case is that kdelibs is not allowed to use/integrate NepomukV2 or Baloo because of the feature freeze since 4.8 as already mentioned. Therefore it still contains NepomukV1 (using strigi to get the metadata).
openSUSE’s KDE-Maintainers wanted to clean up the packages (and get rid of build dependencies) and removed that NepomukV1 completely, because they were not aware of the fact that it is still needed/used for certain features, like the file rename dialog.

Ok, but I think they wanted to have more testing so that it is 100% stable when Plasma next is released.
And it was introduced quite early in the 4.13 release cycle.

But again, this problem is completely unrelated to Baloo.
It is bacause openSUSE removed NepomukV1 from the kdelibs packages.
Even without Baloo the same would have happened.

Points taken. I was thinking more in general terms rather than this specific problem … but it would have helped if I’d said that. :wink:

Yes, you keep indicating that baloo is buggy and unstable.

But it is not in my experience, except for that one bug that this thread originally was about (which I didn’t even notice before, I have to admit).

I know there have been problems with large files f.e. (none of which I experienced), but at least most of them should be fixed already.
And you can switch off the indexer (even with an on/off switch in the configuration module in the meantime… :wink: ).

I still don’t get how suddenly Baloo is much worse/buggy/unstable/whatever than Nepomuk was. It is actually much faster and more resource friendly.
I didn’t even notice it indexing.
And I am not using a highend system here, it’s an 8 year old single core Athlon64 3000+ with an 11 year old 5400RPM hard disk. :wink:

Hi Wolfi,

I digress further and further off-topic >:)

I’m basically a user, not a software developer. I base this on what I see happening, and I’m not alone on this one. I’ve no axe to grind with anyone. I was previously using, and for the purpose of this I will generalise, ‘semantic desktop’ and ‘search’; it was generally quite poor for my needs. Specifically, search was very limited, however, I chose to use it in the belief that it was going to improve. Unfortunately with the introduction of (and here I refer to all changes) KDE 4.13 I saw a marked loss of functionality. Now, you could argue that bugs are inevitable and I should have kept to 4.11(?); I certainly wouldn’t disagree, please though, don’t suggest using a ‘M$’ product. Various bug fixes have occurred and I’m sure there will be many more. As I indicated in earlier posts, I appreciate the work you’ve put in on this. However I stand by what I said, a more mature product, introduced at a more leisurely pace would have seemed, at least to me, a better alternative.

I will digress slightly, I’m using software from ‘KDE:Current’, now that suggests to me as a user, rightly or wrongly, it is stable software that has undergone a degree of testing and is usable with very few (major) bugs. Indeed, that is largely what I see, with the notable exception of baloo et-al. I can’t help but feel that once again the KDE developer community has now found itself having to do more work, under more pressure, whilst carrying out a degree of damage limitation and PR repair. For me, and probably other users, the bottom line is simply: ‘does it work for me?’ and in my case the answer was: ‘as initially released, no’.

And you can switch off the indexer (even with an on/off switch in the configuration module in the meantime… :wink: ).

Yes, as I did by editing ‘baloofilerc’

[Basic Settings]
Indexing-Enabled=false

Now, I was lucky, what of those users who were unaware of the configuration file? Coupled with the fact the ‘official’ method of exclude $HOME from the GUI was being reported by some users as not working.

… in the meantime …

I re-quote you here because these are three very important words - once faith and confidence in (any product) has been lost, there very seldom is ‘a meantime’, more likely forever…

I still don’t get how suddenly Baloo is much worse/buggy/unstable/whatever than Nepomuk was.

Interestingly, perhaps it’s not - maybe my (and others?) expectations of a nepomuk replacement were unrealistic. If there were just a handful of people complaining then those complaints are probably unjustified, I see more than a handful though.

It is actually much faster and more resource friendly.

I’m not going to argue that one, if anything I would tend to agree with you. (Hides behind wall as other users disagree!)

I didn’t even notice it indexing.
And I am not using a highend system here, it’s an 8 year old single core Athlon64 3000+ with an 11 year old 5400RPM hard disk. :wink:

Now that surely depends upon the quantity and type of material to be indexed. For starters, I have almost 1.2TB of 200MB+ PDF/ODT documents spread across 2 external drives … :\

I’ve enjoyed your various discussions interspersed with help and advice - for the moment I’m more than happy to agree to disagree on a few points.

In the meantime: we must all find software that meets our needs. Baloo not meeting mine has, ironically, been of immense help. I’ve mentioned it before and will mention it again. For ‘power indexing / searching’ I’ve yet to see anything better than ‘recoll’ http://www.lesbonscomptes.com/recoll/ - which from what I have discovered was written out of a ‘real need case’ rather than a ‘software project’. I find it hard to not go into ‘evangelism mode’. No, it doesn’t integrate with KDE. Yes, it can be complex. It does what I want, it does it well, but it’s certainly not for everyone and very far removed from Vishesh’s ideas - and that’s good - we need choice. As a search tool, I believe others could learn from it.

Will I ever come back to baloo and friends? Highly unlikely, but I’ll continue to take a look from time to time.