Version: 1.6.1 (using KDE 3.2.1, compiled sources) Compiler: gcc version 2.95.4 20020320 [FreeBSD] OS: FreeBSD (i386) release 4.9-STABLE Reproducible test case: 1) Compose a new message 2) Insert one address in the 'To:' field 3) Insert one address in the 'CC:' field 4) Select the address in the 'CC:' field 5) Drag it to the 'To:' field and drop it there Actual behaviour: - Email address is copied from 'CC:' field to 'To:' field - Email address remains in 'CC:' field Expected behaviour: - Email address is moved from 'CC:' field to 'To:' field, since it has no use to have an address in both the 'CC:' and the 'To:' fields Alternatively, KMail could show a dialog [ Move here | Copy here | Cancel ] like it does when dragging messages from one folder to another.
This is indeed still a problem in 3.2.2. I think it would be much better to have by default the DND action move the address, but I don't think it should open a menu - if you really want to copy the address then use the CTRL+DND, like in konqueror (and actually everywhere else - MS-Outlook composer works like that as well).
I can confirm this is still the case in the development version of KMail.
In KDE 3.4 it will be very easy to change an address from "to" to "cc" by selecting it in a dropdown box next to the address. That makes this bug resolved.
Thanks for the change - I understand that this was done to mimic the interface of Mozilla family of mail user agents ? While I do not think highly of that type of interface (I think it only adds to user confusion), I understand that many people like it and I won't mind much seeing it in KMail (though I would appreciate the ability to turn it off and go back to the "old style" UI). Nonetheless I do not think this is a valid resolution of the current bug. To iterate: the current behavior is broken in that when you select an address in one of the address bar and drags it to one of the other address bars, a drag cursor is used. when dragged with the CTRL key held, a drag cursor with a "+" sign is used. the naive user would then expect that dragging w/ CTRL will copy the address while dragging w/o will move the address - like it is done in virtually ALL other software that allows dragging, be it file managers, email clients, database front-ends, paint programs, you name it. Much to the user's surprise either drag action completes by copying the address. The main issue here, I believe is user surprise and frustration. One way to solve it is to use the "copy drag cursor" even when the user does not hold the CTRL down thereby notifying the user that any drag action will result in a copying the address. I personally - and so I believe would the original reporter - would have preferred that the resolution would be to allow "move" actions. Either way - allowing "move" by radically modifying the interface does not nullify the current bug unless dragging of addresses has now been completely disabled. As I am not the reporter and have no permissions on KDE bugzilla, I cannot change back this bug's status but I encourage Ernst to do so. P.S. Suppose for a minute that the above mentioned change has indeed "resolved" this bug report by revoking it relevancy. In such a case I would hardly say that this mandates a "FIXED" status for the bug - more likely it should be set to "INVALID" or "WONTFIX".
Op Tuesday 1 February 2005 19:32, schreef Oded Arbel: > While I do not think highly of that type of interface (I think it only adds > to user confusion), I understand that many people like it and I won't mind > much seeing it in KMail (though I would appreciate the ability to turn it > off and go back to the "old style" UI). I don't think we will ever have a solution which everyboddy is happy with. I do think that the majority of people prefer this layout above the old one. > Nonetheless I do not think this is a valid resolution of the current bug. > To iterate: the current behavior is broken in that when you select an > address in one of the address bar and drags it to one of the other address > bars, a drag cursor is used. when dragged with the CTRL key held, a drag > cursor with a "+" sign is used. the naive user would then expect that > dragging w/ CTRL will copy the address while dragging w/o will move the > address - like it is done in virtually ALL other software that allows > dragging, be it file managers, email clients, database front-ends, paint > programs, you name it. Much to the user's surprise either drag action > completes by copying the address. Ok. I reopen, you are right, dragging should move the address and shift-dragging should copy the address, if dragging is allowed. > P.S. > Suppose for a minute that the above mentioned change has indeed "resolved" > this bug report by revoking it relevancy. In such a case I would hardly say > that this mandates a "FIXED" status for the bug - more likely it should be > set to "INVALID" or "WONTFIX". It is neither invalid (it does not work as the user describes) or wontfix (we don't want to implement it). It is more 'obsolete' or something, but that does not exist. That is why fixed is better (in the end, the problem does not exist anymore and we did something to do that).
In Qt4/KDE4 it is not possible anymore to drag text from a {Q/K}LineEdit. Should we close this bug?
So it would seem. While personally I think that preventing drag and drop entirely is not an improvement over the previous interface, having established that KMail's address interface is completely different then the classic outlook/evolution one - and it works (to some extent - I still think it is less usable), then this bug report is indeed no longer relevant, i.e. obsolete or bugs.kde.org lacking that status - fixed.
OK, marking as FIXED.