Since version 4.13 tooltips (with meta information/preview) don't work anymore on all other directories except my home directory. The mouse-pointer toggles on hover to the "waiting"-state but nothing happens. I often used this tooltip to display image-meta data like date. Reproducible: Always
Thanks for the bug report, but I cannot reproduce the problem. Does "nothing happens" mean that no tool tip is shown? If not, please provide a screenshot of the non-working tool tip.
Created attachment 86882 [details] screenshot showing the waiting mouse pointer No tooltip is shown, only the mouse pointer symbol changes to a "waiting" state, which stays as long I hover the file. Perhaps important: I don't have installed the "balloo" package (this desktop search thing)
Been there, seen that ... https://bugs.kde.org/show_bug.cgi?id=335087 https://bugs.kde.org/show_bug.cgi?id=332065
(In reply to comment #3) > Been there, seen that ... OK... sorry, this is the tool-tip not the information panel... but I'd be happy to wager... underlying cause much the same.
uh, if this should be balloo related: if I have to install balloo to show exif-meta-data, please please make it possible to do that without needing to have desktop-search/file-indexing activated!
Thanks for the update and for your comment, Paul! I've had a look at the tool tip code - the tool tip is shown only after the "metaDataRequestFinished" signal is received from the meta data widget. So it seems that the widget does not emit the signal for some reason. This has to be fixed in the widget - we cannot do anything about that in Dolphin, I'm afraid. > Perhaps important: I don't have installed the "balloo" package (this desktop > search thing) Does that mean that you do not have anything related to Baloo installed? In that case, Dolphin will just use the old, unmaintained KFileMetaDataWidget from kdelibs, just like in 4.12 if Nepomuk was not installed. But I don't think that this is the case, because KFileMetaDataWidget does not behave different if the URL in question is not in the home directory. Maybe you have the Baloo Widgets library installed, but not some other part of Baloo? (In reply to comment #3) > https://bugs.kde.org/show_bug.cgi?id=335087 Thanks - the present bug report is most likely a duplicate of that one (at least if Baloo Widgets are installed on H.H's system). (In reply to comment #5) > uh, if this should be balloo related: if I have to install balloo to show > exif-meta-data, please please make it possible to do that without needing to > have desktop-search/file-indexing activated! That would be the other bug that Paul has quoted: > https://bugs.kde.org/show_bug.cgi?id=332065
@ Frank Reininghaus Just for information. There is a very long thread over on the openSUSE forum relating to meta-data displayed by Dolphin, 'wolfi323' did a lot of work tracking down the cause(s) and has a patched 'baloo-file' which may be of help to the OP. Perhaps take a look starting around post #33 https://forums.opensuse.org/showthread.php/498098-KDE-4-13-1-Dolphin-Information-Panel-No-Meta-Data?p=2644451#post2644451 and closer to the end at around post #69 https://forums.opensuse.org/showthread.php/498098-KDE-4-13-1-Dolphin-Information-Panel-No-Meta-Data?p=2645521#post2645521
Thanks for the info, Paul, but as I said, we cannot do anything about this in Dolphin. Please make sure that the Baloo people are aware of that information, if that isn't the case already. (In reply to comment #6) > > Perhaps important: I don't have installed the "balloo" package (this desktop > > search thing) > > Does that mean that you do not have anything related to Baloo installed? In > that case, Dolphin will just use the old, unmaintained KFileMetaDataWidget > from kdelibs, just like in 4.12 if Nepomuk was not installed. But I don't > think that this is the case, because KFileMetaDataWidget does not behave > different if the URL in question is not in the home directory. > > Maybe you have the Baloo Widgets library installed, but not some other part > of Baloo? There was no response to my questions, so I assume that it is indeed a duplicate of bug 335087. *** This bug has been marked as a duplicate of bug 335087 ***
>Does that mean that you do not have anything related to Baloo installed? In that case, Dolphin >will just use the old, unmaintained KFileMetaDataWidget from kdelibs, just like in 4.12 if Nepomuk >was not installed. But I don't think that this is the case, because KFileMetaDataWidget does not >behave different if the URL in question is not in the home directory. I recognized, that I had a baloo package installed ( I think something like "libbaloo"). >Maybe you have the Baloo Widgets library installed, but not some other part of Baloo? I don't think the package name was "baloo-widgets" However, after I installed the other baloo-packages, things work, I'll try to remove all baloo related packages also when I have the time.
(In reply to comment #8) > Thanks for the info, Paul, but as I said, we cannot do anything about this > in Dolphin. Please make sure that the Baloo people are aware of that > information, if that isn't the case already. > Yes, I believe they are aware; but for them moment it is not on their agenda. I appreciate that Dolphin is not responsible for the meta-data extraction... If, however, you take a look at the very last (short) post I made over on the openSUSE forum: https://forums.opensuse.org/showthread.php/498098-KDE-4-13-1-Dolphin-Information-Panel-No-Meta-Data?p=2645696#post2645696 There could be a case for Dolphin itself extracting (limited) meta-data for a 'non baloo' situation. Something basic such as meta-data 'pairs', for example: PDF,ODT Author/Title; PNG, JPEG Width/Height; MP3, FLAC Track/Artist ... would be, IMHO very useful to have in addition to the basic file system information.
(In reply to comment #9) > >Maybe you have the Baloo Widgets library installed, but not some other part of Baloo? > > I don't think the package name was "baloo-widgets" Could be, the name of the distro package is not necessarity the name of the git repository. > However, after I installed the other baloo-packages, things work I'm glad that it works now. Thanks for letting us know. (In reply to comment #10) > There could be a case for Dolphin itself extracting (limited) meta-data for > a 'non baloo' situation. > Something basic such as meta-data 'pairs', for > example: PDF,ODT Author/Title; PNG, JPEG Width/Height; MP3, FLAC > Track/Artist ... would be, IMHO very useful to have in addition to the basic > file system information. I see that having meta data shown in the Information Panel even for files which are not indexed by Baloo is very useful. However, the right solution is to make sure that this works correctly inside Baloo's meta data widget (this widget is always used inside the Panel if Dolphin is built on a system where the Baloo widgets library is installed, no matter if indexing is enabled or not). The widget should always just make the file indexer load the meta data on demand as soon as a non-indexed file is selected. See bug 332065. It seems that you are suggesting that we implement a second file indexing solution for KDE inside Dolphin instead. Maybe this isn't obvious, but such a thing would require a *major* effort, and Dolphin developer time isn't exactly an abundant resource. Wasting this time on working around problems in Baloo by implementing a new Baloo replacement (which will have quite a few bugs of its own, and which will require ongoing maintenance) is not really a clever idea from my point of view (asssuming it would be possible at all with the resources that we have, which I seriously doubt).
(In reply to comment #11) > It seems that you are suggesting that we implement a second file indexing > solution for KDE inside Dolphin instead. Even if you replace "file indexing" by "meta data extraction", it doesn't make a difference. It's a major effort in any case.
(In reply to comment #11) > ... However, the right solution > is to make sure that this works correctly inside Baloo's meta data widget > (this widget is always used inside the Panel if Dolphin is built on a system > where the Baloo widgets library is installed, no matter if indexing is > enabled or not). The widget should always just make the file indexer load > the meta data on demand as soon as a non-indexed file is selected. See bug > 332065. > Until such time as the (Baloo) widget is able to extract meta-data only from a file, as opposed to indexing content at the same time, (which I'm sure it must be doing with PDF files, 8 seconds for an approx 12Mb file?), then I don't see it as being a practical solution. The basic assumption behind Baloo seems to have been that it will _always_ have a database to use... the thought that anyone would wish to disable that part of Baloo didn't enter the equation; but that's another story of course, and nothing to do with Dolphin. > It seems that you are suggesting that we implement a second file indexing > solution for KDE inside Dolphin instead. Maybe this isn't obvious, but such > a thing would require a *major* effort, and Dolphin developer time isn't > exactly an abundant resource. Wasting this time on working around problems > in Baloo by implementing a new Baloo replacement (which will have quite a > few bugs of its own, and which will require ongoing maintenance) is not > really a clever idea from my point of view (asssuming it would be possible > at all with the resources that we have, which I seriously doubt). You must direct your resources where they will be of most benefit to all... That I fully appreciate.
(In reply to comment #13) > (In reply to comment #11) > > ... However, the right solution > > is to make sure that this works correctly inside Baloo's meta data widget > > (this widget is always used inside the Panel if Dolphin is built on a system > > where the Baloo widgets library is installed, no matter if indexing is > > enabled or not). The widget should always just make the file indexer load > > the meta data on demand as soon as a non-indexed file is selected. See bug > > 332065. > > > Until such time as the (Baloo) widget is able to extract meta-data only from > a file, as opposed to indexing content at the same time, (which I'm sure it > must be doing with PDF files, 8 seconds for an approx 12Mb file?), then I > don't see it as being a practical solution. Then please file a bug report for Baloo, component "Widgets", and say that no indexing should be done when retrieving meta data for the meta data widget. I think that everyone agrees that meta data should be retrieved as fast as possible in that case. Again: if there is a problem in a library, then the best (and the only real) solution is to fix that problem, and not to write a replacement for that library from scratch. > You must direct your resources where they will be of most benefit to all... > That I fully appreciate. Thanks!
(In reply to comment #14) > Again: if there is a problem in a library, then the best (and the only real) > solution is to fix that problem, and not to write a replacement for that > library from scratch. Indeed. Re-invented wheels will no doubt have re-invented bugs... Bug report filed against Baloo/Widgets: https://bugs.kde.org/show_bug.cgi?id=336084 Despite my apparent bemoaning attitude, I would like to assure both yourself and all other contributors to Dolphin, the work you do is very much appreciated.
Thanks!
Last time I reported, that the tooltip worked after installing all baloo packages. One annoying thing was, that I had to disable the file indexing later (because I don't need such things, and my harddisk was filled and hard-working). Btw: where are the file for file-indexing are stored? I'd like to delete them. But now the real problem: I recognized, that only the thumbnail for images is displayed now, other meta-data like width and height like before are missing! Why? Please don't tell me I have to enable file-indexing for that.. it was so comfortable to simply hover a file instead of opening gwenview..
(In reply to comment #17) > Btw: where are the file for file-indexing are stored? I'd > like to delete them They're located at: ~/.local/share/baloo/ However, don't delete ~/.local/share/baloo/file/fileMap.sqlite3 as baloo needs R/W access to this file even if indexing is disabled. > Please don't tell me I have to enable file-indexing for that.. > it was so comfortable to simply hover a file instead of opening gwenview.. Recently fixed, but I've not yet had time to test it. https://bugs.kde.org/show_bug.cgi?id=332065#c12
great, thanks!