When dragging and dropping elements, there is typically a 2-3 second delay before dragging actually starts. Examples include moving an email in KMail or a file in Dolphin. The icon will not start following mouse movements (and the cursor icon will not be updated) until 2-3 seconds after dragging started. Reproducible: Always Steps to Reproduce: 1. ssh to a remote host 2. start Dolphin 3. start dragging a file: the cursor icon does not change and the file icon does not start following the pointer until after 2-3 seconds 4. pause (but do not drop) over a folder 5. start moving again: the same delay can be observed again Actual Results: Dragging does not actually start until 2-3 seconds after the action was initiated. Expected Results: Drag and drop should happen as quickly as any other ui action (taking into account network latencies, of course). As it stands, drag and drop is essentially unusable, to the point that I have had to find workarounds, such as using the 'Move to' context menu item. Thank you for the wonderful work on KDE.
Thanks for the report. I see that it has been assigned to Dolphin now, even though you say that it happens in all KDE applications. Do I understand correctly that you "ssh -X" to a remote host and then expect everything to work as fast as on your local machine? Note that drawing the "drag&drop" mouse cursor is done by the app on the remote host AFAIK, so this should IMHO be expected to be slow. I don't know if the correct resolution is INVALID, WONTFIX or something else, but I don't have the slightest clue what we could do inside Dolphin to "fix" this problem.
(In reply to comment #1) > Thanks for the report. I see that it has been assigned to Dolphin now, even > though you say that it happens in all KDE applications. This issue is not specific to Dolphin (KMail has the a similar problem), which is why I submitted the bug in the 'general' category. However, I performed additional tests and found out that not all applications seem to have the same problem. For instance, for whatever reason drag&drop from Dolphin to Rekonq is terribly slow, but drag&drop from Rekonq to Dolphin is fast. > Do I understand correctly that you "ssh -X" to a remote host Yes... > and then expect > everything to work as fast as on your local machine? ... of course not ;o) I expect drag and drop to work only as fast as the rest of the interface of the remote application (which is why is wrote 'taking into account network latencies, of course'). > Note that drawing the > "drag&drop" mouse cursor is done by the app on the remote host AFAIK, so > this should IMHO be expected to be slow. I agree that the whole interface is expected to respond slightly slower than that of local applications. As a matter of fact, in my setup the network latency is unnoticeable for most operations, e.g. opening a menu or bringing up a dialog. Even watching videos is really fast. Only drag&drop seems to cause disproportionately long delays. > I don't know if the correct resolution is INVALID, WONTFIX or something > else, but I don't have the slightest clue what we could do inside Dolphin to > "fix" this problem. It is difficult for me to answer this question, but why don't you give it a try? connect to a remote host and try moving files in Dolphin, you will immediately see what I mean.
(In reply to comment #2) > For instance, for whatever reason drag&drop from > Dolphin to Rekonq is terribly slow, but drag&drop from Rekonq to Dolphin is > fast. Could be because Dolphin draws small pixmaps for the dragged files next to the cursor. Maybe sending these through X and updating them repeatedly is the slow thing, I don't know. > It is difficult for me to answer this question, but why don't you give it a > try? connect to a remote host and try moving files in Dolphin, you will > immediately see what I mean. Yes maybe, but then debugging it will be a *very* time consuming process, and probably I would find out that there is just no straightforward way to fix this. Considering how many open bug reports we have and how many people have been bothered by the "slow drag over ssh" issue so far, I think that this is not the best investment of my free time, sorry. And moreover, if this really affects many applications, I cannot believe that it's Dolphin's fault. Maybe something in Qt doesn't work right in this use case, or maybe the slowness when dragging and drawing pixmaps is just unfixable.
> Could be because Dolphin draws small pixmaps for the dragged files next to > the cursor. Maybe sending these through X and updating them repeatedly is > the slow thing, I don't know. I am not sure this is the case. We have quite a number of workstations and servers here, and I have just tested a few configurations: * Dolphin 0.9.2 on KDE 3.5.10 - FAST * Dolphin 1.5 on KDE 4.5.3 - FAST * Dolphin 1.7 on KDE 4.7.4 - FAST * Dolphin 2.0 on KDE 4.8.2 - FAST * Dolphin 2.2 on KDE 4.10.0 - SLOW * Dolphin 2.2 on KDE 4.10.3 - SLOW I was under the impression that this was a rather recent problem. The above confirms this. > And moreover, if this really affects many applications, I cannot believe > that it's Dolphin's fault. I agree (remember I submitted the bug under the 'general' category). > Maybe something in Qt doesn't work right in this > use case, or maybe the slowness when dragging and drawing pixmaps is just > unfixable. I have just installed and played around with qtcreator. Drag&drop seems to work fine (even when there is an associated pixmap). Wouldn't this suggest a problem with KDE4.10?
Thanks for the detailed information! > Wouldn't this suggest a problem with KDE4.10? Hm, if it's indeed fast in all applications (like Dolphin, KMail, etc.) in KDE 4.8.2 and slow in all applications in KDE 4.10.0, then this could be a possibility. However, I guess that there are also different versions of Qt, X, and other libs on these machines, so it's hard to tell. Moreover, one cannot exclude the possibility that both Dolphin and KMail have changed something important in this respect between 4.8.2 and 4.10.0 (but this is unlikely if there are even more KDE apps that have the same problem only in the more recent version). The most reliable way to test would probably be to build "old" versions on the "new" machines and see if that fixes the problem. If kdelibs-devel 4.10.x packages are installed, compiling and installing an older Dolphin version on top of that would be quite straightforward (I'll try to give instructions for that if you're interested). But if that does not fix the problem, downgrading kdelibs and then Qt would be the next steps, which require a bit more work.
Given all of the above, can you maybe reassign the bug to a more general category?
I'm afraid 'kde' might be the most general category we have ;-)
> I'm afraid 'kde' might be the most general category we have ;-) Sorry, from comment #1 I had understood (erroneously, it seems) that the bug had been somehow assigned to Dolphin. Unfortunately, my research duties do not leave me enough time to perform your suggested builds and tests. Hopefully, now that I have reported this bug, it may ring the bell for someone - whoever changed something related to drag&drop around KDE4.10... Could you perhaps reproduce it and change its status to 'confirmed' so that it potentially gets more attention? We do use networked computers quite extensively in our lab, and this would be a very welcome fix. Thanks!
(In reply to comment #8) > > I'm afraid 'kde' might be the most general category we have ;-) > > Sorry, from comment #1 I had understood (erroneously, it seems) that the bug > had been somehow assigned to Dolphin. It was, but I assigned it back, see https://bugs.kde.org/show_activity.cgi?id=320756 > Unfortunately, my research duties do not leave me enough time to perform > your suggested builds and tests. Hopefully, now that I have reported this > bug, it may ring the bell for someone - whoever changed something related to > drag&drop around KDE4.10... As I said, it's not even clear that it has anything to do with KDE at all. Moreover, there are not really many people who go through all incoming bug reports, so I'm not sure how likely it is that anyone will look into this issue (if there really is an issue that we could reproduce and debug, see below). > Could you perhaps reproduce it and change its > status to 'confirmed' so that it potentially gets more attention? We do use > networked computers quite extensively in our lab, and this would be a very > welcome fix. Thanks! I just tried it, and I cannot confirm the problem (both local and remote system running Opensuse 12.3, KDE 4.10.3), Qt 4.8.4. Everything is a bit slower than when working locally, but a 2 second delay does definitely not occur. Note that you can actually use a local Dolphin instance to manage remote files over ssh - just enter fish://username@remote.machine.org in the location bar.
This worked for Frank, and was reported against an old version. Please reopen if it's still happening.