Version: 0.9.0 final (using KDE KDE 3.5.5) Installed from: Ubuntu Packages Compiler: g++ (GCC) 4.1.2 20061212 (prerelease) (Ubuntu 4.1.1-21ubuntu2) configured with --enable-final OS: Linux The new "Rebuild All Thumbnails" dialog box is extremely convenient. Can this dialog box be made "modeless" so that it does not block the operation of digikam? As RAW collections get larger, the probability of a user modifying enough images during the "rebuild all thumbnail" process to invalidate its results is relatively small. By being modeless, Digikam is not blocked for a potentially long period of time. Thank you.
An alternate approach could be to have an additional button labled "Work in background" that would close the window but leave a small progress bar showing in a part of the application frame. Users could right-click on the bar to restore dialog and/or abort the process. Actually, this kind of facility should be made available to any other plugin as a framework option. One thing that some Windows applications do well in this regard is they will modify their title bar text to reflect the progress level during lengthy operations. I.e. "digiKam - 34% complete" This allows users to work with other applications while still being able to monitor the progress of the app even if its minimized. Very handy.
I'd like to point out that bugs 137320, 138927, 140615 are all similar in the sense that in each case the reporter would like to have *background* (re)creation of thumbnails.
Yes, but there a some differences: * 140615: create all MISSING thumbnails for WHOLE album or ONLY A FOLDER (without blocking) * 137320: create all MISSING thumbnails for CURRENT FOLDER WHILE SHOWING it (without blocking) * 138927: REBUILD ALL thumbnails WITHOUT BLOCKING
effectively, any thumbnail generation/recreation should not block. [bugs.kde.org quoted mail] _________________________________________________________________ Fine Dining & Fancy Food. Check Out This Collection Of Good Eats. http://local.live.com/?mkt=en-ca/?v=2&cid=A6D6BDB4586E357F!378
Marcel, In 0.10.0 we using multithreading for thumbs creation. Do you see any problems to make batch thumbs creator dialog modeless here ? We can continue to use digiKam interface without problem during thumbs processing ? Gilles Caulier
Marcel, Are you seen my post #5 ? Gilles
I see no problems to make the window modeless if the batch creator is using its own thumbnail thread and just displaying progress information.
Created attachment 29436 [details] set thumb generator dialog modeless Marcel, With this patch, dialog can be reduced, but digiKam still unsuitable in background... Gilles
Look at DigikamApp::slotRebuildAllThumbs. We will want to call dialog->show() instead of dialog->exec(). Calling exec() ignores setModal().
Marcel, Right. Fixed. now all is fine... Question : whats about to do the same with "Rebuild All Finger-Prints" and "Update Metadata Database" tools ? Do you see any problems with concurrent database access if use continue to play with main interface when these tools work in background ? Gilles
SVN commit 899448 by cgilles: digiKam from trunk: set modeless batch thumbnaims generator dialog. BUG: 138927 M +1 -10 digikam/digikamapp.cpp M +0 -1 digikam/digikamapp.h M +5 -1 project/project.kdevelop M +3 -2 utilities/batch/batchthumbsgenerator.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=899448
I think in principle both should work fine. It may be that update meta data, which operates from the main thread, can cause UI delays.
SVN commit 900091 by cgilles: use modeless dialog with batch tools: -sync metadata with database -Rebuild all finger-prints. CCBUGS:138927 M +2 -11 digikam/digikamapp.cpp M +0 -1 digikam/digikamapp.h M +4 -3 utilities/batch/batchalbumssyncmetadata.cpp M +3 -2 utilities/batch/fingerprintsgenerator.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=900091