Summary: | Filmstrip in album view is not synchronized correctly | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Andi Clemens <andi.clemens> |
Component: | Preview-Image | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 0.10.0 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 0.10.0 | |
Sentry Crash Report: | |||
Attachments: | API change |
Description
Andi Clemens
2008-07-23 20:28:46 UTC
If i remember, Arnd has already reported a similar bug in the pass, to showfoto component... Gilles Really? I can't find that entry? Maybe it has been closed already... I found out that the filmstrip is not set to the current selection if the image size is bigger than 100kb. Very strange but all images in an album will be displayed correctly in the filmstrip if they have a size less than 100kb. I guess this is some kind of signal / slots problem, maybe the update signal comes too late if an image takes longer to load. Since 2 hours I'm playing around with GDB and callgrind, but no clue so far. Just wanted to give an update here. Andi SVN commit 873062 by aclemens: fix centering of the selected image in filmstrip this commit will fix the centering of the currently selected image in album icon view as well as in image editor. Strangely showFoto isn't working, although it is derived from the same class as image editor. There is still a problem on first init: sometimes the width of the content is unknown, so that a item in the thumbbar is highlighted, but the bar is not scrolled to the correct position. This is only true for the first image displayed, all the other times it is working, since now the thumbbar is not re-generated all the time. This patch also fixes the re-generating of the thumbbar every time an image is selected and viewed from the album icon view. On large albums the old behavior was very slow. Marcel, Gilles, we still have the thread problem I mentioned before and that someone else posted here. Sometimes you get a very high CPU load while thumbbar is created and digiKam will crash on close. I have not figured out why this is sometimes happening. CCBUG:167320 M +18 -14 digikam/albumwidgetstack.cpp M +4 -4 libs/widgets/common/thumbbar.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=873062 Gilles, I guess I found a solution for the problem that the thumbbar is not always displayed correctly. For this I have made the slotUpdate() from thumbbar.cpp public and call it directly now, before this it was called by triggerUpdate(), but somehow this didn't work out all the time. Since triggerUpdate calls slotUpdate immediately (timer->start(0)), there is no big difference in calling slotUpdate() directly. So if this really fixes the problem, we might think about removing the trigger method and just call slotUpdate in the corresponding places. What do you think? Andi Created attachment 28011 [details]
API change
This little patch combined with the above commit should fix the problem.
Andi
Another way would be to call slotUpdate() directly from triggerUpdate(), without the use of a timer, if we want to keep triggerUpdate() method. SVN commit 873272 by aclemens: make triggerUpdate() call slotUpdate() directly, remove the timer since the timer calls slotUpdate() immediately, we can also remove the timer completely and call the slot manually from within triggerUpdate(), so no API change will be done. This seems to fix the problem that sometimes a thumbnail in the filmstrip isn't shown correctly. Maybe we don't even need triggerUpdate() anymore, but if we want to do additional processing in there, this is the best solution right now that doesn't change any program logic. BUG:167320 M +2 -1 NEWS M +1 -0 digikam/albumwidgetstack.cpp M +1 -8 libs/widgets/common/thumbbar.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=873272 |