Re: [kde] cannot cut/copy with dolphin
Kishore Jonnalagadda posted on Mon, 28 Oct 2013 17:36:40 +0530 as excerpted: > On Monday 28 Oct 2013 10:31:12 AM Duncan wrote: >> Kishore Jonnalagadda posted on Mon, 28 Oct 2013 14:06:53 +0530 as >> >> excerpted: >> > I can't be sure from when this problem occurs but its quite recent. >> > I'm on KDE 4.11.2 and i cannot cut or copy files in dolphin with >> > either the context menu or the CTRL+C and CTRL+V shortcuts. >> > When i try to cut a file, the file briefly becomes light shaded (like >> > it usually does when a file or folder is cut) but then restores >> > itself to the normal icon in about a second. When i click copy on any >> > file i do not get the paste option like i would expect it to. I do >> > notice that klipper updates the file path each time i try to cut or >> > copy. >> > >> > Do anybody know what could lead to this? >> >> That's a very interesting problem. I have little idea what this issue >> might be, but the fact that it exists for your normal user but NOT for >> a new user indicates it HAS to be something in your normal user's >> config. >> >> That means the problem should be resolvable by bisection. =:^) > Thanks Duncan! Indeed i followed a similar process and came down to > kdeconnect. kdeconnect allows your computer to pair with itself which is > strange! Pairing with itself was the source of the problem. I don't know > the technical reason behind it but i think it has to do with > kdeconnect's feature of sharing the clipboard. Indeed, I /did/ have not the foggiest idea what the issue was! I don't use software such as kdeconnect (I do use ssh in a text terminal occasionally, but I don't even use X forwarding with it), so wouldn't have guessed that for sure! But if it has a clipboard sharing mechanism, and the idea is to allow remote connects, then yes, it stands to reason that it'd disable file cut/ copy/paste across the shared clipboards, and if you're effectively connected to yourself, then yes, that'd probably disable it there, too! That's surely one for the archives! Who knows when someone else will post with the same issue, and I'll look like a genius posting a solution like this out of left field, if it actually happens to be their problem too (tho I'll be sure to say it's not original to me but came from a previous post to the list with the same problem, since I don't even use kdeconnect or the like)! So thanks for the followup, who knows when it'll come in handy, and /I'd/ surely not have thought of that on my own! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] cannot cut/copy with dolphin
On Monday 28 Oct 2013 10:31:12 AM Duncan wrote: > Kishore Jonnalagadda posted on Mon, 28 Oct 2013 14:06:53 +0530 as > > excerpted: > > I can't be sure from when this problem occurs but its quite recent. I'm > > on KDE 4.11.2 and i cannot cut or copy files in dolphin with either the > > context menu or the CTRL+C and CTRL+V shortcuts. > > > > I tried installing konqueror and the problem is the same in there. > > The problem does not exist for a new user that i create. > > Copy/Move by drag&drop operations works fine. > > > > When i try to cut a file, the file briefly becomes light shaded (like it > > usually does when a file or folder is cut) but then restores itself to > > the normal icon in about a second. When i click copy on any file i do > > not get the paste option like i would expect it to. I do notice that > > klipper updates the file path each time i try to cut or copy. > > > > Do anybody know what could lead to this? > > That's a very interesting problem. I have little idea what this issue > might be, but the fact that it exists for your normal user but NOT for a > new user indicates it HAS to be something in your normal user's config. > > That means the problem should be resolvable by bisection. =:^) The > general idea of bisection is to repeatedly test whether the problem is > there or not, cutting the test space (the number of config files in this > case) roughly in half each time, depending on the results of the previous > test. > > More specifically, nearly all of a user's kde config is found in the > $KDEHOME directory (normally ~/.kde, tho some distros will default that > to ~/.kde4 or some such), so your first test will be to verify that the > problem disappears if you start with a clean $KDEHOME. > > To do that, while either not running kde (perhaps from the text-mode > commandline) or while logged in as superuser so your user's kde config > isn't being used, rename the ~/.kde directory to something else, say > ~/.kde.backup. > > Then login to kde as that user and confirm that the problem no longer > exists. Assuming it doesn't, you've confirmed that the problem is in a > config file somewhere in your $KDEHOME directory. > > Next, within the $KDEHOME directory, pretty much all the config is in two > subdirs, $KDEHOME/share/config, and $KDEHOME/share/apps. Most of the > actual /config/ is in config (duh!), while apps is other application > data, so we'll guess it's in config and try the same process with it. > > Again without kde running as that user, delete the new test $KDEHOME dir > created by the test, and rename the backup copy back to its original name. > > Then navigate to $KDEHOME/share, and rename the config subdir to > something else, say config.backup. > > Again login as that user and check if the problem exists again or not. > > If it doesn't, you've now confirmed the problem is within the config > subdir; if the problem exists, it's NOT in the config subdir, so try apps. > > Now assuming it's in config, again without kde running as that user, blow > away the config subdir created by the test, and COPY the config dir from > the backup back in place. Then with the backup still in place to be > safe, cd into the the newly copied config dir (NOT the backup!), and > delete the few subdirs and about half the files. > > Repeat the login test. If the problem exists, then you know the problem > is in the half you did NOT delete. If the problem does NOT exist, it's > in the half you deleted. > > Repeat the process again, deleting the files created in the last test and > restoring all the files you now know are good, while testing half of the > half you know is bad. > > Continue repeating until you either isolate the problem to a single file, > or you're comfortable simply deleting the remaining bad configuration and > redoing it. > > Once you reach a single file, you can either stop there if you're > comfortable blowing it away and reconfiguring whatever configuration it > saved, or continue the process in that file by switching from a file > manager to a text editor for further testing, working first with sections > of the file and then with individual lines, until you either nail it down > to a single line and know where the problem is, or you decide you can > blow away the bad config that remains and reconfigure it by hand. > > The first couple times you do this, it's hard. After doing it a few > times, you'll start to get the hang of how kde organizes its > configuration, and for most problems you can shorten the process > considerably by choosing the correct configuration file (or at least the > handful of files with a common name, say the several plasma* files if > it's a plasma problem) the first time. > > Even here, you /could/ try dolphinrc and/or klipperrc right away, and > maybe you'll be right and one of them is the problem. But the trouble > is, this doesn't sound exactly like a klipper problem, and dolphin > doesn't have a whole lot of configu
Re: [kde] cannot cut/copy with dolphin
Kishore Jonnalagadda posted on Mon, 28 Oct 2013 14:06:53 +0530 as excerpted: > I can't be sure from when this problem occurs but its quite recent. I'm > on KDE 4.11.2 and i cannot cut or copy files in dolphin with either the > context menu or the CTRL+C and CTRL+V shortcuts. > > I tried installing konqueror and the problem is the same in there. > The problem does not exist for a new user that i create. > Copy/Move by drag&drop operations works fine. > > When i try to cut a file, the file briefly becomes light shaded (like it > usually does when a file or folder is cut) but then restores itself to > the normal icon in about a second. When i click copy on any file i do > not get the paste option like i would expect it to. I do notice that > klipper updates the file path each time i try to cut or copy. > > Do anybody know what could lead to this? That's a very interesting problem. I have little idea what this issue might be, but the fact that it exists for your normal user but NOT for a new user indicates it HAS to be something in your normal user's config. That means the problem should be resolvable by bisection. =:^) The general idea of bisection is to repeatedly test whether the problem is there or not, cutting the test space (the number of config files in this case) roughly in half each time, depending on the results of the previous test. More specifically, nearly all of a user's kde config is found in the $KDEHOME directory (normally ~/.kde, tho some distros will default that to ~/.kde4 or some such), so your first test will be to verify that the problem disappears if you start with a clean $KDEHOME. To do that, while either not running kde (perhaps from the text-mode commandline) or while logged in as superuser so your user's kde config isn't being used, rename the ~/.kde directory to something else, say ~/.kde.backup. Then login to kde as that user and confirm that the problem no longer exists. Assuming it doesn't, you've confirmed that the problem is in a config file somewhere in your $KDEHOME directory. Next, within the $KDEHOME directory, pretty much all the config is in two subdirs, $KDEHOME/share/config, and $KDEHOME/share/apps. Most of the actual /config/ is in config (duh!), while apps is other application data, so we'll guess it's in config and try the same process with it. Again without kde running as that user, delete the new test $KDEHOME dir created by the test, and rename the backup copy back to its original name. Then navigate to $KDEHOME/share, and rename the config subdir to something else, say config.backup. Again login as that user and check if the problem exists again or not. If it doesn't, you've now confirmed the problem is within the config subdir; if the problem exists, it's NOT in the config subdir, so try apps. Now assuming it's in config, again without kde running as that user, blow away the config subdir created by the test, and COPY the config dir from the backup back in place. Then with the backup still in place to be safe, cd into the the newly copied config dir (NOT the backup!), and delete the few subdirs and about half the files. Repeat the login test. If the problem exists, then you know the problem is in the half you did NOT delete. If the problem does NOT exist, it's in the half you deleted. Repeat the process again, deleting the files created in the last test and restoring all the files you now know are good, while testing half of the half you know is bad. Continue repeating until you either isolate the problem to a single file, or you're comfortable simply deleting the remaining bad configuration and redoing it. Once you reach a single file, you can either stop there if you're comfortable blowing it away and reconfiguring whatever configuration it saved, or continue the process in that file by switching from a file manager to a text editor for further testing, working first with sections of the file and then with individual lines, until you either nail it down to a single line and know where the problem is, or you decide you can blow away the bad config that remains and reconfigure it by hand. The first couple times you do this, it's hard. After doing it a few times, you'll start to get the hang of how kde organizes its configuration, and for most problems you can shorten the process considerably by choosing the correct configuration file (or at least the handful of files with a common name, say the several plasma* files if it's a plasma problem) the first time. Even here, you /could/ try dolphinrc and/or klipperrc right away, and maybe you'll be right and one of them is the problem. But the trouble is, this doesn't sound exactly like a klipper problem, and dolphin doesn't have a whole lot of configuration for the problem to hide in and nothing in its configuration that looks remotely related, so those files may or may not contain the problem, while our chances at finding the problem in $K
Re: [kde] cannot cut/copy with dolphin
On Monday 28 Oct 2013 2:06:53 PM Kishore Jonnalagadda wrote: > I can't be sure from when this problem occurs but its quite recent. I'm on > KDE 4.11.2 and i cannot cut or copy files in dolphin with either the > context menu or the CTRL+C and CTRL+V shortcuts. > > I tried installing konqueror and the problem is the same in there. > The problem does not exist for a new user that i create. > Copy/Move by drag&drop operations works fine. > > When i try to cut a file, the file briefly becomes light shaded (like it > usually does when a file or folder is cut) but then restores itself to the > normal icon in about a second. When i click copy on any file i do not get > the paste option like i would expect it to. I do notice that klipper > updates the file path each time i try to cut or copy. > > Do anybody know what could lead to this? I finally found the cause of this problem. It was related to kdeconnect! In the devices kcm of kdeconnect, your own PC is also listed as one of the available devices and it is possible to pair with it! It does not make sense but in my case my laptop was paired with itself and this was the source of the problem. Unpairing solved the problem! -- Cheers! Kishore ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
