<br><br><div><span class="gmail_quote">2008/3/5, Pau Rul·lan Ferragut <<a href="mailto:paurullan@bulma.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">paurullan@bulma.net</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

  hi all!</blockquote><div><br>hi<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I have used digikam for a long time and I decided to start contributing to the<br>

 project. </blockquote><div><br>Thanks to contribute...<br><br>Please read this page before (just to be sure) :<br><a href="http://www.digikam.org/?q=contrib" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.digikam.org/?q=contrib</a><br>
<br>...especially "Submitting patches" section.<br>
 </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The first thing I would like to do is to get rid of the stoping<br> thumbnail bug:<br>

 <a href="http://bugs.kde.org/show_bug.cgi?id=137320" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://bugs.kde.org/show_bug.cgi?id=137320</a><br> <br> Do any of the core developers believe this is too dificult to begin or are<br>
 working on it?</blockquote><div>
<br>Me and Marcel we work on KDE4 port.<br><br>I know than Arnd said to me by IRC than he will be interested to fix this problem too.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

 But I am having a dificult time trying to understand the scheme of the<br> program. Which modules are involved in the process?</blockquote><div><br>It's not to difficult, but code to touch is indeep in core implementation from digikam/digikam subfolder. Look here :<br>
<br>- a class named PixmapManager handle thumbs image for each icon item.<br>- a class named AlbumIconView manage view of icon from main interface.<br><br>in AlbumIconView, we have a method named nextItemToThumbnail() which is called by PixmapManager::slotComplete() when a thumb have been found in cache (or regenerate in background if necessary by a kio-slave)<br>
<br>When you select a new album or if you scrool icon view, PixmapManager will call AlbumIconView::nextItemToThumbnail() to get the next icon instance to thumbnailize.<br><br>Now if you look how AlbumIconView::nextItemToThumbnail() method work, you will see than the first and the last _visible_ items are used to limit regeneration of thumbs... <br>
<br>If you want to change the behaviours of thumbnails genration done in background the code from AlbumIconView::nextItemToThumbnail() need to be fixed to handle the first and the last iconview item item from current album, not the visible ones.<br>
<br>But take a care : regenerate all icon thumbs in background take a while, especially with slow computer. Of course a kioslave is a separate process which run outside of digiKam but we don't have any control to set the priority (as a separate thread)<br>
<br>So, for huge album and slow computer (using a single processor especially) thumb generation will slow down digiKam. This is why the current thumbs generation behaviours have been implemented to only generate current visible items.<br>
<br>This is my proposal : <br><br>- added a new option in "Album Settings" page from Setup dialog, into "Interface Options". A checkbox is enough here. The new option must be disable by default.<br>- patch AlbumSettings class to manage this new option.<br>
- patch AlbumIconView::nextItemToThumbnail() to handle this option (thrue an AlbumSettings method) to change behaviours accordingly (only visible items or all items)<br><br>Note : use KDE3 branch from svn to patch source code. Code will be backported later by me later to KDE4. Please use the bugzilla entry to post patch. Message will be automatically dispatched to this mailing list...<br>
<br>Best<br><br>Gilles Caulier<br><br><br></div></div><br>