Version: unknown (using 3.5.9, Arch Linux) Compiler: Target: i686-pc-linux-gnu OS: Linux (i686) release 2.6.25-ARCH When viewing images with the filmstrip (thumbnail bar) turned on, the filmstrip is not synchronized accordingly. 1. Open a folder with a lot of images (or use album subtree inclusion) 2. select an image from the middle of the set (not the first one, this will not show the error) 3. Now the filmstrip might not display the thumbnail of the currently viewed image (if it does, go to album view again and select another image, sometimes the first selection works) 4. if you press PageUp or PageDown, the filmstrip will be updated again. BUT: the filmstrip is acting strange. I assume that the current selected image is positioned in the middle of the filmstrip, but it is not. Most of the time it is the second last image in the filmstrip. So selecting images AFTER the current viewed is nearly impossible, because you don't see much choices.
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