Re: DnD vs CnP (was Copy/Paste Events)

Le 14-août-09 à 10:00, timeless a écrit :

> Paul Libbrecht< wrote:
>> - 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).
> this isn't true.
> depending on how friendly your drop target is, it theoretically could
> be true, but in practice many apps do not make it easy to understand
> precisely where you're dropping or precisely what effects a drop will
> have.

I should have said "drag and drop can allow a precise visual..."

This is the app responsability. I'm claiming there are many apps that  
do so.
The MacOSX Finder is definitely one of them, most Cocoa based text- 
editing apps do so as well, most picture processing programmes as well.

> sometimes your entire document is replaced by the thing you
> thought you were dragging. sometimes you get something you didn't
> think you were dragging.

that's when you can't identify the nature of things.
The story you are telling below is a simple confusion: the CD icon on  
the left of Finder windows is not the same as the on either the  
desktop or the "computer" view: if you drag out from these icons you  
do so as if you were dragging out of a dock which  has been much  
criticized, I know, it's just inaccomplished.

> Unfortunately, the concept isn't as simple as that, it turns out (and
> i finally understand it now [actually, i think i discover it ever
> couple of weeks and then promptly forget), then there's a difference
> between dragging the disk reference from the desktop to the trash and
> dragging the item from a finder window's tray to the trash. the former
> changes the trash to an eject icon and the latter doesn't. either way,
> when you drag a usb volume to the trash, the volume disappears from
> [....]
> Keep in mind that this drop target is supposedly *friendly* it tells
> me if it's actually going to eject by changing the icon of the target,
> and yet, i still don't manage to get it right most of the time
> (probably because my desktop is typically obscured, so i couldn't drag
> or see the volume on the desktop).

Apple has provided Exposé's "see desktop" to help you.

>
>> Copying, however, is simpler
>> and better understood as long as the selection model is clear.
>
> yesterday i was merging two documents using a third window (a browser)
> as a reference.
>
> mostly this meant a was copying an annotation ("# UNUSED") from
> old-document to new-document
> and copying an identifier from new-document to cross reference to
> verify whether the identifier was indeed unused.
>
> I did this by having the browser (Camino.app) as approximately full
> screen behind a text editor that supports multiple windows (XCode.app)
> with two windows side by side.

you describe this very well: you wish it was DnD because you don't  
want long-term storage but you cannot do it because it's using the  
keyboard: typically the keyboard is preferrable for selection and text  
navigation and is often better preferred by people that already  
keyboarding: hence Copy-and-paste is often understood as a keyboard  
bound thing while DnD is not: you can't specify the exact target  
(unless you are simulating it all).

> The process was basically:
> * in right editor window (new-document)
> 1. use the down arrow to move to the next identifier
> 2. use alt-right to select the identifier
> 3. use cmd-tab to switch to Camino
> * in Camino
> 4. double tap into the xref search field (this is about 10% down the
> screen and 10% to the right of the left edge)
> 5. use cmd-v to paste
> 6. use enter to start the search
> 7. use cmd-tab to switch back to XCode.app
> * in XCode
> 8. use cmd-` to switch to old-document
> 9. use cmd-c to copy "# UNUSED"
> 10. use cmd-` to switch to new-document
> 11. use cmd-left to go to the start of the line
> 12. use cmd-v to paste
> 13. loop
>
> In this process, i have two things which have to be in my "clipboard",
> obviously neither is in my clipboard as "long term storage", it's in
> fact merely drag and drop, but the coordinates of my drag source and
> drag targets are too disparate for me to use a mouse for most of them
> (and if i was really a keyboard user, i might have arranged it so that
> i could use a keyboard to focus the search field in the browser, or
> used the urlbar. I'm a power user, not a keyboard user, so i used the
> mouse for this step.
>
> the fact is that this process is really drag and dropping between
> three windows, i'm only using the keyboard because it's expensive to
> retarget and focus each of these areas.
>
>> - 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.
>
> That's a clipbook, not a clipboard. Most clipboards do not survive
> restarts, heck half the time they don't survive apps quiting.

I am sorry that's not true: a system clipboard is filled independently  
of the application.
See here:
   http://developer.apple.com/documentation/Cocoa/Conceptual/CopyandPaste/Articles/pbFundamentals.html#/ 
/apple_ref/doc/uid/TP40004254

Many applications have internal clipboards, which allows a no-loss, no- 
duplication copy-and-paste but when leaving the application you have  
to export these.

>> - 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.
>
> I don't understand this.

In java at least, a dragEnd allows the drag-receiver to only pull one  
flavour.
I know of no framework that explicitly allow pulling several flavours  
from a DnD transfer while the system clipboard trivially does (because  
you can re-pull it).

>> 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.
>
> Insisting isn't how we do things here. Provide use cases, provide
> explanations, try to convince with real data.

I agree and I wanted to make videos to more convince but I just did  
not manage.

paul