umsp used i select 2 photos then i click on "download" button then all photos are selected ! during downloading process - the button "cancel" stays in grey" - you can only cancel the download by closing the import window Reproducible: Always
also true with ptp
if you select 2 photos then right click then select "download" option in contextual menu then no pb
Philippe, I cannot reproduce this problem with 3.0.0 where all import gui have been re-written through GoSC 2012 project Can you test and confirm using current implementation from git/master (next 3.0.0-beta2, it's better than beta1) Gilles Caulier
The current importUI seems to be misbehaving a lot, unfortunately. I can not reproduce the problem that is described in the bugreport, but it has different issues: - Slow on 50 images, unresponsive on 500 images (I have to kill digiKam), 100% CPU usage while rendering the thumbs (or fetching other information) - If you select a folder in AlbumUI, than press CTRL+I to start the importUI and select images to download, it doesn't remember the currently selected folder from albumUI. You have to select it manually in the "album selection dialog". - Custom rename is broken - The "thumbnails" and "preview item" buttons are not working correctly - The thumbbar is too big and can not be shrunken - The thumbbar is veeery slow when rendering the thumbnails, you can sometimes watch the thumbs being drawn line by line (in albumUI it works fast) - Already downloaded images are not remembered, they always appear as "New" items etc... I guess I will open bugreports for all of the mentioned issues... Andi
>> Can you test and confirm using current implementation from git/master (next 3.0.0-beta2, it's better than beta1) if you have a packet for a distribution i can install in virtualbox this distrib and test digikam 3.0.0
Islam, take a look to Andi comment #4 please Gilles Caulier
OK, I will take a look at these issues and report back here.
Andi, I tested the issues you described here is what I got: 1- Slow on 50 images, unresponsive on 500 images (I have to kill digiKam), 100% CPU usage while rendering the thumbs (or fetching other information) -- I tested it with 1955 items from UMS, it behaves just fine, I am now have no digital camera to test it. 2- If you select a folder in AlbumUI, than press CTRL+I to start the importUI and select images to download, it doesn't remember the currently selected folder from albumUI. You have to select it manually in the "album selection dialog". -- This issue is reproducible, I will fix it and report back here. 3- Custom rename is broken -- I tried to download some existing images and the custom rename dialog popped up and it worked just fine, It is very strange that it didn't work for you, can you please describe your steps to reproduce? 4- The "thumbnails" and "preview item" buttons are not working correctly Can you please describe how you expect them to work and how they worked with you? .. I tried to use them and they behave just fine. 5- The thumbbar is too big and can not be shrunken This issue was an old one, and I fixed it recently, here is a screenshot for the thumbbar I get http://imagebin.org/231218 6- The thumbbar is veeery slow when rendering the thumbnails, you can sometimes watch the thumbs being drawn line by line (in albumUI it works fast) -- I tried it with UMS, it works the same as albumUI, I think you tried it with a digital camera connected, so the thumbnails loading of it was slow (and it is normal sometimes). 7- Already downloaded images are not remembered, they always appear as "New" items -- I don't get what you mean by remembered?, did you expect that if you close the importUI and reopen it the downloaded images will be marked as downloaded? or what?
Islam, I test here too, using an USB card reader. For 1/ and 6/ are reproducible. In fact the problem is that you render all items thumbnails. This will bloat memory if you don't have enough In previous implementation, i have solutioned this problem to render only image visible on screen and query for new only when user scroll icon-view. I also cached all thumb in a limited space (100 items). This prevent memory consumsion. The old class dedicated, that you don't have used in your project is this one (taken from an old branch) : https://projects.kde.org/projects/extragear/graphics/digikam/repository/entry/utilities/cameragui/controller/camerathumbsctrl.h?rev=gsoc%2Fclone This file is removed from git/master. Check git history to have the last version... Gilles
(In reply to comment #9) > Islam, > > I test here too, using an USB card reader. For 1/ and 6/ are reproducible. > > In fact the problem is that you render all items thumbnails. This will bloat > memory if you don't have enough > > In previous implementation, i have solutioned this problem to render only > image visible on screen and query for new only when user scroll icon-view. I > also cached all thumb in a limited space (100 items). This prevent memory > consumsion. > Well sounds like classical ModelView to me... shouldn't this be doable with a Q*View class? No need to manually decide when to display a thumb and when not...
Sorry forgot to cc this bug about this commit. http://quickgit.kde.org/?p=digikam.git&a=commit&h=48ffa887c54e45e0951a67803d4b833452533a69 Gilles, about your comment#9 as Andi said the current model/view classes of importUI do that, the thumbnails start loading when user scroll to them, and there is a caching mechanism already implemented.
Can you confirm if this bug still exists? Especially because there's no single download button anymore, but you have to select the action from the dropdown list, I think this bug can be closed. If there are other valid bugs (like those mentioned in the comments?) new entries should be created for them if there is none available.
opensuse 13.1 , kde 4.12 , digikam 3.5 Samsung Galaxy SII P , android 4.2.2 ptp protocol mtp protocol using "download selection" works well then i consider this bug report resolved