Page 2 of 11 FirstFirst 1234 ... LastLast
Results 11 to 20 of 104

Thread: KDE 4.13.1 Dolphin Information Panel, No Meta Data

  1. #11

    Default Re: KDE 4.13.1 Dolphin Information Panel, No Meta Data

    Quote Originally Posted by tannington View Post
    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.
    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... As I said, user beware.
    Or disable extended file attributes in the filesystem's settings.
    Most (all?) USB sticks are FAT-formatted anyway.
    Last edited by wolfi323; 18-May-2014 at 11:51.

  2. #12
    Join Date
    Sep 2013
    Location
    Norfolk, UK
    Posts
    1,335

    Default Re: KDE 4.13.1 Dolphin Information Panel, No Meta Data

    Quote Originally Posted by wolfi323 View Post
    And uninstalling baloo-file should disable this as well, as this package contains baloo_file_extractor.
    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.
    Regards, Paul

    2x Tumbleweed (Snapshot: 20191211) KDE Plasma 5
    2x Leap 15.1 KDE Plasma 5

  3. #13

    Default Re: KDE 4.13.1 Dolphin Information Panel, No Meta Data

    Quote Originally Posted by tannington View Post
    Trouble with that is Dolphin then displays no file information at all in the Information Panel.
    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.

    [QUOTE]
    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' ...
    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.
    Last edited by wolfi323; 19-May-2014 at 02:19.

  4. #14
    Join Date
    Jul 2008
    Location
    Planet Earth
    Posts
    195

    Default Re: KDE 4.13.1 Dolphin Information Panel, No Meta Data

    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.

  5. #15

    Default Re: KDE 4.13.1 Dolphin Information Panel, No Meta Data

    Quote Originally Posted by Dragon32 View Post
    I'm just getting very tired of Nepomuk (Baloo is just V2)
    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.
    Last edited by wolfi323; 19-May-2014 at 02:43.

  6. #16
    Join Date
    Jul 2008
    Location
    Planet Earth
    Posts
    195

    Default Re: KDE 4.13.1 Dolphin Information Panel, No Meta Data

    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

  7. #17
    Join Date
    Sep 2013
    Location
    Norfolk, UK
    Posts
    1,335

    Default Re: KDE 4.13.1 Dolphin Information Panel, No Meta Data

    Quote Originally Posted by wolfi323 View Post
    No, that's completely unrelated to baloo-file. The information widget and the metadata extractors are in kfilemetadata.
    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.
    Regards, Paul

    2x Tumbleweed (Snapshot: 20191211) KDE Plasma 5
    2x Leap 15.1 KDE Plasma 5

  8. #18

    Default Re: KDE 4.13.1 Dolphin Information Panel, No Meta Data

    Quote Originally Posted by tannington View Post
    In which case I apologise and was obviously mistaken. It was my belief that baloowidgets was now providing that functionality.
    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.
    Last edited by wolfi323; 19-May-2014 at 04:22.

  9. #19
    Join Date
    Sep 2013
    Location
    Norfolk, UK
    Posts
    1,335

    Default Re: KDE 4.13.1 Dolphin Information Panel, No Meta Data

    Quote Originally Posted by wolfi323 View Post
    So why is it suddenly much worse with baloo?
    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?lis...&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.
    Regards, Paul

    2x Tumbleweed (Snapshot: 20191211) KDE Plasma 5
    2x Leap 15.1 KDE Plasma 5

  10. #20

    Default Re: KDE 4.13.1 Dolphin Information Panel, No Meta Data

    Quote Originally Posted by tannington View Post
    Three check boxes and nepomuk was completely disabled.
    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...

Page 2 of 11 FirstFirst 1234 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •