Bug 142774

Created attachment 19923 [details]
Screenshot of a scenario where it should be possible to be able to move an item across albums

*** Bug 147981 has been marked as a duplicate of this bug. ***

SVN commit 743941 by cgilles:

digiKam from KDE3 branch : support Copy and Paste between Physical Albums and Tags Albums
CCMAIL: digikam-devel@kde.org


 M  +43 -17    albumiconview.cpp


--- branches/extragear/kde3/graphics/digikam/digikam/albumiconview.cpp #743940:743941
@@ -689,7 +689,6 @@

    // --------------------------------------------------------

-
    popmenu.insertItem(SmallIcon("edittrash"),
                       i18n("Move to Trash", "Move %n Files to Trash" , selectedImageIDs.count() ), 16);

@@ -848,29 +847,56 @@
 void AlbumIconView::slotPaste()
 {
    QMimeSource *data = kapp->clipboard()->data(QClipboard::Clipboard);
-    if(!data || !QUriDrag::canDecode(data))
+    if(!data)
        return;

-    if(d->currentAlbum->type() == Album::PHYSICAL)
+    if(d->currentAlbum->type() == Album::PHYSICAL &&
+       QUriDrag::canDecode(data))
    {
-        if (QUriDrag::canDecode(data) &&
-            d->currentAlbum->type() == Album::PHYSICAL)
-        {
-            PAlbum* palbum = (PAlbum*)d->currentAlbum;
-
-            // B.K.O #119205: do not handle root album.
-            if (palbum->isRoot())
-                return;
+        PAlbum* palbum = (PAlbum*)d->currentAlbum;
+
+        // B.K.O #119205: do not handle root album.
+        if (palbum->isRoot())
+            return;

-            KURL destURL(palbum->kurl());
+        KURL destURL(palbum->kurl());

-            KURL::List srcURLs;
-            KURLDrag::decode(data, srcURLs);
+        KURL::List srcURLs;
+        KURLDrag::decode(data, srcURLs);

-            KIO::Job* job = DIO::copy(srcURLs, destURL);
-            connect(job, SIGNAL(result(KIO::Job*)),
-                    this, SLOT(slotDIOResult(KIO::Job*)));
+        KIO::Job* job = DIO::copy(srcURLs, destURL);
+        connect(job, SIGNAL(result(KIO::Job*)),
+                this, SLOT(slotDIOResult(KIO::Job*)));
+    }
+    else if(d->currentAlbum->type() == Album::TAG &&
+            ItemDrag::canDecode(data))
+    {
+        TAlbum* talbum = (TAlbum*)d->currentAlbum;
+
+        // B.K.O #119205: do not handle root album.
+        if (talbum->isRoot())
+            return;
+
+        KURL::List      urls;
+        KURL::List      kioURLs;
+        QValueList<int> albumIDs;
+        QValueList<int> imageIDs;
+
+        if (!ItemDrag::decode(data, urls, kioURLs, albumIDs, imageIDs))
+            return;
+
+        if (urls.isEmpty() || kioURLs.isEmpty() || albumIDs.isEmpty() || imageIDs.isEmpty())
+            return;
+
+        QPtrList<ImageInfo> list;
+        for (QValueList<int>::const_iterator it = imageIDs.begin();
+             it != imageIDs.end(); ++it)
+        {
+            ImageInfo *info = new ImageInfo(*it);
+            list.append(info);
        }
+
+        changeTagOnImageInfos(list, QValueList<int>() << talbum->id(), true, true);
    }
 }

*** Bug 125789 has been marked as a duplicate of this bug. ***

*** Bug 120959 has been marked as a duplicate of this bug. ***

Just tested moving images in the Albums View:
when you move an image, the icon view is not updated
(but the image is moved). This only seems to happen when
recursive viewing of albums is activated.

About copy and paste: if I am in recursive view mode
and do a CTRL+C of one image of the first displayed album
and try to paste it into a different album (but still in the same view), 
one gets a message box "File already exists",
The picture isn't stored on the local host.
Click on this label to load it".
Suggesting a new name works (though there is the confusing
"Rename" button; "Copy" would be better IMO).

So to me it seems as if the path, where the image should
be copied to is always determined from the first displayed folder,
but not from the currently selected (or active) image.
((Note that I am not sure what to do if 
http://bugs.kde.org/show_bug.cgi?id=134389
is implemented. I.e., for a merged view
there would be no separators.))

Additional remark: image rotation according to exif is not taken
into account properly in the message box.

Created attachment 22623 [details]
Drag & Drop supports over digiKam sidebar...

This patch implement D&d support with digiKam sidebar, like Amarok, but using a
more universal way to do it...

Problem is about KMultiTabBar class from KDE API witch do not provide D&D
supports:

http://websvn.kde.org/branches/KDE/3.5/kdelibs/kutils/kmultitabbar.h?revision=535111&view=markup


Amarok team have re-implemented whole KDE widget to do it... It's a waste of
time (:=))) :

