Le 13-août-09 à 13:34, Ian Hickson a écrit :
So I'm saying is that, regardless of whether you use voice, keyboard, touch or mouse... There are two distinct concepts at play here.I disagree. The drag and drop model allows the user to drag to the clipboard and paste from the clipboard. This is exactly what copy-and-paste simulates. I don't see why this is a problem. If the drag-and- drop code doesn't support dragging to another app, then that's a problem withthe drag-and-drop code, and providing a second API to work around that problem just for copy-and-paste doesn't help the people using the drag-and-drop feature in that fashion
To me it is a problem to confuse the two operations:- drag and drop allows a precise visual target identification thus may be considered safer (and this is actually implemented so: you can faster drag-and-drop URLs than copy and paste them). Copying, however, is simpler and better understood as long as the selection model is clear.
- copy-and-paste is aimed at long term storage: if you write to the clipboard you have to write all the flavours you think a recipient would ever make use of! The clipboard often survives computer-restarts.
- drag-and-drop is aimed at direct negotiations: generally, only at the end of the drag is the actual data produced. In case this is running over a network-based conversion this is significant I feel.
So I would insist to split the two set of events while keeping common, of course, some of the interfaces to denote what can be transferred.
paul
smime.p7s
Description: S/MIME cryptographic signature
