Version: 0.9.3 (using KDE 3.5.8) Installed from: Debian testing/unstable Packages OS: Linux The download images dialog puts small icons over each image to signal de status of the download, like a kde gear for "ongoing", a green check for OK and a red X for red. The problem I am reporting is that when it puts a red check in a image, no other information is given about what went wrong, and nowhere else in the dialog it is mentioned that something failed. This "error reporting" is very insufficient and is easy to be left unseen. What if the user downloads 100's of images and only a few of them have errors? The only way to be sure that all went well is to slowly scroll down the images list and carefully check each image's status symbol. Very cumbersome. And even if the user notes the red X, he has no idea what went wrong. This could be considered a wishlist or improvement, but I am filing it as a bug because it is very inadequate UI.
Note that this is related to Bug 158377 (that the errors in fact indicate that photos have been copied over other photos), although this is a separate issue
David, as file #158377 is solved, i supose this entry become invalid. Right ? Thiago, i need a fresh report from you using 0.9.4-beta1. Thanks in advance Gilles Caulier
This is a separate issue than bug #158377. It's just that this issue surfaced for me at the time as that bug. If the UI wasn't changed to warn the user about problems that happened, this bug is still present. Regarding the report using 0.9.4-beta1, I'll try it out, then.
Thiago, For me digiKam always report an error into a separate message box in live. For ex, if image cannot be taken from camera, deleted, copied to your computer, etc... and in this case digiKAm ask you if you want to continue of course. Or perhaps for you, the failed operations are special... Please give me more informations to hack... Gilles Caulier
Well, the bug #158377 was where I saw this behaviour. There were red X in the images but no separate message box for them. I don't know if there are other cases where this happens. Apart from that, I never had any error when downloading images with digikam (or I just missed them because I didn't have the habit of checking the Xs and Vs in each image (I do now!)).
Re Comment #5: The main reason this occurred was that the logic was not thread safe. In theory if everything is working the code should not produce this error. However, there could still be a problem in the copy if the final rename fails. It will show a red cross, but not the error dialog, since this is only shown if the CameraEvent::gp_downloadFailed signal is sent from the copying thread. This is much more unlikely without the threading issue - see my suggestions in http://bugs.kde.org/show_bug.cgi?id=158377 as to how to fix it but I don't think I'm going to have time to work on them.
What's news about this report ? it still valid using digiKam 0.9.4 ? Gilles Caulier
If I understood David Fraser's comments in bug #158377, this issue won't be solved until his suggestions in comment #18 of that bug are implemented.
SVN commit 973032 by cgilles: Camera Gui : new download history log view to simplify camera operations analysis. TODO : click on history entry must move camera icon view to right item. BUG: 158374 M +37 -7 cameraui.cpp M +2 -0 cameraui.h M +2 -1 cameraui.rc M +5 -0 cameraui_p.h AM logview.cpp [License: GPL (v2+)] AM logview.h [License: GPL (v2+)] WebSVN link: http://websvn.kde.org/?view=rev&revision=973032