Version: (using KDE 3.5.8KDE 1.2) OS: Linux Select several large files residing on one disk, press Ctrl-X, focus another Konqueror window, press Ctrl-V. Sometimes the paste operation (Ctrl-V) is repeated again right away. So I get 2 file transfer dialogs AT THE SAME TIME, both copying from & to same locations! Second dialog prompts about overwriting the partial file created by 1st Move dialog!! I use bluetooth keyboard. I also use konsole a lot and never noticed characters duplicating.
You've keep the "CTRL+V" pressed to much long, I've reproduced on 3.5.9. Anyway this is not a good behaviour: the paste action should be triggered only one time, and not repeated. The same bug exist even on KDE4 (in the dolphin part)
I do not use KDE4, do you mind logging the bug there as well?
Alex: You don't have to put bugs for 3 and 4 in twice. :) Developers worth on both, and they will see the bug here, fix it in 4 first, and if feasible, backport it to 3.5.
work, not worth... :P
I can reproduce it here with kde 3.5.9. Steps that I use to reproduce the bug: 1 - Select one file (one is sufficient) in konqueror 2 - Press Ctrl+C 3 - Change to another directory 4 - Press and hold Ctrl+V I have hold for a few seconds and several dialogs appear.
If you hold any key for a longer delay, autorepeating is started and the keys are posted to the application periodically. In your case Ctrl+V is posted N times and the application (in this case Dolphin/Konqueror) just executes the corresponding action N times that is associated with this shortcut. This is valid for all KDE applications and all keys (including Ctrl + ... shortcuts). If your autorepeat setting is too fast, I'd suggest adjusting the delay to a higher value inside System Settings.
Peter, you are correct technically, but from useability point of view, this is absurd behaviour. Copy or move op should be a blocking op for that window. Just like it is on other OSs/GUIs.
> Peter, you are correct technically, but from useability point of view, > this is absurd behaviour. I agree that that the autorepeat functionality for some shortcuts might not make sense or are even counter productive. But generally turning off the autorepeat functionality might be wrong too and other Oss/GUIs don't do this too: > Copy or move op should be a blocking op for that window. > Just like it is on other OSs/GUIs. I just verified this with Windows XP + Windows 2000: for all shortcuts the autorepeat behavior is turned on. Usecase where this also makes sense: Copy a text template inside an editor by Ctrl+C and paste it repeatedly by staying on Ctrl+V. My point of view to this issue: we're making a problem where no problem exists. I guess the root of the issue above is a too short set autorepeat delay that gets a problem if the system is blocked for e. g. a short period where the autorepeat timer gets triggered. But I'll jump out of this discussion now, as technically the problem must be solved on kdelibs level and not on applications level. I personally see no way how on a global level we should define where autorepeat makes sense: e. g. autorepeat for Ctrl+V might make sense for some people inside editors, but it is not wanted in this bug-report for file managers... To stress this issue a little bit more: if Dolphin/Konqueror would automatically rename an item when pasting it into the same directory, then suddenly autorepeat for Ctrl+V might make sense too: e. g. copy a template file 30 times into a directory by Ctrl+C on the template file and staying on Ctrl+V. Sure: a quite constructed use case, I just wanted to show that the usability question here is not black and white and that what this bug report sees as bug might be a regression for other people in other use cases. OK, I'm jumping out of this discussion as I cannot do something technically to fix this :-)
What says Peter is correct. I've forgot that from the system settings (or kcontrol) you can disable or adjust this behaviour, so if someone needs he can configure his settings without any problem. Actually I don't have this needings :-)
I checked on winxp and indeed, it doesnt block. Terrible software quality. I'm pretty sure older version of Windows used to block. Anyway, auto repeat is useful and shouldnt be circuimvented on the kdelibs level. Rather, konqueror should do the blocking.
Just wanted to add - konq shows fool-proof confirmation dialog when somebody tries to delete file. This "non-blocking" issue falls along the same lines of useability - dont let the user screw up too easily.
@Alex: > I'm pretty sure older version of Windows used to block. I've tested it with Windows 2000: it does not block too...
> I've tested it with Windows 2000: it does not block too... Same with Windows Vista, it also doesn't block. Actually, I can't remember any version of Windows that did block this. If there really was one, it must have been long ago. Indeed, it would be counter-intuitive: Every keyboard input normally does autorepeat, including all keyboard shortcuts. So why should one specific keyboard shortcut be blocked if one specific application has the input focus? I don't think this would be a logical behaviour. So I think the current status is fine as it is, if someone has the autorepeat set to a too low delay, this is the problem that he/she should fix (by setting a higher delay). Everything else seems to be just fine as it is.
This is the point of the open source software. We are not cloning Windows. We are building the perfect system. It is unnecessary to verify if Windows or any other system or GUI has the same issue. I think that all agree that it is a usability bug. It is not what the user expects. Maybe some disagree if we should fix it as the others has this issue too. What Peter Penz says about copying a template file is worth to consider and implement, although only a small percent of users will sometime use it. I suggest that kdelibs should have a handler of shortcuts that catches the ctrl+v and ctrl+c (maybe others) and signals the repetition to application. The application will decide what it will do with the repetition. If it is a text editor, it will do a repetitive copy. If it is a file manager, it will block it or shows a window telling the user about the repetitive action and asking what to do (block or do a repetitive copy). The window should ask how many copies to avoid the repetitive action. This behaviour should be configurable. Maybe the repetitive copy using shortcuts should be avoided and a little tool integrated with konqueror/dolphin should handle this task. I think this is great. If correctly implemented, we will be ahead of anyone. The bug that all others have, even the MacOSX. It is worth to consider.
Message from the Bugsquad and Konqueror teams: This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore. If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report. Thank you for your understanding.