Version: 0.10.0 (using KDE 4.2.4) OS: Linux Installed from: Ubuntu Packages When I am in the album view looking at thumbnails, a tooltip appears if I hover over an image for a second or so. The tooltip fades in quite quickly rather than appearing instantly. If, while the tooltip is fading in, I click on an image to preview it, the tooltip disappears, the preview image is shown and the tooltip reappears again in the same position. Until I pass the mouse over the tooltip, it will not go away. This keeps happing to me (every minute or two) and is quite distracting. It took me a while to figure out how to reproduce it and it is quite hard to get the timing just right when trying to do it deliberately, but it does seem to be caused by switching views just as the tooltip is fading in. The tooltip even stays open when I open the Settings dialog box (and obscures my view). In that case, I have to close the dialog box and pass the mouse over the tooltip to get rid of it, as it will not go away while the dialog is open. I guess that the tooltip does not register any mouse movements while the modal dialog is open. Is there a problem in the code that dismisses the tooltips if their display is interrupted while they are fading in?
Just noticed that the tooltips sometimes stay open and on top of other windows when I just Alt-Tab between them, but I cannot make it happen reliably.
I have noticed this behavior as well, sometimes, not reproducable. For 1.0beta/current trunk the code has mostly been reimplemented and IIRC I took inspiration from Qt tooltip code directly, so hopefully well tested code.
I tried to reproduce it, but with current SVN I can't.
I upgraded to 1.0.0-beta5 (Kubuntu 9.10) and, after a few minutes use, I didn't get any "sticky" tool-tips. Not a very thorough test, but promising. Before upgrading to the beta I was spending hours and hours rating thousands of photos and switching between the thumbnail view and preview a lot and the unrelenting "sticky" tool-tips were doing my head in. I'll be using it heavily over the weekend, so I'll report back again after that.
Note that Kubuntu unfortunately added a crashy release of digiKam. The crashes will mostly be triggered in the camera import dialog. digiKam-beta6 fixes these issues, but I'm not sure if Kubuntu will ever update the package due to their upgrading policies. If you don't fear compiling, grab the new beta6 instead for testing.
I've been busy tagging and rating a few thousand more photos in 1.0.0-beta5 (which I didn't find too buggy). I did not get a single repeat of the "sticky" tool-tips problem. In the previous version 0.10.0, I was getting "sticky" tool-tips ever minute or two. It looks like the new code has fixed the problem (whatever it was), so I think you can close this issue. Thank you.
Thanks for the report Gilles Caulier
Spoke too soon... I'm using 1.0.0-rc1 at present. If I hover over an image in the thumbnail view, a tool-tip opens. If I then quickly move the mouse pointer to the album tree, the tool-tip stays open. It even stays open on top of another widow when I hit Alt+Tab. Moving the mouse pointer into and out of the tool-tip gets rid of it. I happens every single time. I've never been able to reproduce it so easily before.... ....and now that I have typed in this bug report and tried to reproduce it again, I can't!.... ....and now that I have switched over and back a few times and have run a metadata update job in the background, it has started again.... ....now it has stopped again.... ....OK, while a job is running the the background chewing up CPU time, I hover over an image and the tool-tip fades in. WHILE it is fading in, if I hover over a second image until its tool-tip appears and quickly move the mouse to the album tree, the tool-tip sticks. Now, if I hover over another thumbnail and go quickly to the album tree, the tool-tip sticks again. It will stick every time from now on. It seems like digiKam has got itself into a strange state. It becomes very easy to reproduce until I switch to another window or until the background job finishes chewing up CPU time. While something else is running, the tool-tip takes much longer to fade in (maybe 0.5s instead of 0.1s), so it is easier to start displaying another tool-tip in that time. That seems to be the root of the problem: opening one tool-tip while another is fading in puts digiKam into a state that causes tool-tips to stick quite regularly (or all the time if you make an effort). Anyway, this is not "FIXED" yet. I'll let you change the state as appropriate.
Just to confirm: You mean the thumbnail view (or icon view) and not the thumbbar that appears when one image is opened for preview?
The thumbnail view (the one where when the main area of the window is full of image thumbnails with little annotations around them).
Digikam does not fade the tooltips at all. It just shows and hides. It's a kwin effect that does this fading. It would be interesting if you can reproduce with the Fading effect or desktop effect at all switched off. The code for the tooltip hiding was mostly copied from Qt, it should be pretty well tested.
Perhaps "mostly copied" and "pretty well tested" have resulted in "mostly works pretty well". Once the effect has been triggered the first time, it is not necessary to catch a tool-tip in "mid-fade" to trigger it again. There must be some state information somewhere that is causing this effect under some unanticipated circumstances. Perhaps the state is toggled without being checked to see if it is sane.
SVN commit 1066042 by mwiesweg: Dont check for isVisible() here. I cannot reproduce the problem for the bug report, but after careful reading, that's one of the few differences I can spot to Qt's QTipLabel. CCBUG: 196917 M +0 -3 itemviewtooltip.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1066042
Please give us feedback here with a recent version (1.2).
New digiKam 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ?
Not reproducible with 4.12.0