I think this makes a lot of sense. Nice work Nigel (and Noel!).
One comment regarding API future-proofing:
> Some final, miscellaneous points regarding the current implementation:
> dropping a directory will be rejected, since Gears doesn't really have
> a good representation for a directory at the moment. Dropping Windows
> shortcuts (i.e. .lnk files,or alias files, on the Mac) will be
> followed, so that dropping a shortcut to an .avi file onto a YouTube
> upload page will upload the actual movie file, not the 400 or so bytes
> for a .lnk file.
> ...
> The context is a JavaScript object with named properties. For example,
> during ondrop (but not during ondragenter, ondragover or ondragleave),
> context.files will contain an array of File objects, exactly like the
> array of Files returned by desktop.openFiles. Another property is
For future extensibility, it might be best not to assume files. You
mentioned dragging directories. I suspect there are other things
people may want to drag/drop over time?
Something more generic like 'context.data' might work. Here's just
one idea for how it could work:
* .data is of type DropData
* DropData contains a
- String field describing the type
- BlobContainer object, which just guarantees it has a .blob property
This way, any object that has a .blob field (including File) could be
placed there. And code could still do some things with future types
it didn't fully understand. [Yes, I realize File may need to be
extended slightly to make the JS details work out.]
Does the general idea make sense?
