Re: Problem getting import UTI recognised
Something is extremely screwy. I've rebuilt the lsregister, I've rebooted in safe mode, tried everything that I can find hints about on the 'net. In my app, I log the results from +readableTypes and they all look fine. Experimenting, these seem only to be derived from the document types I declare, they are unaffected by the UTIs. It's still unclear to me what a document-based app does with UTIs when opening a file, whether it looks at local informaiton only, or goes out to the ls database - I suspect it must be the latter since the local info appears to be correct and consistent. I deleted the UTIs altogether to start over, and now I get a logged warning from NSDocumentController about being unable to get a type from the file extension, and that I should declare at least one EXPORT UTI. I add that back in and the warning shuts up. My Open dialog now shows files available for the two additional (non-native) types I can open, but greys out my native type. I add back in all the import and export UTIs that I had before. Same thing - my native type is unavailable, the extra types are readable and open OK. I installed the 3rd party pref pane RCDefaultApp to try and make it a bit easier to examine the ls register database. It seems to have all the expected mappings for my file type, the UTI and my app's bundle ID. Comparing to other apps, it appears to be no different, and yet I'm still unable to open my native files. one small clue might be that during this deleting and recreating my UTIs and document types, I changed the description of my document, however the Finder and RCDefaultApp displays the OLD name I had used, even after forcing a rebuild of the register. This suggests that the OS is caching the register and the rebuild commands (namely /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain user). Info on the net suggests that a reboot in safe mode should do something about that, but after doing so I see no improvement. I don't know, but it seems to bethat my system is screwed up in some way that the usual lsregister rebuild isn't clearing. If that's the case then this screw-up occurred using Xcode 6.0.1's UTI editor plus launching my app, nothing especially skanky on my part. I think my question must be now: how do I get rid of the cached register and rebuild it properly? --Graham On 16 Oct 2014, at 3:11 pm, Graham Cox graham@bigpond.com wrote: On 16 Oct 2014, at 2:19 pm, Kyle Sluder k...@ksluder.com wrote: Is there another app on your system declaring that file extension for its own UTI? You can dump the database with lsregister(1). No, I used lsregister -dump and my app is the only one. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
On Oct 15, 2014, at 23:05 , Graham Cox graham@bigpond.com wrote: I don't know, but it seems to bethat my system is screwed up in some way that the usual lsregister rebuild isn't clearing. If that's the case then this screw-up occurred using Xcode 6.0.1's UTI editor plus launching my app, nothing especially skanky on my part. I think my question must be now: how do I get rid of the cached register and rebuild it properly? I dunno, but I also got into LS database hell once, and it wasn’t fun. From what I recall, rebuilding the database isn’t really reliable. Whether it lies, or doesn’t do it, or does something more complicated than you expect, I don’t know. Again from what I recall, the only solution was to go on a search and destroy mission locating every lurking copy of the app that remained on the system. Only when I found and destroyed the last one did the associations work properly. Deleting your derived data folder is a key part of this, but you may find other copies of your app (from previous builds, test sessions, emails, etc) in unexpected places. The fact that the Finder is mis-reporting the file type suggests to me that there are out-of-date copies of your app somewhere. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
On 16 Oct 2014, at 5:18 pm, Quincey Morris quinceymor...@rivergatesoftware.com wrote: I dunno, but I also got into LS database hell once, and it wasn’t fun. Well, that's actually a help - it means that what I'm experiencing isn't necessarily unique. From what I recall, rebuilding the database isn’t really reliable. Whether it lies, or doesn’t do it, or does something more complicated than you expect, I don’t know. Again from what I recall, the only solution was to go on a search and destroy mission locating every lurking copy of the app that remained on the system. Only when I found and destroyed the last one did the associations work properly. Deleting your derived data folder is a key part of this, but you may find other copies of your app (from previous builds, test sessions, emails, etc) in unexpected places. The fact that the Finder is mis-reporting the file type suggests to me that there are out-of-date copies of your app somewhere. This is really bizarre. I deleted not only every copy of my app, but I deleted the entire project target and made a new one with a new name. I gave it an entirely new bundle identifier, and I changed the file extension and UTI string. This was a lot of work, but the point should be that it has no apparent connection to my previous app, it should look like something completely new, opening different file types. Even if the ls database is corrupted for my old app, surely new entries arising from this should be clean? It acts exactly the same. I subclassed NSDocumentController so I can intercept and log some of the internals, and the file types being passed to -beginOpenPanel:forTypes:completionHandler: are correct - all of the document types I declare are there. But the resulting Open panel still greys out my native type. I don't know if this open panel calls back into the document controller as a delegate, but there seem to be no other public methods that I can override to check what's going on - it seems possible that the open panel might be talking directly to launch services outside of the app, so it can still ignore some of the local info even though that seems all in order. I'm really stumped now; I can't understand what I'm seeing. --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
On 16 Oct 2014, at 7:04 pm, Graham Cox graham@bigpond.com wrote: It acts exactly the same. I subclassed NSDocumentController so I can intercept and log some of the internals, and the file types being passed to -beginOpenPanel:forTypes:completionHandler: are correct - all of the document types I declare are there. But the resulting Open panel still greys out my native type. I don't know if this open panel calls back into the document controller as a delegate, but there seem to be no other public methods that I can override to check what's going on - it seems possible that the open panel might be talking directly to launch services outside of the app, so it can still ignore some of the local info even though that seems all in order. I must be doing something wrong. I made a clean build of my app, moved it to another machine and it does exactly the same thing - can't recognise files of its own type. I've cut down my UTI and document types to a minimum, with a single export for my private native file type, and no imports. I declare 3 document types which include some types written by another app (including plain text). Since I have this other app installed, these files are registered as belonging to it, but can be opened by my app. If I don't declare any UTIs at all I get an error logged from NSDocumentController. Overriding -[NSDocumentController typeForContentsOfURL:error:], I log the UTI that is returned by super's implementation (this is having forced the app to open this file type by setting the Open With... mapping in Finder and double-clicking the file - it still isn't available in the Open dialog, nor draggable on my app's icon). 2014-10-16 21:42:48.896 Crucible 2[380:3307] type = dyn.ah62d4rv4ge80g8dyq2, URL = file:///Users/grahamcox/Documents/Test Files/TestFile2.cxtf It is a dyn.blahblah type, which indicates that the UTI for the given file extension is unknown. So this is the puzzle - why, having exported a UTI for that very extension (.cxtf), is it still returning unknown, even after rebuilding the database, safe rebooting, etc. My export declaration must be incorrect, but AFAICS it looks fine: ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 array dict keyUTTypeConformsTo/key array stringpublic.content/string /array keyUTTypeDescription/key stringCrucible File/string keyUTTypeIconFile/key stringcrucibledoc/string keyUTTypeIdentifier/key stringnet.apptree.crucible.newcrossfile/string keyUTTypeTagSpecification/key dict keycom.apple.ostype/key array stringCXTF/string /array keypublic.filename-extension/key array stringcxtf/string /array /dict /dict /array /plist If I force the above NSDocumentController method to return the expected UTI, it does go ahead and opens the file properly. However, this is not a fix, because it only allows the file to be opened by forcing it open with the app and double-clicking, not in the Open dialog. Still stumped, but maybe somone can spot an issue with the UTI export? --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
Just a shot in the dark, but maybe this is an issue: Comparing your declaration to the sample from https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_declare/understand_utis_declare.html reveals that the sample declares com.apple.ostype directly as an string: .. keyUTTypeTagSpecification/key dict keycom.apple.ostype/key stringJPEG/string keypublic.filename-extension/key .. whereas your sample uses an array with one string. Cheers, Felix On 16.10.2014, at 13:07, Graham Cox graham@bigpond.com wrote: It is a dyn.blahblah type, which indicates that the UTI for the given file extension is unknown. So this is the puzzle - why, having exported a UTI for that very extension (.cxtf), is it still returning unknown, even after rebuilding the database, safe rebooting, etc. My export declaration must be incorrect, but AFAICS it looks fine: ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 array dict keyUTTypeConformsTo/key array stringpublic.content/string /array keyUTTypeDescription/key stringCrucible File/string keyUTTypeIconFile/key stringcrucibledoc/string keyUTTypeIdentifier/key stringnet.apptree.crucible.newcrossfile/string keyUTTypeTagSpecification/key dict keycom.apple.ostype/key array stringCXTF/string /array keypublic.filename-extension/key array stringcxtf/string /array /dict /dict /array /plist If I force the above NSDocumentController method to return the expected UTI, it does go ahead and opens the file properly. However, this is not a fix, because it only allows the file to be opened by forcing it open with the app and double-clicking, not in the Open dialog. Still stumped, but maybe somone can spot an issue with the UTI export? --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/franz%40ergosign.de This email sent to fr...@ergosign.de ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
On 16 Oct 2014, at 10:07 pm, Graham Cox graham@bigpond.com wrote: maybe somone can spot an issue with the UTI export? Just a guess -- the docs say: When specifying conformance for your UTI, your items should ideally conform to both a physical and functional hierarchy. That is, the conformance should specify both its physical nature (a directory, a file, and so on) as well as its usage (an image, a movie, and so on). • A UTI in the physical hierarchy should conform through the inheritance hierarchy to public.item. • A UTI in a functional hierarchy should conform through inheritance to a base UTI that is not public.item. For example, public.content, public.executable and public.archive are all examples of functional base UTIs. While conforming to the functional hierarchy is not mandatory That last sentence could be read as implying that conforming to a physical hierarchy is mandatory, and you're not doing that. So maybe you also need to conform to something like public.item or public.data. -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
On Oct 16, 2014, at 4:07 AM, Graham Cox graham@bigpond.com wrote: ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 array I’m assuming this is a snippet extracted from your actual Info.plist. dict keyUTTypeConformsTo/key array stringpublic.content/string /array You’re not conforming to any physical types. You probably want to conform to public.data as well as public.content. Also, can you provide your CFBundleDocumentTypes array? Most of those keys have been supplanted by the UTI declaration, but you still need that to connect the UTI to an NSDocument subclass. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
On 17 Oct 2014, at 2:25 am, Kyle Sluder k...@ksluder.com wrote: I’m assuming this is a snippet extracted from your actual Info.plist. Yes, when you copy a section of the info.plist it inserts a new header around it. dict keyUTTypeConformsTo/key array stringpublic.content/string /array You’re not conforming to any physical types. You probably want to conform to public.data as well as public.content. OK... I hadn't come across the documentation that really spells that out, but I added it anyway. This was after some time had passed away from my computer. Well, it worked. This was good news, but also suspicious, because I'd earlier tried public.data (instead, rather than as well as, public.content) without luck. OK, so maybe it does need both but now, when I remove the public.data, the behaviour does not revert to how it was! It has turned into an inverse Heisenbug - it only shows up when you're looking for it, sometimes. OK, further experiment... Adding in or removing public.data doesn't have any immediate effect, but seems to after a delay of several minutes. It also seems to be affected by whether I also have an OSType entry or not - if I do, I also need the public.data, but it's hard to tell because of the long delay between the change and the effect it has on the system. Presumably the lsregister is only updated by some daemon that runs fairly slowly? That's a real problem when you're developing and need to see the effect of changes immediately. Shouldn't XCode be forcing the register to be valid for the app it's debugging? Also, can you provide your CFBundleDocumentTypes array? Most of those keys have been supplanted by the UTI declaration, but you still need that to connect the UTI to an NSDocument subclass. That looks OK, here's the relevant entry (there are others): ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 array dict keyCFBundleTypeExtensions/key array stringcxtf/string /array keyCFBundleTypeIconFile/key stringcrucibledoc/string keyCFBundleTypeName/key stringCrucible File/string keyCFBundleTypeRole/key stringEditor/string keyLSItemContentTypes/key array stringnet.apptree.crucible.newcrossfile/string /array keyLSTypeIsPackage/key integer0/integer keyNSDocumentClass/key stringCRUDocument/string /dict dict /array /plist Im grateful for the help, though so far I'm still not certain whether I've nailed the problem or not. --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
On 17 Oct 2014, at 11:36 am, Graham Cox graham@bigpond.com wrote: Im grateful for the help, though so far I'm still not certain whether I've nailed the problem or not. Nope, because moving the clean build of the app to another machine it cannot open its own files, even after waiting a long time in case it's just an update issue. It's odd, because the files get the right icon in Finder, but the Open With menu shows no app claims it. If I force the app to claim it, it's still greyed out in the Open dialog, but double-clicking the file launches the app, which then shows the error message that the app can't open files of this type. Grrr, this whole UTI business - what is it good for? --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
Just to throw another spanner in the works, is there an interaction between the UTI/filetype/app claim system and code signing? For my second machine, I've been signing my app using my Developer ID. If I don't sign it, it works. If it's signed, it doesn't. The UTI documentation doesn't mention this, so I'm not sure if what I'm seeing is real (by which I mean maybe my other system has just caught up and updated...) --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Problem getting import UTI recognised
Hi all, My app declares 3 UTIs for import, which are basically the same as the document types it supports. It imports two of the types fine, but the other (which is actually the default native format) it refuses to accept - I get a message to say that my app cannot open documents of such-and-such format, and my document's -readFromData:ofType:... isn't even called. It writes files of this type OK, but in the Finder they have the generic icon and the 'Kind' is just Document instead of the correct description. My native UTI is declared in the usual way, in reverse dot.com form, and this conforms to public.content, unpackaged. The export UTIs are the same. I must be missing something pretty obvious, but I'm at a loss. --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
On Oct 15, 2014, at 8:14 PM, Graham Cox graham@bigpond.com wrote: Hi all, My app declares 3 UTIs for import, which are basically the same as the document types it supports. It imports two of the types fine, but the other (which is actually the default native format) it refuses to accept - I get a message to say that my app cannot open documents of such-and-such format, and my document's -readFromData:ofType:... isn't even called. It writes files of this type OK, but in the Finder they have the generic icon and the 'Kind' is just Document instead of the correct description. My native UTI is declared in the usual way, in reverse dot.com form, and this conforms to public.content, unpackaged. The export UTIs are the same. I must be missing something pretty obvious, but I'm at a loss. Is there another app on your system declaring that file extension for its own UTI? You can dump the database with lsregister(1). --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem getting import UTI recognised
On 16 Oct 2014, at 2:19 pm, Kyle Sluder k...@ksluder.com wrote: Is there another app on your system declaring that file extension for its own UTI? You can dump the database with lsregister(1). No, I used lsregister -dump and my app is the only one. I'm going backwards now - having rebuilt using lsregister and fiddled around in my app's UTI declarations (deleting and recreating them), I can't open any files at all now. When I show my app's Open dialog, ALL of the files I declare are unopenable (greyed out). In the Finder I can force a file to Open with the app, which does assign the correct 'Kind, but my app still won't actually open it. I've also tried deleting the UTIs altogether and sticking only with declared document types, old-school, but that doesn't fix things. I think one of the the things that's frustrating me here is I don't know how an app actually links a document class to a file type - UTIs only seem to complicate the picture while still ultimately deriving from the file extension. Should I be overriding +readableTypes, +writeableTypes and +isNativeType in my document subclass? I don't think I've had to do that in the past - I thought the UTI declarations informed these methods? -Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
