(*** This bug was imported into bugs.kde.org ***) Package: konqueror Version: KDE 3.0.3 Severity: normal Installed from: SuSE RPMs Compiler: Not Specified OS: Linux OS/Compiler notes: Not Specified At first I apologize if "Konqueror" is not the proper group for this bug since I think this is related with Klipper (copy-n-paste) but I just couldn't find klipper in the webpage. This bug appear in KDE 3.0.3 it does not appear in KDE 3.0.2 (confirmed at 2 machines one with SuSE72 and the other is 8.0). Case 1. I open File manager (Konq in File management mode) -- let's call it windowA. Now switch to Desktop. Select several files at desktop. Press Ctrl-C (copy) and then switch focus to windowA. I should be able to paste those files but couldn't. I tried Ctrl-V or using menu Edit or right-click to pop-up a menu but on both occasion the "paste" entry is disabled. The copy-and-paste only work in the desktop or between "file manager windows". Case 2. Open Konqueror browse to remote ftp (let's call this windowA). Open file manager (Konq in File Management profile). Select files in windowB copy (Ctrl-C). Then switch focus to windowB. In windowB files can't be pasted. The copy-and-paste only work if I copy from windowA and paste in windowA or between "file manager windows". Regards Verdi (Submitted via bugs.kde.org)
This bug is still around in RC5 (using todays KDE_3_1_BRANCH). Generally, the cases seems to be: 1. If you "copy" a file on the desktop, you can't paste it into any konqueror instance. ctrl-v doesn't work and the paste buttons are also disabled. 2. If you "copy" a file in a konq instance, you can only paste into konq windows managed by this _process_ or onto the desktop. You can ctrl-n and get a new konq with the paste button enabled and pasting works fine. A konq window from a different process will not have the paste button enabled, and ctrl-v doesn't work. 3. If you mark a file for "copy" and then close the konq instance, you can't paste this anywhere. The paste button will be enabled for the desktop, but you'll only get "the clipboard is empty" or a textfile with the path to the file you wanted to copy. (I've seen both cases, but haven't quite figured out when the respective case happens.) 4. If you mark a file for "copy" and then delete the file, paste buttons are still enabled, but will only give you a "file not found" error. (I really don't know if this should work at all, but a user might think it equivalent to "move".) All in all this makes for a very confusing user experience when it comes to copying files in konqueror (and combine it with bug #51620 for some real confusion.. :) )
Subject: kdebase/libkonq CVS commit by orlovich: Fix the originally reported part #47418 (additional comments/reports still need to be addressed; but this fixes the big issue) -- unable to copy/paste files between KDesktop and Konqueror or multiple Konqueror processes. The problem is that libkonq's code for updating the action was looking for non-zero size of format 0 -- which when getting that data from a real clipboard (and not a local KonqDrag) was text/plain encoded with utf8 (which Qt always advertises when text/plain is there) -- but KonqDrag doesn't actually provide the data, resulting in 0 bytes.. This provides that encoding, a long with the legacy latin-1 encoded one; the patch is virtually identical to the one I did for KUriDrag a while ago... (Will be backported to 3.1 branch..) CCMAIL:47418@bugs.kde.org M +32 -0 konq_drag.cc 1.19 --- kdebase/libkonq/konq_drag.cc 1.19: @@ -37,4 +37,10 @@ const char* KonqIconDrag::format( int i else if ( i == 3 ) return "text/plain"; + else if ( i == 4 ) //These two are imporant because they may end up being format 0, + //which is what KonqDirPart::updatePasteAction() checks + return "text/plain;charset=ISO-8859-1"; + else if ( i == 5 ) //..as well as potentially for interoperability + return "text/plain;charset=UTF-8"; + else return 0; } @@ -63,4 +69,30 @@ QByteArray KonqIconDrag::encodedData( co uris.append(KURL((*it).latin1(), 106).prettyURL()); // 106 is mib enum for utf8 codec QCString s = uris.join( "\n" ).local8Bit(); + a.resize( s.length() + 1 ); // trailing zero + memcpy( a.data(), s.data(), s.length() + 1 ); + } + } + else if ( mimetype.lower() == "text/plain;charset=iso-8859-1") + { + if (!urls.isEmpty()) + { + QStringList uris; + + for (QStringList::ConstIterator it = urls.begin(); it != urls.end(); ++it) + uris.append(KURL(*it, 106).url(0, 4)); // 106 is mib enum for utf8 codec; 4 for latin1 + + QCString s = uris.join( "\n" ).latin1(); + a.resize( s.length() + 1 ); // trailing zero + memcpy( a.data(), s.data(), s.length() + 1 ); + } + } + else if ( mimetype.lower() == "text/plain;charset=utf-8") + { + if (!urls.isEmpty()) + { + QStringList uris; + for (QStringList::ConstIterator it = urls.begin(); it != urls.end(); ++it) + uris.append(KURL(*it, 106).prettyURL()); // 106 is mib enum for utf8 codec + QCString s = uris.join( "\n" ).utf8(); a.resize( s.length() + 1 ); // trailing zero memcpy( a.data(), s.data(), s.length() + 1 );
Case 1 (Desktop to konqueror) still does not work on KDE-3.1 (Dec 20).
In KDE 3.1: Case 1 is solved, copy-paste from/to desktop is ok. Case 2 is still not solved, I still can't copy from konqueror_browsing_ftp to konqueror_running_filemanagement. Note that my setting (in kontrol center - kde components - file manager) is to never minimize memory, so konqueror_ftp and konqueror_localfile are two separate processes.
Hmm.. Both cases work fine for me, among different processes, too (started from CLI). Looks like I am missing some detail needed for reproducing this (someone mentionned the same problem on the dot, too).
Subject: Re: copy-and-paste file does not work for specific cases On Friday 14 March 2003 09:52, you wrote: > ------- Additional Comments From mo002j@mail.rochester.edu > 2003-03-14 02:52 ------- Hmm.. Both cases work fine for me, among > different processes, too (started from CLI). Looks like I am missing > some detail needed for reproducing this (someone mentionned the same > problem on the dot, too). Perhaps it's related to the binary. I once use 3.1 binaries (for suse 8.0) available at ftp.kde.org, now I'm using binary from suse's ftp (because the binaries are newer builds). When using binary from ftp.kde.org, the copy&paste works for both cases. And now with binaries from suse's ftp, copy&paste does not work again (for both cases).
Thanks for the great observation.. Could you perhaps give a link to the SuSE ftp site so I could see what the difference is (I assume they also have SRPMs).. I guess the exact revision numbers of the packages may also be helpful. Thanks!
Subject: Re: copy-and-paste file does not work for specific cases On Wednesday 19 March 2003 14:34, you wrote: > ------- Additional Comments From mo002j@mail.rochester.edu > 2003-03-19 07:34 ------- Thanks for the great observation.. Could you > perhaps give a link to the SuSE ftp site so I could see what the > difference is (I assume they also have SRPMs).. I guess the exact > revision numbers of the packages may also be helpful. > > Thanks! ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/supplementary/KDE/update_for_8.0 Currently the latest build for kdebase is kdebase3-3.1-74.
Subject: Re: copy-and-paste file does not work for specific cases With the release of kde 3.1.1 (binary for suse 8.0), copy/paste files from konq to desktop works, but not between konq from different processes.
I discussed this with a SuSE developer (Lubo? Lu?
*** Bug 56899 has been marked as a duplicate of this bug. ***
Subject: Re: copy-and-paste file does not work for specific cases On Monday 12 May 2003 22:03, you wrote: > ------- Additional Comments From mo002j@mail.rochester.edu > 2003-05-12 16:03 ------- I discussed this with a SuSE developer > (Lubo? Lu?
I have the same problem (case 2) with KDE 3.1.2 and I find this very annoying, it makes Konqueror completely useless for me. I am running this on Gentoo (1. 4r3)
I can reproduce comment #12 with KDE3.1.2, but it works fine with CVS HEAD.
Ahhhhhh. Seli: your revision 1.61 of libkonq/konq_dirpart.cc (switching the polling to check whether the format() is non-null instead of data) fixes it. Should it be backported, perhaps?
*** Bug 60973 has been marked as a duplicate of this bug. ***
revision 1.61 has been backported for KDE 3.1.3
*** Bug 61621 has been marked as a duplicate of this bug. ***
I have the same problem (case 2)under kde 3.1.3 on my Slackware Box.