Bug 122653

Can nobody confirm this?

Yes, it happens for me also.

Yes, of course i can confirm this bug.

I suspect than camera picture download bug #126427 is the same problem.

After investiguations, the problem is relevant of KURL construct by digiKam and passed to KDE kio-slave to copy/move the pictures.

The KURL is given by PAlbum class and use "digikamalbum:/" protocol witch is unkown by KDE kio-slave. This is why the dialog cannot found the image to display.

Not yet tested, but if i force in digiKam to use "file:/" protocol with kurl passed to KDE kio-slave, all will work fine.

Marcel, i would have your viewpoint about "digikamalbum:/" protocol: 

- The error come from PAlbum class where a full compatible kurl method need to be added, especially for KDE kio-slave...

or

- The error come from kio-slave protocol installation witch is not properlly installed and reconized by KDE...

or 

- Something is missing in digikamalbum kio-slave to be compliant with KDE rules.

Gilles

AlbumFolderView::contentsDropEvent will call DIO::copy with kioURLs.
DIO::copy will call KIO::copy.

KIO::copy will check if the dest exists, it does, so I think it is the KDE libs that will popup the overwrite dialog. Of course, it is unknown to KDE libs that digikamalbums:/ is actually a local file. Don't know how to change that.

Then, KDE libs will load the proper kioslave, and kio_digikamalbums::copy will get called. You have the debug statement from that method in your ~/.xsession-errors.

Then the copy method will somewhere return with KIO::ERR_ACCESS_DENIED, and the error message is sent to digikam.
So we have to fix the ioslave.

Or, some not-thought-through ideas:
- in albumfolderview, use normal file:/ URLs and afterwars do the same as in ImageWindow::saveAsIsComplete. Race-condition proof?
- use ForwardingSlaveBase for all file-related stuff in our ioslave - a pity, it's only available for KDE 3.4.

SVN commit 586141 by mwiesweg:

Provide the UDS_LOCAL_PATH entry.
Now the KDE replace file dialog will no longer think digikamalbums:/ is a remote file.

CCBUG: 122653


 M  +5 -1      digikamalbums.cpp  


--- trunk/extragear/graphics/digikam/kioslave/digikamalbums.cpp #586140:586141
@@ -1149,7 +1149,11 @@
     atom.m_uds = KIO::UDS_NAME;
     atom.m_str = QFileInfo(path).fileName();
     entry.append(atom);
-    
+
+    atom.m_uds = KIO::UDS_LOCAL_PATH;
+    atom.m_str = path;
+    entry.append(atom);
+
     return true;
 }
 

When I tested this, I got an error message, (#4), but now it seems to me this bug is only about the "not on local storage" message. This is fixed now, so I close this.

SVN commit 605173 by mwiesweg:

Revert fix for bug #122653, as a temporary fix for bug #137282

CCBUG: 137282, 122653


 M  +7 -0      digikamalbums.cpp  


--- trunk/extragear/graphics/digikam/kioslave/digikamalbums.cpp #605172:605173
@@ -1151,11 +1151,18 @@
     atom.m_str = QFileInfo(path).fileName();
     entry.append(atom);
 
+    /*
+    // If we provide the local path, a KIO::CopyJob will optimize away
+    // the use of our custom digikamalbums:/ ioslave, which breaks
+    // copying the database entry:
+    // Disabling this as a temporary solution for bug #137282
+    // This code is intended as a fix for bug #122653.
 #if KDE_IS_VERSION(3,4,0)
     atom.m_uds = KIO::UDS_LOCAL_PATH;
     atom.m_str = path;
     entry.append(atom);
 #endif
+    */
 
     return true;
 }

Reopening, see comment #7

Marcel,

Do you know a new issue for this file ?

Gilles

I have not tried it for KDE4, for KDE3, the situation did not change as far as I see...

Marcel, 

What news with 0.10.0 ? It still valid ?

Gilles

Yes this is still valid. We can re-analyze if we have other means to fix this for KDE4 of course, I dont know currently.

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

I promote this bug to 0.10. We can see if we find a solution with KDE4, but it's difficult as the relevant dialog comes from kdelibs directly.

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

Still not working (and maybe never will).
You get the "remote src" labels and when you click them, the thumbnail will appear.
Maybe we need to write a "real" slave for this, not only a wrapper, like here:
http://lxr.kde.org/source/KDE/kdebase/workspace/kcontrol/kfontinst/kio/KioFonts.h

But then again I don't know if you get the dialog (properly yes).

Andi

Hmm but why is it even working when I click the label?
If this is possible, it should also be possible to display the thumbnail in the first place, right?

Andi

The problem is in the depth of KIO, where our requests are identified as "remote" because the protocol is unknown and no UDS_LOCAL_PATH is provided.

The ioslave is not needed as much as in autumn of 2006, the fix from #5 may in fact be applicable now again.
Should we dare it?

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