Version: 2.0.0 (using KDE 4.6.1) OS: Linux If you drag a tag to a currently not highlighted thumpnail and you say "assign tag to this item" it wil give the tag not to the thumpnail you point to but it is assigned to the currently selected thumbnail(s) instead. The metadata of both photos have changed now (should be only one) and in a different way. Actually, the wrong (highlighted) photo changed in the right way and the right photo got the tag but without the parents. Reproducible: Always Steps to Reproduce: You should highlight one thump and than drag from ¨captions/tags¨ window a tag including parents to the image next to the highlighted one and drop with ¨assign to this¨ Actual Results: as in details good workaround for now. Never tag not highlighted pictures.
Cannot reproduce. Anyone?
I tried, my first thought, wow, it´s gone but NO it is not gone. Try this please: I have a tag tree, three levels, I right click ¨select parents¨ then I select the tag in the deepest level. Now it is checked along with its parents, now I drag it to a not highligted picture, I say applay change. Now the highlighted picture tags are updated instead of the pointed to picture, as well ass the pointed to picture in the wrong way. If you do´nt manage to reproduse I can make a video, and you will see it happen. sorry for the bad news, Rinus Op 23-05-11 21:16, Marcel Wiesweg schreef: > https://bugs.kde.org/show_bug.cgi?id=270158 > > > > > > --- Comment #1 from Marcel Wiesweg<marcel wiesweg gmx de> 2011-05-23 21:16:01 --- > Cannot reproduce. Anyone? >
I've tried this: 1) select a picture 2) in the tag panel check a child and parent tag 3) drag the children tag on a different image than 1) A) A dialog box appear asking for tag assignment 4)click on "assign pippo/superman to this item" B) A dialog box appear asking: "You have edited the tags of the image. Do you wanto to apply tour changes?" 5) ckick "yes" Now the image in 1) has both child and parent tag, image 3) has only the child tag That's because dialog B) refers to image in 1) and dialog A) refers to image in 3) A little bit confusing but expected, maybe start a drag operation should uncheck the tags or vice-versa checked tags should stop dragging operations or maybe it should stay exactly as is. DB Backend MySQL compiled from latest git
Op 25-05-11 11:45, Francesco Riosa schreef: > https://bugs.kde.org/show_bug.cgi?id=270158 > > > Francesco Riosa<francesco+kde@pnpitalia.it> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |francesco+kde@pnpitalia.it > > > > > --- Comment #3 from Francesco Riosa<francesco+kde pnpitalia it> 2011-05-25 11:45:45 --- > I've tried this: > 1) select a picture > 2) in the tag panel check a child and parent tag > 3) drag the children tag on a different image than 1) > A) A dialog box appear asking for tag assignment > 4)click on "assign pippo/superman to this item" > B) A dialog box appear asking: > "You have edited the tags of the image. Do you wanto to apply tour changes?" > 5) ckick "yes" > > Now the image in 1) has both child and parent tag, image 3) has only the child > tag > That's because dialog B) refers to image in 1) and dialog A) refers to image in > 3) > Thanks for the accurate test. > A little bit confusing but expected, expected from the programmers point of view not the users one > maybe start a drag operation should > uncheck the tags As I understand it right, you could drag to one picture and have to check the tag again for the next picture, thats not convenient. > or vice-versa checked tags should stop dragging operations or So, you mean, that nothing happens when trying to drag the tag, might be the best option from the point of savety, but not so nice. > maybe it should stay exactly as is. I would say ¨no¨, it leads definately to wrong tags. I am aware of the phenomenon but other users are not. would it not be possible that dialogue B is aware of what happend before with dialogue A? After all dialogue B applies a change that actualy NOT has been made. Rinus > DB Backend MySQL compiled from latest git >
Hm, to check a checkbox I need to click on the checkbox directly, not on the tag name or any other part of the element. Additionally, when a drag is started if the click is done directly on the checkbox, the checkbox is _not_ checked here, only the drag is started (Oxygen on Linux). So I may have misunderstood something once again but I dont really see the problem - if you edit anything in the Comments/tags sidebar, it applies to the current selection. That you can start a drag from the tags tree view is extra, independent functionality - you can start a drag from any tags tree view.
Op 29-05-11 15:53, Marcel Wiesweg schreef: > https://bugs.kde.org/show_bug.cgi?id=270158 > > > > > > --- Comment #5 from Marcel Wiesweg<marcel wiesweg gmx de> 2011-05-29 15:53:13 --- > Hm, to check a checkbox I need to click on the checkbox directly, not on the > tag name or any other part of the element. > Additionally, when a drag is started if the click is done directly on the > checkbox, the checkbox is _not_ checked here, only the drag is started (Oxygen > on Linux). > So I may have misunderstood something once again but I dont really see the > problem - if you edit anything in the Comments/tags sidebar, it applies to the > current selection. That you can start a drag from the tags tree view is extra, > independent functionality - you can start a drag from any tags tree view. > Hi Marcel, I highly appreciate your attention on the subject. But your reaction is a bit as if you go with your car to the garage because you have no brakes, and they tell you: yes of course that is how we designed this super XTG$ model: no brakes. Of course, if I follow a strict protocol, while tagging, it is ok, but it is verry error prone. I give you a link to a few second´s movie explaining the problem. http://dl.dropbox.com/u/30482865/Tag%20problem.mp4 If that doesn´t help I won´t bother you any further on the subject. All the best, Rinus
Ok, the video seems to tell me where the problem is. First, lets define to states: "checked" means there is a checkmark in the checkbox, "selected" means the tag is drawn in blue, while all other tags are white. The two are independent. It seems your aim is to drag three tags in a batch on a picture. That does not work current, because the tree view is single-selection; only one tag is selected at a time, and you only drag one single item. There is a wish here on b.k.o. to have multiple selection. Now you use the menu entry which says "Select Parents" but which in fact with the above terminology checks the tag. This operation always refers to the currently selected items, but the checkbox has no connection at all to the drag-drop behavior. So, if you want to assign three tags to n items, select all items (you have multiple selection here) and then check the relevant tags, you can do this with the context menu. With drag-drop, you can only apply one tag (to n items) at a time at the moment.
Marcel, did you see the video till the end? It is not about what I want to do. It is about what I do not want to happen i.e. applying the tag ¨cruel cat¨ to the lovely bird while I did not drop it there, and visa versa. Look at the tags beneath the pictures at the end of the video. I understand perfectly how it is programmed, but (don´t shoot the messenger) for an application with professional aspirations is this simply unacceptible. can´t make it any clearer. Rinus Op 30-05-11 20:35, Marcel Wiesweg schreef: > https://bugs.kde.org/show_bug.cgi?id=270158 > > > > > > --- Comment #7 from Marcel Wiesweg<marcel wiesweg gmx de> 2011-05-30 20:35:29 --- > Ok, the video seems to tell me where the problem is. > First, lets define to states: "checked" means there is a checkmark in the > checkbox, "selected" means the tag is drawn in blue, while all other tags are > white. The two are independent. > > It seems your aim is to drag three tags in a batch on a picture. That does not > work current, because the tree view is single-selection; only one tag is > selected at a time, and you only drag one single item. There is a wish here on > b.k.o. to have multiple selection. > Now you use the menu entry which says "Select Parents" but which in fact with > the above terminology checks the tag. This operation always refers to the > currently selected items, but the checkbox has no connection at all to the > drag-drop behavior. > > So, if you want to assign three tags to n items, select all items (you have > multiple selection here) and then check the relevant tags, you can do this with > the context menu. > With drag-drop, you can only apply one tag (to n items) at a time at the > moment. >
I see in the video: Bird is selected (and thus edited by the Caption/tags sidebar) Cruel Cat and its parent tags are checked (and the three tags properly assigned to the bird, which is currently being edited, as soon as you click Apply or select a different image) Independent from this: Cruel Cat is selected (it is also checked, but that does not matter. You could just as well drag Flowers) Cruel Cat is dragged to the Cat (and properly assigned, single tag) You dont need to drop a tag to assign it; checking is another way to assign a tag.
Rinus, This file still valid using digiKam 2.4 ? Gilles Caulier
What's news about this file ? It still valid using digiKam 3.5.0 ? Gilles Caulier
Rinus, We need a fresh feedback here... Gilles Caulier
New digiKam 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ?
digiKam 4.12.0 is out : https://www.digikam.org/node/741 We need a fresh feedback using this release please... Thanks in advance.
With digiKam 5.0.0, this problem is not reproducible. I close this file now. Don't hesitate to re-open if necessary. Gilles Caulier