Re: DnD vs CnP (was Copy/Paste Events)
On Thu, 3 Sep 2009, Paul Libbrecht wrote: > > Which of them supports to transfer arbitrary flavours? > Generic image formats along of markup? I do not recall off-hand. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: DnD vs CnP (was Copy/Paste Events)
Which of them supports to transfer arbitrary flavours? Generic image formats along of markup? thanks in advance paul Le 03-sept.-09 à 15:00, Ian Hickson a écrit : Currently, Safari and IE support this API to some extent in their respective shipping products, and Firefox either supports it in the shipping version or in the next version, I don't recall (it's in the nightlies, either way). smime.p7s Description: S/MIME cryptographic signature
Re: DnD vs CnP (was Copy/Paste Events)
On Mon, 31 Aug 2009, Paul Libbrecht wrote: > Le 31-ao�t-09 � 04:44, Ian Hickson a �crit : > > > > Honestly, I find the whole DnD and CnP treatment in HTML5 quite much > > > ad-hoc. It's welcome to have such an addition but it makes too many > > > arrangements and still is hard to read. > > > > Yes, it's a horrible model. It's one that had been implemented > > multiple times before the spec existed, and implementations trump > > pretty much everything except security problems when it comes to > > deciding what the spec should say. > > could I request a pointer to implementations or, even better, test-cases > ? This is where I'd like my test cases to be: http://hixie.ch/tests/adhoc/dom/web-apps/drag-and-drop/ ...but I have very few so far. Currently, Safari and IE support this API to some extent in their respective shipping products, and Firefox either supports it in the shipping version or in the next version, I don't recall (it's in the nightlies, either way). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: DnD vs CnP (was Copy/Paste Events)
Le 31-août-09 à 04:44, Ian Hickson a écrit : Honestly, I find the whole DnD and CnP treatment in HTML5 quite much ad-hoc. It's welcome to have such an addition but it makes too many arrangements and still is hard to read. Yes, it's a horrible model. It's one that had been implemented multiple times before the spec existed, and implementations trump pretty much everything except security problems when it comes to deciding what the spec should say. could I request a pointer to implementations or, even better, test- cases ? Maybe they could encourage or disappoint server implementors. If it's what I know of MSIE then it will discourage us. (as far as I recall: unstable because of lack of complete security, only three flavours) paul smime.p7s Description: S/MIME cryptographic signature
Re: DnD vs CnP (was Copy/Paste Events)
On Sat, 22 Aug 2009, Paul Libbrecht wrote: > Le 22-ao�t-09 � 07:51, Ian Hickson a �crit : > > > > > > 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 can also be for long-term storage -- drag whatever it is > > you were going to copy to your clipboard to your clipboard > > erm... can you give me the pixel coordinates of my clipboard please? It's wherever your clipboard program's window is. > > ... same result. And with the DND model in HTML5, you have to "write > > all the flavours you think a recipient would ever make use of" in the > > same way as you describe for copy-and-paste. > > To me, as a server implementor, this is a problem: I will not offer any > expensive type for DnD then, while I could offer them if I knew the > target wishes to get, say, a PDF of the formula that was just dragged. I agree that this is a problem; we can fix it in a future version. Note that copy-and-paste doesn't mean generating everything at copy time either. Just like with drag-and-drop, you could easily model copy-and- paste as a promise model. > > DND in HTML5 generates the data at drag time, not drop time. > > Well, this is the choice of HTML 5 I am debating, precisely. It all > comes (consistently) together as a problem. We don't really have much choice over what the API is -- it's whatever IE implemented about 10 years ago. We can add more features, but we should wait until we have good interop with this version first. > > > 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. > > > > I see no reason to split them. > > Maybe a reasonable approach would be to have on "simplified" API that > corresponds to this one which merges the two while a finer grained API > would differentiate them? I see no benefit to differentiating the two. On Thu, 27 Aug 2009, Paul Libbrecht wrote: > > While re-reading the spec: > > http://dev.w3.org/html5/spec/Overview.html#drag-and-drop-processing-model > I seem to understand that "supply data immediately" is the alternative > proposed currently by HTML5. Right? Yes. > If yes, then it's clear that most server-implementors will not be able > to offer rich flavours as possible conversion targets since you don't > want to wait on a network load for a drag-start to fire! Correct. > Honestly, I find the whole DnD and CnP treatment in HTML5 quite much > ad-hoc. It's welcome to have such an addition but it makes too many > arrangements and still is hard to read. Yes, it's a horrible model. It's one that had been implemented multiple times before the spec existed, and implementations trump pretty much everything except security problems when it comes to deciding what the spec should say. > What I would wish, and I think many many many others is a readable > specification for copy-and-paste that meets large implementations and > maybe later something for drag-and-drop. I agree that the drag-and-drop spec should be easier to read. I'm hoping that maybe Lachlan's authoring document will include help on how to use the API. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: DnD vs CnP (was Copy/Paste Events)
>
> I seem to understand that "supply data immediately" is the alternative
> proposed currently by HTML5. Right?
It has been proposed that a "DownloadURL" alternative be added to the list
of types to create downloadable files.
http://www.mail-archive.com/wha...@lists.whatwg.org/msg17210.html
The problem with this is that you can't specify mime type for the file
content. I also suggested that the file API be extensible but this is too
messy.
Instead you could add a method such as: dataTransfer.setRemoteData(mimeType,
url);
Or as a type decorator: dataTransfer.setData("remote: " + mimeType, url);
Then you could declare any data to be loaded lazily from a remote server
when a drop operation occurs. Dragging of file data to a file manager would
cause the file on the specified URL to be downloaded to the target folder.
On Thu, Aug 27, 2009 at 12:20 AM, Paul Libbrecht wrote:
> While re-reading the spec:
>
> http://dev.w3.org/html5/spec/Overview.html#drag-and-drop-processing-model
> I seem to understand that "supply data immediately" is the alternative
> proposed currently by HTML5. Right?
>
> If yes, then it's clear that most server-implementors will not be able to
> offer rich flavours as possible conversion targets since you don't want to
> wait on a network load for a drag-start to fire!
>
> Honestly, I find the whole DnD and CnP treatment in HTML5 quite much
> ad-hoc. It's welcome to have such an addition but it makes too many
> arrangements and still is hard to read.
>
> What I would wish, and I think many many many others is a readable
> specification for copy-and-paste that meets large implementations and maybe
> later something for drag-and-drop.
>
> paul
>
>
> Thanks for the pointers. We now have more words: supply data on demand or
>> supply data immediately is the crucial difference.
>>
>> The on-demand situation means: the application still must live for its
>> on-demand flavours to be available.
>>
>> We're now porting it all to a web-browser: an application is a web-page, a
>> document that is. So on-demand copy-and-paste would stop being available as
>> soon the document is gone, i.e., as soon as the page is changed following a
>> link or a back, right?
>>
>> I would feel bothered as a user.
>>
>
>
Re: DnD vs CnP (was Copy/Paste Events)
While re-reading the spec: http://dev.w3.org/html5/spec/Overview.html#drag-and-drop-processing-model I seem to understand that "supply data immediately" is the alternative proposed currently by HTML5. Right? If yes, then it's clear that most server-implementors will not be able to offer rich flavours as possible conversion targets since you don't want to wait on a network load for a drag-start to fire! Honestly, I find the whole DnD and CnP treatment in HTML5 quite much ad-hoc. It's welcome to have such an addition but it makes too many arrangements and still is hard to read. What I would wish, and I think many many many others is a readable specification for copy-and-paste that meets large implementations and maybe later something for drag-and-drop. paul Thanks for the pointers. We now have more words: supply data on demand or supply data immediately is the crucial difference. The on-demand situation means: the application still must live for its on-demand flavours to be available. We're now porting it all to a web-browser: an application is a web- page, a document that is. So on-demand copy-and-paste would stop being available as soon the document is gone, i.e., as soon as the page is changed following a link or a back, right? I would feel bothered as a user. smime.p7s Description: S/MIME cryptographic signature
Re: DnD vs CnP (was Copy/Paste Events)
timeless, So, erm, your conclusion should be we follow MicroSoft Windows copy- and-paste? I still find that the immediate-clipboard-data-delivery is a safer mechanism. It's funny to fall on such a dichotomy! Le 23-août-09 à 15:47, timeless a écrit : http://msdn.microsoft.com/en-us/library/f427xyk8(loband).aspx With the advent of OLE, there are two Clipboard mechanisms in Windows. The standard Windows Clipboard API is still available, but it has been [...] Note that Windows really does lump clipboard and drag and drop together. Wasn't it a person of MicroSoft that started that thread? Thanks for the pointers. We now have more words: supply data on demand or supply data immediately is the crucial difference. The on-demand situation means: the application still must live for its on-demand flavours to be available. We're now porting it all to a web-browser: an application is a web- page, a document that is. So on-demand copy-and-paste would stop being available as soon the document is gone, i.e., as soon as the page is changed following a link or a back, right? I would feel bothered as a user. paul On Sun, Aug 23, 2009 at 12:11 AM, Paul Libbrecht wrote: I am sorry that's not true: a system clipboard is filled independently of the application. No, I'm sorry you're unaware of how other operating systems work. See here: http://developer.apple.com/documentation/Cocoa/Conceptual/CopyandPaste/Articles/pbFundamentals.html#/ /apple_ref/doc/uid/TP40004254 http://msdn.microsoft.com/en-us/library/9s5z33c4(loband).aspx How data is inserted into a data source depends on whether the data is supplied immediately or on demand, and in which medium it is supplied. The possibilities are as follows. Supplying Data on Demand (Delayed Rendering) In the Data on Demand/Delayed Rendering case, the data does not survive app death (unless the app chooses to force the data onto the clipboard immediately before death). smime.p7s Description: S/MIME cryptographic signature
Re: DnD vs CnP (was Copy/Paste Events)
http://msdn.microsoft.com/en-us/library/f427xyk8(loband).aspx With the advent of OLE, there are two Clipboard mechanisms in Windows. The standard Windows Clipboard API is still available, but it has been supplemented with the OLE data transfer mechanism. OLE uniform data transfer (UDT) supports Cut, Copy, and Paste with the Clipboard and drag and drop. Note that Windows really does lump clipboard and drag and drop together. On Sun, Aug 23, 2009 at 12:11 AM, Paul Libbrecht wrote: > I am sorry that's not true: a system clipboard is filled independently of > the application. No, I'm sorry you're unaware of how other operating systems work. > See here: > http://developer.apple.com/documentation/Cocoa/Conceptual/CopyandPaste/Articles/pbFundamentals.html#//apple_ref/doc/uid/TP40004254 http://msdn.microsoft.com/en-us/library/9s5z33c4(loband).aspx How data is inserted into a data source depends on whether the data is supplied immediately or on demand, and in which medium it is supplied. The possibilities are as follows. Supplying Data on Demand (Delayed Rendering) In the Data on Demand/Delayed Rendering case, the data does not survive app death (unless the app chooses to force the data onto the clipboard immediately before death).
Re: DnD vs CnP (was Copy/Paste Events)
Le 22-août-09 à 07:51, Ian Hickson a écrit : 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 can also be for long-term storage -- drag whatever it is you were going to copy to your clipboard to your clipboard erm... can you give me the pixel coordinates of my clipboard please? ... same result. And with the DND model in HTML5, you have to "write all the flavours you think a recipient would ever make use of" in the same way as you describe for copy-and-paste. To me, as a server implementor, this is a problem: I will not offer any expensive type for DnD then, while I could offer them if I knew the target wishes to get, say, a PDF of the formula that was just dragged. DND in HTML5 generates the data at drag time, not drop time. Well, this is the choice of HTML 5 I am debating, precisely. It all comes (consistently) together as a problem. 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. I see no reason to split them. Maybe a reasonable approach would be to have on "simplified" API that corresponds to this one which merges the two while a finer grained API would differentiate them? paul smime.p7s Description: S/MIME cryptographic signature
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/Co
Re: DnD vs CnP (was Copy/Paste Events)
On Thu, 13 Aug 2009, Paul Libbrecht wrote: > > > > 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 > > with the 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. I agree that the UI is different. But that doesn't mean that they're not the same operation. Double clicking on an application icon and running the application from the command line are also the same operation with different UI. It's all the same. > - 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 can also be for long-term storage -- drag whatever it is you were going to copy to your clipboard to your clipboard... same result. And with the DND model in HTML5, you have to "write all the flavours you think a recipient would ever make use of" in the same way as you describe for copy-and-paste. > - 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. DND in HTML5 generates the data at drag time, not drop time. > 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. I see no reason to split them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: DnD vs CnP (was Copy/Paste Events)
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. 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.
I have a mac book, and sometimes when I want to eject my usb media, i
try to drag it to the trash, because this is one way to eject disks.
http://everything2.com/title/Dragging+a+disk+to+the+trash+to+eject+it+on+a+Macintosh
talks about it a bit.
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
the finder window. except if you dragged it from the desktop you've
safely unmounted it, and if you drag it from the finder window, you've
just removed the entry from the finder window. There's almost enough
feedback, but as it happens, i've now safely unmounted my phone half a
dozen times this week because i can't remember how to use apple's drag
and drop metaphor.
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).
> 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.
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.
> - 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.
> 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.
Hopefully my example is compelling,.
Re: DnD vs CnP (was Copy/Paste Events)
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 with the 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
