Wolfie, I wouldn’t deny you that 
Quick question just to clarify (I could possibly be suffering from a ‘senior moment’).
Does Dolphin natively populate the Information Panel with ‘basic’ (mimetype, size, modified, owner, permissions) file data?
Yes this works, also for not-indexed folders/files (I just tried / and /boot).
Of course you have to enable this data, by default only size and mimetype is shown. But that’s unrelated to baloo of course.
But after uninstalling baloo-file this only works for already indexed files… :sarcastic:
Didn’t notice this before.
Only if you select more than one file it shows the total size correctly.
I suppose that’s gonna be another bug report, although it could be related to that existing one.
I have yet to see any usable indexer. Lets face it those that are producing these things want all to find the joy of complete and total indexing. Sorry not all files need or should be indexed. For most toaster users(ie non tech types) indexing the document folder would be sufficient since that is whee all their work is. This should be the default ir doc’s only. Ok So you want to index your email. So you could add the email folder(s) as an option. IMO There is no need to try and index any binary based file. But I guess adding meta data from some forms of binary make sense but there are many that don’t so why waste the CPU cycles???
So the default should be simple and directed at the obvious areas but never just the home directory entirely. If someone want that let them turn it on do not turn it on by default
Indexing should not be linked to normal metadata reading, ever!!!
The first thing I do at a Windows install is turn off the indexing. I should be able to turn off the indexing in KDE also
But you can.
In 4.13.1 (released 2 weeks ago) the standard Baloo configuration module (in “Configure Desktop”/“Systemsettings”) has an on/off switch that enables/disables file indexing.
And you can exclude folders from indexing.
And there’s the advanced configuration module (similar to the old Nepomuk configuration module) where you can select exactly which folders are to be indexed, and which filetypes (you can exclude specific mimetypes and specific filename patterns).
Indexing should not be linked to normal metadata reading, ever!!!
I agree. But again, that’s a bug that has to be fixed.
Thanks for that … think I’m starting to lose the plot now :X I’ll go take a walk in the woods…
I just want to add what the problem actually is: ( I examined this a bit more)
The information panel uses “ballo_file_extractor” to get the metadata for not-indexed files. This program is in the package baloo-file.
“baloo_file_extractor” (or baloo-file) is actually not needed to get the basic information like size and permissions, but the widget hangs and doesn’t show anything if “ballo_file_extractor” cannot be started.
If I create a dummy “ballo_file_extractor” script in /usr/bin/, showing the filesize, permission, and so on does work fine even with baloo-file uninstalled.
The bug in this case is, that the widget starts “ballo_file_extractor” (to get the metadata) without any error checking and waits for an answer (which never comes if it cannot be started) without any timeout.
At least this should be easily fixable. I guess I could create a patch in 5 minutes…
PS: It’s called “baloo_file_extractor” of course, not “ballo…”, sorry.
I filed a bug report:
https://bugs.kde.org/show_bug.cgi?id=335087
I’m going to even propose a bug fix myself for that in a few days, if there’s no reaction before.
I propose a name change for Baloo:
Bugaloo
:good: Well done that man!!
Hmm… which could be accused of creating (allegedly) rather a Hullabaloo >:) …
I also found out why no metadata is shown for not-indexed files, i.e. the original problem of this thread.
As mentioned, the widget just runs “baloo_file_extractor” to get the metadata.
But “baloo_file_extractor” does not fetch any metadata from files that should not be indexed, i.e. in folders that are excluded. It just exits with the following debug message:
baloo_file_extractor(14300) Baloo::App::App: "/boot/boot.readme" does not exist or should not be indexed
Of course, the widget then still doesn’t have any metadata to display…rotfl!
I added that information to the bug report.
PS: The aforementioned problem is already fixed on my system… 
Excellent detective work Wolfi 
Most grateful - appreciate your work on this
… and … as you’re on a roll with it lol!
Bug filed against KIO a while back. https://bugs.kde.org/show_bug.cgi?id=334235 Same underlying cause perhaps? (It’s been CC’d to ‘me at vhanda.in’)
I don’t think so. I still can reproduce that problem here, although the metadata for not-indexed files works now:
http://wstaw.org/m/2014/05/20/dolphin.png
Maybe that rename dialog just hasn’t been ported to baloo and is missing some libraries now or something? Might be a problem though, as kdelibs is in feature freeze.
I think that’s the reason why there’s no metadata in the “File Properties” dialog anymore. Because of the feature freeze they couldn’t port it to NepomukV2 and therefore it doesn’t work any more (I might remember wrong though).
The feature freeze is of course the reason that NepomukV2 and now Baloo are not in kdelibs, but in nepomuk-core and friends resp. baloo-core and other packages, as already mentioned. KIO is in kdelibs though.
I’ll have to take a look on it, but actually I don’t even know atm where to find that rename dialog in the source repo. A quick look at KIO’s kfilemetadata class revealed that this is indeed still using strigi (also used by NepomukV1 as metadata extractor). I have no idea why it wouldn’t work though if you have strigi installed (like I do).
Maybe it’s even an openSUSE-specific issue though. AFAIK they disabled the building of Nepomuk now wherever possible, to not carry unneeded/unused cruft in the packages (and 3 indexers ).
This sounds plausible, as kdelibs is compiled with those options in KDE:Current:
-DKIO_NO_STRIGI=ON \ -DKIO_NO_SOPRANO=ON \ -DKIO_NO_NEPOMUK=ON \
I will build a package tomorrow with those enabled and check.
OK, it was just a thought…
although the metadata for not-indexed files works now:
Looks good.
Maybe that rename dialog just hasn’t been ported to baloo and is missing some libraries now or something? Might be a problem though, as kdelibs is in feature freeze.
I think that’s the reason why there’s no metadata in the “File Properties” dialog anymore. Because of the feature freeze they couldn’t port it to NepomukV2 and therefore it doesn’t work any more (I might remember wrong though).
You recall correctly, metadata was removed from file properties October 2013…
http://commits.kde.org/kdelibs/fa58b5a00540b4697bc11cacf66fedb1ba6d22ce
I’ll have to take a look on it, but actually I don’t even know atm where to find that rename dialog in the source repo. A quick look at KIO’s kfilemetadata class revealed that this is indeed still using strigi (also used by NepomukV1 as metadata extractor). I have no idea why it wouldn’t work though if you have strigi installed (like I do).
Interesting, I don’t have strigi installed, don’t recall removing it and there’s no mention in /var/log/zypp/history, but that only goes back to Dec 2013. – Just installed strigi/libstrigi0, no difference. The rename dialogue was working pre 4.13 so something has obviously changed … your ‘not ported to baloo’ I guess could well be right.
Maybe it’s even an openSUSE-specific issue though. … I will build a package tomorrow with those enabled and check.
Thanks for the work you’re putting in on this - I’m sure I’m not the only person to appreciate it!
Ah yes. Thanks for the pointer!
I wasn’t sure whether they removed it upstream, or it’s just not there in openSUSE’s packages because of some missing dependency or compile switch.
Interesting, I don’t have strigi installed, don’t recall removing it and there’s no mention in /var/log/zypp/history, but that only goes back to Dec 2013. – Just installed strigi/libstrigi0, no difference.
I’m not sure whether strigi was installed by default in 13.1, because the Nepomuk (V2) in KDE 4.11 already didn’t use it any more, and had its own metadata extractors.
Installing strigi on 4.13 has no effect whatsoever of course, since the 4.13 openSUSE kdelibs packages are built without any support for Nepomuk and strigi as mentioned (there’s even a patch included to make them compilable/work without strigi)
The rename dialogue was working pre 4.13 so something has obviously changed … your ‘not ported to baloo’ I guess could well be right.
Yes, and it was in 4.13 Beta1 when openSUSE’s maintainers removed the strigi support. So this would be another indication that that is the reason.
But unfortunately adding back Nepomuk/Soprano/Strigi support (i.e. removing those compile switches and the no-strigi patch) didn’t change anything.
And if it worked for you on 4.11/4.12 without strigi installed, it can’t be because of the missing strigi support anyway.
Hm, I have to investigate deeper. May take a few days though.
Anyhow, I don’t see any upstream commit that explicitely removed that feature.
To add, this works fine in Kubuntu 14.04 (KDE 4.13.0):
http://wstaw.org/m/2014/05/21/dolphin1.png
So there’s definitely something missing in the openSUSE packages.
Well, I’ll find out…
I have to take that back.
It does work now on my openSUSE system as well:
http://wstaw.org/m/2014/05/21/dolphin2.png
By mistake I still had an older kdelibs4 package installed. The new one wasn’t published on OBS yet when I updated, apparently.
After getting an update notification and installing the update, it works now.
So I only have to find out now, which one of the 3 is really needed. (I doubt that it’s soprano… )
I can’t be 100% certain strigi wasn’t (at some point) installed. 2013-12-26 is the furthest I’m able to go back in /var/log/zypp/history, a grep for strigi returns nothing.
Nepomuk/Soprano were definitely installed.
Currently have kdelibs4/kdelibs4-core at V 4.13.1-12 (openSUSE KDE Current).