[squeak-dev] DropPlugin usage questions

tim Rowledge tim at rowledge.org
Fri Apr 11 18:25:04 UTC 2014

On 11-04-2014, at 7:18 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:

> 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).

I thought that might have been the issue, but I can’t see anything in the plugin code that really supports the theory. I wondered if may it had been a Mac thing - they (used to) have some pretty weird file related needs.

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: CPE: Create Parity Error

More information about the Squeak-dev mailing list