Hi All,
I finally got around to giving KDE 4.13 a spin after all the Baloo stuff died down but after going from 4.12 to 4.13.1 I’ve noticed that there is no meta data displayed in the dolphin information panel for any file type, e.g. MP3, JPG or video files etc. Is this how the information panel is now or am I missing something ? Any help appreciated.
Thanks
The Information Panel is now, unfortunately, reliant upon baloowidgets… >:( As, it seems, numerous parts of KDE are. Sigh!!
It requires libbaloowidgets, true. But it shouldn’t need the file indexer enabled.
Before that it was reliant on nepomukcore (and even part of that package) and nepomukwidgets. And before that it needed strigi.
So no change there.
It doesn’t work here though even with the file indexer enabled, so there seems to be a bug.
PS: It does work for indexed files. But for some reasons I don’t have any files indexed anymore (since upgrading to 4.13.1?).
Anyway, it is still a bug. The information should be shown for not-indexed files as well, just like it was with Nepomuk.
For the record:
https://bugs.kde.org/show_bug.cgi?id=334931 (filed by Dragon32, thank you for that!)
Thanks for the reply folks. Thought it might be a bug or developers omission. It’s back to 2009 again when Nepomuk first came out and meta data was removed for non indexed files :
http://forum.kde.org/viewtopic.php?f=15&t=62458
Sigh, getting tired of this whole Nepomuk/Baloo business and I’m seriously considering kicking KDE into touch for another desktop environment. Anyhow bug report filed at KDE:
I’m sorry to say that IMHO baloo has, how shall I say, ‘multiple issues’… Considering it is, I believe, little more than ‘nepomuk with a new name’ but now using xapian as the database; I’m surprised at just how buggy it is… Vishesh has probably put an enormous amount of effort into this, but I for one don’t like the direction in which he’s heading. His choice of ‘on by default’ has won him few friends either.
At least nepomuk could be disabled, baloo looks to me as if it’s becoming more deeply embedded within KDE and is beginning to become quite intrusive - probably best left for a new thread in ‘soapbox’… 
That’s correct AFAIK.
Vishesh has probably put an enormous amount of effort into this, but I for one don’t like the direction in which he’s heading. His choice of ‘on by default’ has won him few friends either.
Well, nepomuk was enabled by default as well already, even the file indexing.
It was an openSUSE specific change to disable the file indexing by default. I don’t know what other distributions did in this regard though.
At least nepomuk could be disabled, baloo looks to me as if it’s becoming more deeply embedded within KDE and is beginning to become quite intrusive - probably best left for a new thread in ‘soapbox’…
Again, this has not changed at all with baloo. It’s exactly the same as it was with nepomuk. The only difference is that nepomuk had separate “nepomukserver” and “virtuoso” processes that had to be running all the time. It was this that you have been able to turn off in addition to disabling the file indexer. But baloo doesn’t have this anyway.
Otherwise not much has changed except for the storage.
Baloo file indexing can be disabled, just like it was with Nepomuk, and it now (4.13.1) even has an on/off switch in its configuration module.
And there’s the advanced module as well as you know.
Sorry wolfi, I find it difficult to agree with you there 
Yes, baloo can be (mostly, barring a few bugs) disabled with regard to the content, or phase two, indexing. However meta-data is still extracted from files and stored in the database. With nepomuk one could disable that also, if that’s available with baloo then the option is well hidden and I’ve yet to discover it!
And there’s the advanced module as well as you know.
I’m aware of that but haven’t looked into it - is that not just a GUI for the settings that are in what is now ‘baloofilerc’, which looks from memory at least, much the same as the old nepomuk version.
From a personal point of view, I would much prefer to have full control (to the extent of removing all baloo components if I so chose), over an indexers behaviour; be that baloo or any other.
Basically it comes down to something which is fundamentally simple: If I don’t want indexing of file content, meta-data, e-mail, or indeed file names; then I should be able to disable that. At present, with baloo, that is not possible.
I genuinely hope developers are taking note of some of the criticism of baloo’s implementation, a lot of which I feel is justified. How many end-users for example know that data is also written to the extended attribute user namespace. At the moment I’m aware of baloo.rating, xdg.tags and xdg.comments - user beware! Your ‘comments’ may not be as private as you thought they were. 
Is it? That would be a bug I’d say.
But I haven’t tried to turn it off yet.
What metadata do you mean, actually? In phase 1 it only stores filesize and such AFAIK. But I guess it shouldn’t do that neither when disabled.
OTOH, since this thread is about the missing metadata: it didn’t store any metadata for non-indexed files in the database here (unless I called baloo_file_indexer manually). Not even for the files that should be indexed, when I wanted to display the metadata in dolphin. And it still hasn’t reindexed all my files.
Again, with Nepomuk one could disable the nepomukserver and virtuoso (the database) running, but those don’t exist anymore with baloo.
I have to admit though that I don’t know all the details about Nepomuk/baloo either.
I’m aware of that but haven’t looked into it - is that not just a GUI for the settings that are in what is now ‘baloofilerc’, which looks from memory at least, much the same as the old nepomuk version.
Yes. And it already respected those settings in 4.13.0. It even migrated my Nepomuk settings from nepomukfilerc automatically.
From a personal point of view, I would much prefer to have full control (to the extent of removing all baloo components if I so chose), over an indexers behaviour; be that baloo or any other.
You can disable the file indexer in baloo’s settings module.
You can disable the akonadi indexer in Akonadikonsole I think. At least you can disable mail indexing per mail folder in KMail (again, exactly as it was with Nepomuk).
And you can uninstall baloo-file or baloo-pim to completely disable the corresponding indexers. (this was not possible with Nepomuk)
Basically it comes down to something which is fundamentally simple: If I don’t want indexing of file content, meta-data, e-mail, or indeed file names; then I should be able to disable that. At present, with baloo, that is not possible.
See above.
As last resort you can just uninstall the indexers, at least on openSUSE.
I genuinely hope developers are taking note of some of the criticism of baloo’s implementation, a lot of which I feel is justified. How many end-users for example know that data is also written to the extended attribute user namespace. At the moment I’m aware of baloo.rating, xdg.tags and xdg.comments - user beware! Your ‘comments’ may not be as private as you thought they were.
Yes, baloo saves the tags and so on in extended attributes. This of course has advantages and disadvantages. And there was a long discussion going on about that on the KDE developer mailinglists before baloo was released, but it was agreed upon doing it that way in the end.
If you copy/move your files to a FAT partition or upload them somewhere those get lost anyway.
Well, I’m not trying to defend Baloo here. I never used Nepomuk (I had it enabled though, just disabled the file indexer), and I haven’t used baloo either yet. I do still have the indexer enabled, but for some reason it forgot all my indexed files after updating to 4.13.1 and doesn’t really seem to index them by itself anymore. (I have filed a bug report about this)
OTOH, I didn’t even notice baloo indexing everything after updating to 4.13.0. It didn’t really have any negative impact on my system. (I did exclude some folders during Nepomuk times already, although I had the file indexer disabled)
It’s just that I don’t really want to “waste” 1GiB hard disk space for a feature I’m not using anyway, so I guess I’m going to disable it again sooner or later.
But I guess I’m getting off-topic here now…
It appears — anything it can extract; depending upon file type.
And… ( bug https://bugs.kde.org/show_bug.cgi?id=332610 ) it likes drawing your attention to it.
As last resort you can just uninstall the indexers, at least on openSUSE.
rm -rf ~/.local/share/baloo/*
chmod 1000 ~/.local/share/baloo
and it’s not bothered me since…
If you copy/move your files to a FAT partition or upload them somewhere those get lost anyway.
Just don’t give an ext4 formatted memory card / usb stick to your mate… :X As I said, user beware.
But I guess I’m getting off-topic here now…
Think we both are… Hopefully baloo will ‘mature’. One thing I do know though, I won’t be going back to it.
Make the most of what’s left of the weekend.
Yes, it still shows indexed data. And the indexed data doesn’t get removed automatically when you disable it.
But it shouldn’t index anything new. But as I said, I haven’t tested it yet.
And yes, I noticed the duplication (triplication, whatever) of metadata as well in 4.13.0. At the moment (on 4.13.1) this is not the case, but most of my files are not even indexed yet as mentioned.
rm -rf ~/.local/share/baloo/*
chmod 1000 ~/.local/share/baloo
and it’s not bothered me since…
Of course.
Still it would be a bug (that must be fixed) if it would index although it’s disabled, I’d say.
And uninstalling baloo-file should disable this as well, as this package contains baloo_file_extractor.
Just don’t give an ext4 formatted memory card / usb stick to your mate… :X As I said, user beware.
Or disable extended file attributes in the filesystem’s settings.
Most (all?) USB sticks are FAT-formatted anyway.
Trouble with that is Dolphin then displays no file information at all in the Information Panel.
Or disable extended file attributes in the filesystem’s settings.
Yes, one could, but it would (should?) be better to be able to control baloo’s behaviour.
Most (all?) USB sticks are FAT-formatted anyway.
Indeed, that is true. This raises something quite interesting though. Linux has, I believe by it’s very nature, a more diverse range of users whose method of working is probably less typical of the ‘average user’.
For example, I have four USB sticks lying on my desk at the moment, none of which are formatted FAT. I need to retain ownership/permissions without resorting to archiving, these provide a convenient method of exchanging data with colleagues.
Using baloo as an example of how a group of developers believe an application should behave. I will stress here this is not a personal criticism aimed towards them, just an illustration of how difficult it is to cater for the mythical ‘average user’.
‘As is’ baloo makes a lot of assumptions about what I ‘want’; with very little control over it’s behaviour. It shouldn’t be necessary to jump through hoops backwards to disable part, or all. If, and this is the crux of the issue; if baloo did what I wanted, then I would choose to use it. It doesn’t, and I’m finding it hard to disable in it’s entirety. I also know that I’m far from alone in this - google ‘baloo + kde’ and most hits on the first page are along the lines of ‘how do I disable / remove’ …
Bottom line in my own case is: Yes I need full text indexing with comprehensive control and the ability to conduct complex search queries - provided by ‘recoll’. No I don’t need indexing of tags, ratings, comments etc…
Sorry, verging on ‘rant mode’. However I don’t like the way in which baloo (or indeed any component) is becoming deeply embedded within KDE, to the extent that it potentially becomes impossible to remove/disable without breaking something. (Reminds me slightly of how IE was embedded within windows…)
With apologies to the OP - Probably hi-jacked this thread enough.
No, that’s completely unrelated to baloo-file. The information widget and the metadata extractors are in kfilemetadata.
But at the moment it does not display any file information at all for files that are not indexed. Even when you have baloo-file installed and enabled.
And that’s exactly what this thread and the bug report is about.
Yes, one could, but it would (should?) be better to be able to control baloo’s behaviour.
Yes, and this is actually possible.
Again, if it doesn’t work/the settings are not respected, it is a bug and should be reported.
I cannot confirm this yet, though, as I haven’t tried to disable it yet.
For example, I have four USB sticks lying on my desk at the moment, none of which are formatted FAT. I need to retain ownership/permissions without resorting to archiving, these provide a convenient method of exchanging data with colleagues.
Using baloo as an example of how a group of developers believe an application should behave. I will stress here this is not a personal criticism aimed towards them, just an illustration of how difficult it is to cater for the mythical ‘average user’.
[QUOTE]‘As is’ baloo makes a lot of assumptions about what I ‘want’; with very little control over it’s behaviour. It shouldn’t be necessary to jump through hoops backwards to disable part, or all. If, and this is the crux of the issue; if baloo did what I wanted, then I would choose to use it. It doesn’t, and I’m finding it hard to disable in it’s entirety. I also know that I’m far from alone in this - google ‘baloo + kde’ and most hits on the first page are along the lines of ‘how do I disable / remove’ …
Every application makes a lot of assumptions what one ‘wants’. That’s not necessarily a bad thing, but necessary.
I do agree though that it was a (very) bad idea to strip down the baloo configuration module to a folder blacklist only, as it was done.
But, the module at least got that enable/disable switch now, and there’s also the advanced module available that has (nearly) all functionality of the old Nepomuk configuration module.
Bottom line in my own case is: Yes I need full text indexing with comprehensive control and the ability to conduct complex search queries - provided by ‘recoll’. No I don’t need indexing of tags, ratings, comments etc…
Well, then use recoll, and don’t use baloo’s tags, ratings, comments, etc.
Sorry, verging on ‘rant mode’. However I don’t like the way in which baloo (or indeed any component) is becoming deeply embedded within KDE, to the extent that it potentially becomes impossible to remove/disable without breaking something. (Reminds me slightly of how IE was embedded within windows…)
Again, baloo is not in any way deeper embedded within KDE than Nepomuk has been. You even can uninstall the indexer parts which was not possible with Nepomuk.
The issue this thread is about (no metadata shown for not-indexed files) is a bug that I hope will be fixed soon. (and this same bug already was there in the beginning of Nepomuk)
I just want to state another thing about the use of extended attributes: Personally if I add comments/tags/ratings/whatever to a file, I would expect them to stick to the file. That’s the whole point of it, no? If I move the file to a different place they should not disappear.
Having them stored in the database is just a kludge that shouldn’t be needed (other than for searching of course).
So I rather regret that they are still lost when you move them to specific file systems.
With apologies to the OP - Probably hi-jacked this thread enough.
not really, I think you have some quite valid points. I’m just getting very tired of Nepomuk (Baloo is just V2) and it’s continued instability. It appears to me that it’s introduction was somewhat rushed and more thorough testing should have been done, probably leaving Nepomuk in place and introducing Baloo in KDE 5 IMHO would have been a better move.
Well, actually it is V3.
Nepomuk V1 is still part of kdelibs4 (at least parts of it; it cannot be completely removed/replaced because of the feature freeze since 4.8, and for compatibility reasons).
Nepomuk V2 was added with 4.10 IIRC, in the extra packages nepomuk-core and friends.
Well, actually it is V3.
Thanks for the correction. Wow three stabs at it and thing is still as unstable as a Saturday night drunk
In which case I apologise and was obviously mistaken. It was my belief that baloowidgets was now providing that functionality.
Regarding your other, all very valid points; this emphasises the point I was making, we all have diverse uses. Personally I too would want meta data related to the actual file I had (knowingly) attached it to, and yes, I would expect it to remain if the file was moved, but not so on copy.
One other thing with baloo at the moment is simply, what is stored where, by what, when, and for what purpose? Questions which should be addressed to the developers of course. At the moment, as far as I had established there is the xapian database, an sqlite database, and the extended file attributes…
There will be a lot of people who chose to use baloo, of that I’m certain, I for one, won’t be amongst them. As for deep integration with KDE, we’ll have to wait and see what happens. With nepomuk one could easily and reliably disable the ‘semantic desktop’, file indexing, and mail indexing. I’m sorry, but I don’t see this with baloo.
Well, yes, the widget itself is actually provided by libbaloowidgets4 I suppose, sorry. This in turn uses kfilemetadata to get the metadata.
But that doesn’t change the fact that it is unrelated to baloo-file, the indexer.
You cannot uninstall kfilemetadata and libbaloowidgets4 anyway, as they are required by dolphin.
But again (a last time ), this was exactly the same with Nepomuk. NepomukV1 has that widget in libkde4 and used strigi for indexing and metadata extraction. NepomukV2 (which Dolphin uses in 4.10?, 4.11 and 4.12) had it in nepomuk-widgets and the metadata extractors, i.e. what is now kfilemetadata4, has been in nepomuk-core.
So why is it suddenly much worse with baloo?
In fact the packaging is much more fine-grained now, so it is actually possible to uninstall the indexers without losing any other functionality.
Regarding your other, all very valid points; this emphasises the point I was making, we all have diverse uses. Personally I too would want meta data related to the actual file I had (knowingly) attached it to, and yes, I would expect it to remain if the file was moved, but not so on copy.
Is it retained on copy as well? I don’t think so.
I just added a comment to a file, copied it with dolphin, and the copy DID NOT have any comment.
Anyway, that would be no different to ID3 tags f.e. then. Do you complain that when you copy an MP3 file, the copy contains the tags you added, too?
Btw, beagle did store everything in extended attributes already, and I think tracker does as well, but I’m not sure.
One other thing with baloo at the moment is simply, what is stored where, by what, when, and for what purpose? Questions which should be addressed to the developers of course. At the moment, as far as I had established there is the xapian database, an sqlite database, and the extended file attributes…
As I said, I don’t know all the details, but AFAIK there is only one database, the one in ~/.local/share/baloo/. (well, actually separate ones for files, emails, contacts, notes, …)
This is a xapian database. This is the search index, which has to be central of course, otherwise the whole purpose of an indexer is void.
I see one sqlite file in there as well, ~/.local/share/baloo/file/fileMap.sqlite3, there may be good reasons why this is there. By looking into this, it only seems to be used to connect the internal numeric id with the actual URL of the file.
Whereas Nepomuk used soprano for that, and either redland, sesame, or virtuoso as backend.
There will be a lot of people who chose to use baloo, of that I’m certain, I for one, won’t be amongst them. As for deep integration with KDE, we’ll have to wait and see what happens. With nepomuk one could easily and reliably disable the ‘semantic desktop’, file indexing, and mail indexing. I’m sorry, but I don’t see this with baloo.
What is it that you don’t see?
Again, it can be disabled exactly the same, even in (nearly) the same config files. The option to disable baloo-file was missing in the GUI in 4.13.0, but is there now.
If disabling it doesn’t have effect that’s another story, I don’t know whether that’s the case.
There is no option in the configuration module any more to disable mail (PIM) indexing, true. But AFAIK that should be doable by just removing the “Akonadi Baloo Indexing Agent” in Akonadi’s settings. TBH, I never disabled the Nepomuk PIM indexing anyway. I rather disabled indexing for all my mail folders, as I said this can be configured on a per-folder basis in KMail.
And there is no server process any more, so there is no need to disable the server process.
The only difference is, that baloo’s libraries can access the database directly now, without the need of a separate server process. But I would rather regard that as advantage.
Three check boxes and nepomuk was completely disabled.
There appears to be a fundamental difference between what should(?) and does happen. At this point in time, functionality is lost if ‘baloo-file’ is removed. Be that a bug or not, at the practical level is immaterial.
I appreciate the points you make. If the sole use of my PC was to keep a few photos, music files, etc etc I wouldn’t care whether baloo indexed anything, wrote anything, or created as many database files as it felt necessary to do. That is not the case though (it’s that usage scenario again) - this is a ‘working machine’ which contains confidential (work related) material. I don’t want some incorrigible indexer trawling through the content unless I can be absolutely confident that I have full control over that process. As released that control was sadly lacking. I feel that you know as well as I that a look through https://bugs.kde.org/buglist.cgi?list_id=1048289&product=Baloo does not inspire a great deal of confidence at this point in time.
As I said, there is difference between what should and does happen. Bugs need to be found and fixed, that needs the cooperation of users, but in this case I believe there were too many at release. Coupled with some of the responses to concerns about the lack of control being along the lines of:
“The current way to disable email indexing is to add your $HOME to the list of folders which should not appear in Desktop Search. I wanted to push people to make Desktop Search enabled by default. Hence there isn’t a clear disable option any more. Could you please open detailed bug reports about why your system is un-usable. Lets fix all them. Closing this as WONTFIX.” ( https://bugs.kde.org/show_bug.cgi?id=331932#c1 )
Which, IMHO, clearly indicates an attitude which does not bode well for the future.
I hope baloo matures into a good piece of software, but when confidence in any product is lost, it is seldom regained. For myself, I have found a better alternative. It’s unfortunate that arguments about the merits or otherwise of baloo will probably drag on, just as with it’s predecessors.
I respect your comments on this but perhaps it is better if we draw to a close.
Well, I already went into this in detail.
At this point in time, functionality is lost if ‘baloo-file’ is removed. Be that a bug or not, at the practical level is immaterial.
Which functionality do you mean again?
The metadata display in the information panel for not-indexed files?
As I said, that functionality is lost even with baloo-file installed.
Another time: this is independent of baloo-file. No functionality is lost if you uninstall baloo-file, except for the indexing itself, which is of course the whole point of uninstalling it.
As I said, there is difference between what should and does happen. Bugs need to be found and fixed, that needs the cooperation of users, but in this case I believe there were too many at release. Coupled with some of the responses to concerns about the lack of control being along the lines of:
“The current way to disable email indexing is to add your $HOME to the list of folders which should not appear in Desktop Search. I wanted to push people to make Desktop Search enabled by default. Hence there isn’t a clear disable option any more. Could you please open detailed bug reports about why your system is un-usable. Lets fix all them. Closing this as WONTFIX.” ( https://bugs.kde.org/show_bug.cgi?id=331932#c1 )
Which, IMHO, clearly indicates an attitude which does not bode well for the future.
Yes, but this decision has been revised obviously.
The main baloo developer even helped with the development of the advanced settings module, and offered to review it.
I respect your comments on this but perhaps it is better if we draw to a close.
I actually agree.
Still, I just had to reply another time…