| Summary: | Problem with "sticky" tooltips in album view | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | DGardner <damien> |
| Component: | Albums-MainView | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, marcel.wiesweg |
| Priority: | NOR | ||
| Version: | 0.10.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.12.0 | |
| Sentry Crash Report: | |||
|
Description
DGardner
2009-06-17 21:12:09 UTC
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 |