On Oct 4, 2008, at 8:31 PM, Jim Correia wrote:
On Oct 4, 2008, at 10:45 PM, Nathan Vander Wilt wrote:
HFS types seem to be well deprecated in nearly every other area,
the drag destination guides don't encourage checking the types anyway
Can you post a reference?
You generally should check the type in the drag, and not offer to
accept a drag which you can't accept.
As to HFS types being deprecated, the documentation at http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html
says they were "originally designed for Mac OS 9 and earlier".
Beyond that, I think I'll have to mostly concede this point. You are
right that the HIG encourages rejecting drags based on file types
(though in the case of a non-promise drag this can take an extremely
non-deterministic amount of time). For what it's worth, the sample
code at http://developer.apple.com/documentation/Cocoa/Conceptual/DragandDrop/Tasks/DraggingFiles.html
does not check types, but the text above does mention "The
destination can then accept or reject a drag operation based on the
contents of the types array."
and the API itself doesn't facilitate easy checking especially
given the fact that strings already are *either* extensions or
legacy type codes with no programmatic distinction.
Due to the convention for how HFS types are encoding, it is possible
to programatically distinguish the two, if you need to do so.
I'm not sure what you mean here. The documentation for promise drags
says to encode the OSType using NSFileTypeForHFSTypeCode() which in my
testing just turns the "characters" the programmer sees in their
source into a string (ie 'uint' becomes @"uint"). As extensions could
be any number of characters, how would I know if "docx" is the
exension of a new Office document or maybe some old OSType code
registered decades ago for a totally different format?
Plus who really wants to keep comparing strings (eg 'txt' vs. 'TXT'
vs. 'TEXT' times every other supported format) when they could be
using UTTypeConformsTo instead? :-)
Nobody really wants to keep supporting legacy standards when there
are new better ones. However, if you want to interoperate with stuff
which uses those legacy standards, you have to.
Until such time as NSPasteboard does implicit translation of UTIs
put in NSFilesPromisePboardType, any client only expecting to see
traditional types might fail. Only you can decide if you need to
interoperate with such clients.
As it turns outs, I've hedged my bets. I conservatively only put
traditional types when writing NSFilesPromisePboardType, but
correctly handle UTIs when receiving the drag. I don't know how many
other clients are as flexible.
What initially bothered me about the lack of UTI support was that I
have no idea what the HFS types were, except for 'GIFf' and 'TEXT'
which show up as canonical OSType examples throughout the docs. Of
course, since I can use extensions that's mostly a a non-issue, though
I do wonder what I'd do if another app gives me HFS types instead of
extensions. You're probably right, though, if I'm the only one putting
UTI strings into the promise array it might as well be haiku or ASCII
art instead.
thanks,
-natevw
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