http://websvn.kde.org/branches/stable/extragear/multimedia/amarok/src/multitabbar.h?revision=629191&view=markup


... and of course for Amarok KDE4 port, the widget have been fully
re-implemented from scratch...

My solution is more simple/universal/portable : using QWidget::eventFilter()

This patch fix Digikam::Sidebar in this way. When you drag an album folder or
album items to a sidebar tab button,  this one is actived and you toggle
automatically to the right view... to drop items...

This patch do not work with all cases. For ex, you cannot yet D&D from Tag icon
view to Album icon view. More changes need to be done in AlbumIconView class...
I need more time...

Please test this patch against current KDE3 implementation from svn and let's
me ear your viewpoints...

Gilles Caulier

Works great :)

About cases where user will not drag into album but some other view
- I wonder if they are really usable. D'n'd from album to some time?
Should it change date of image? Overly complicated.

But if you want to proceed there is interesting(?) bug: when dragging
from Album into Tag, assignation of tags doesn't work when trying to
drop into active (visible) tag. Not only when dropping into main part
but also when trying to drop into tree view.

IMO just concentrate on d'n'd into Album. Rest of scenarios is much
less probable and much more complex to implement - not even
as implementation in code but as predicting users expectations.

I agree with Mikolaj that it makes only sense to move from anywhere to Album structure. 
- Tags can be mass-attributed by dragging tags to selections. 
- Time/date can be batch-changed with kipi-plugins

The only additional d&d feature would be to d&d within the main window across the horizontal Album separators.

Gerhard

SVN commit 751207 by cgilles:

digiKam from KDE3 branch : support of copy and paste over albums on the same icon view using recursive mode 
CCBUGS: 142774


 M  +23 -8     albumiconview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=751207

SVN commit 751252 by cgilles:

digiKam from KDE3 branch : support D&D between albums to move/copy items when recurssive mode is enable
CCBUGS: 142774


 M  +95 -14    albumiconview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=751252

Arnd, Fabien, Mik, Gerhard,

Before to release 0.9.3, please test my recent patches about copy/move items between albums using recurssive mode... Thanks in advance...

Nota: I'm will not available during one week from 22/12/2007 to 29/12/2007. Take a care than normally 0.9.3 must be released at 23/12/2007... If something is wrong, well delay release date.

Gilles

SVN commit 751278 by cgilles:

backport commits #751264 from KDE3 branch : support Drag & drop with Sidebar widget
CCBUGS: 142774


 M  +68 -0     sidebar.cpp  
 M  +3 -0      sidebar.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=751278

Gilles, I checked current svn and drag&drop seems to work fine
when in album view (i.e.across the horizontal Album separators.

However, is there anything which would be against allowing drag&drop
across the horizontal Album separators
when in Tags/Date/Search View? In these cases we (currently) still have a separation between folders, so moving items around would be just the same
as in album view, or am I missing something?

Best, Arnd

Arnd,

About Date and search icon view, nothing is implemented.

About Tag icon view, well it's implemented but nothing is doing. I cannot investiguate better now.

If you want to take a look, methods to check are AlbumIconView::slotPaste(),  and AlbumIconView::contentsDropEvent(). AlbumIconView::contentsDragMoveEvent() method normally is fine, but i'm not sure (:=)))

Marcel, 

Please, take a look too, if all is fine for you in these methods. Thanks in advance...

Gilles (Who prepare Christmas travel (:=)))

I tested the svn 751278, works fine in 'Include Album Tree' view mode :-). It is very important to have this feature, as it is intuitive for rearranging things.

I also agree with Arnd (#14), the drag across horizontal separation is foremostly useful in date, search and tag view. It is less useful in album view (the only mode it works now), because the tree is open in the sidebar anyway. In practical cases, there are always many more images in a flattened album view than in a date view, and therefore you rather drop into the sidebar tree instead of scrolling up and down the view until youcross the separation.

Gerhard 

Gerhard, Andi, Arnd, Mik,

For me this file can be closed now. A lots of works have been done here.

For more specific points, news files can be open. 

Are you agree ?

Gilles Caulier

I didn't even know that you can D&D in iconview :-) Found a new feature!!
Sure it would be nice to D&D an image from album iconview to the tags view (which practically is working, but the tag will not be assigned), but then again, this is a strange workflow for me.
Since you can D&D from Caption/Tags all the time (or tags filter), I don't see any needs to D&D an image to the tags folderview as well.

Andi

Andi,

Here, with my large screen, i always use D&D everywhere. It's really a pleasure.

So, as the lead subject of this file is fully implemented in 0.9.5 and 0.10.0, i close this file now.

Gilles Caulier