[squeak-dev] DropPlugin usage questions
bert at freudenbergs.de
Fri Apr 11 14:18:22 UTC 2014
On 10.04.2014, at 17:57, tim Rowledge <tim at rowledge.org> wrote:
> I’ve just had to fix up some code that handled file drops. Since it was easy to mooch off the code in PasteUpMorph, that’s what I did - but I’m wondering what the reason is for the rather convoluted code in StandardFileStream class>requestDropStream:
> So far as I can tell the DropPlugin code provides a string representing the dropped file (along with the event carrying the number of files dropped etc) and then we immediately ask the plugin for an actual file handle. It’s a bit hard to see why the plugin needs to do that since we can open a file easily enough in other ways. I can see from the *nix and Mac OS code that they are just opening files ‘normally’ (and I agree with Ian’s comment /* you cannot be serious? */ by the way). The win32 code is less intelligible but seems to be doing much the same. Does anyone remember why we ended up going to this trouble to do something the hard way instead of passing the client a filename? The code in ExternalDropHandler spends much of its time dealing with the filename anyway.
I don't quite remember, but is it possible that dropped files might indeed need special handling in some cases? Like, if the OS gives you a handle to the file instead of just a file name. This does make sense when you think of the handle as a capability (as in capability-based security).
Also, I do remember a case on Linux where we needed to delete a dropped file immediately after opening it because it was supposed to be temporary (and reading works fine even after the dir entry has been deleted). But that may be unrelated to the DropPlugin code.
- Bert -
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140411/aa4f49ac/smime.bin
More information about the Squeak-dev