Is there a way to access other controller square's other icons programmatically?

[Daryle Walker]

I used to use a single view controller, in a storyboard, with all the 
controls/views laid out, including any object/array controllers in the top bar 
along with the view-controller reference and the first responder icon. Now I 
moved to a network of view controllers, i.e. split- and tab-view-controllers. 
This means that the various parts can’t access each other anymore. I have a 
custom window controller class with a reference to the model and an object 
controller that points to the model. Since the view controller tree is fixed, I 
can walk it and keep references to each view controller. While walking the 
tree, I make the model’s object controller the represented-object for each view 
controller (with Cocoa Bindings). I think each view controller has a reference 
to its top view; this means I can walk each controller for the individual 
scroll, clip, and table/text views.

Now the view controller that contains the table view also has an array 
controller connecting the table to the model’s object controller. When walking 
the controller tree, how can I get a reference to that array controller to 
store as a property in my window controller class? (Or anything in that top 
icon strip besides the controller itself) I want to keep referencing the same 
object & array controllers already allocated when I build my tree of text 
blocks to support find.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

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

How do I set a NSTextView's font in Interface Builder?

[Daryle Walker]

I have the NSTextView selected in its storyboard scene. And I have the 
Attributes Inspector active. The entry for the font is empty. Clicking the 
squared-T gives a pop-up with a “Custom” font and changing it to one of the 
fixed selections (User, fixed) doesn’t do any actual change. This makes the 
text-view with the initial font (the application/user non-fixed-width font). Is 
there a way to change the text-view’s font in IB?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

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: Unicode filenames with Apple File System and UIManagedDocument

[davelist]

> On Mar 23, 2017, at 12:24 PM, David Duncan  wrote:
> 
> I just want to remind everyone I’m *not* a file system’s engineer – I’m just 
> trying to help Dave (and anyone else caught in this) make sure their app can 
> find their files.
> 
>> On Mar 23, 2017, at 1:53 AM, Alastair Houghton 
>>  wrote:
>> 
>> On 22 Mar 2017, at 18:00, David Duncan  wrote:
>>> 
>>> So there was another explanation posted on the bug that I’m not certain you 
>>> got, but which I think may explain.
>>> 
>>> Basically the concept is that since APFS doesn’t normalize file names, if 
>>> you store file names in some other storage (say in your preferences) then 
>>> what could happen is this:
>>> 
>>> 10.2: File is saved with a file name handed to the file system in NFC form. 
>>> File system converts the file name to NFD. You store it as NFC.
>>> 10.3: File system is converted to APFS, and the file name is NFD. You try 
>>> to look up the file as NFC, and it fails.
>> 
>> This is going to cause problems, though, when things migrate from HFS+ to 
>> APFS, because the HFS normalisation *isn’t* a standard one.  In particular, 
>> it certainly *isn’t* NFD for the current version of Unicode.
> 
> Yes, that is the crux of Dave’s issue – HFS+ => APFS only translated the file 
> names (from UTF-16 to UTF-8), it did not re-normalize them.
> 
>> The only obvious solution for that would be to have the HFS+ to APFS 
>> migration tool *re-normalise* the filenames (maybe it does?), but that’s 
>> bound to break things in the (presumably quite common) case where the 
>> filename stored in e.g. a plist was originally obtained from the filesystem.
> 
> Arguably there is no way for the file system converter to know how it should 
> renormalize file names. This is akin to case sensitive vs case insensitive 
> file systems. If you ran a converter from a case insensitive file system to a 
> case sensitive one, you could preserve the capitalization during the 
> conversion, but file lookups that used the wrong case would fail after the 
> conversion. But the converter can’t know you want to look up “foo” via “FOO” 
> or “Foo” to do any kind of normalization. The difference here is that for the 
> most part unicode normalization is invisible to the developer.
> 
>> 
>> Kind regards,
>> 
>> Alastair.
>> 
>> --
>> http://alastairs-place.net
>> 
> 
> --
> David Duncan


I appreciate the help you (and everyone else) has given. I should be able to 
add an option to rescan what files are there. And I'll make time this weekend 
to submit a DTS incident and see what answer I can get and share it here. I do 
suspect I won't be the only one bit by this.

Thanks,
Dave Reed





___

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: Printing in Swift

[corbin dunn]

> On Mar 21, 2017, at 7:45 AM, David Delmonte  wrote:
> 
> Hello Group. 
> 
> I have an NSView-based app (i.e. not document-based), and I’d like to bolt on 
> a printing subsystem. I can get NSViews in my main controller to print ok. 
> However, I want to have a special view constructed just for printing. The 
> view should not show in the app’s window.
> 
> I cannot seem to figure out a way to do this.  I have tried various forms of 
> these examples:
> 
> 1. Add an NSView to my main view window? Seems logical, but it’s awkward in a 
> storyboard, (I can’t position the view in the storyboard).
> 
> 2. Programmatically create a custom NSView with a xib?
> 
> For this, I’ve tried:
> 
> @IBOutlet weak var printView: NSView!
> ….
> let printOperation = NSPrintOperation(view: printView!)
> 
> This results in the comprehensive “fatal error: unexpectedly found nil while 
> unwrapping an Optional value” message.

Sounds like printView is nil, but shouldn’t be; maybe you are loading the NIB 
wrong? What is your code? Is the Outlet hooked up?

corbin

> 
> 
> 3. A seperate ViewController? If so, how can I avoid having two print buttons 
> — one to call the print controller, and the second, to print the 
> PrintController’s view.
> 
> I’ve tried reading the Apple docs, but they are not the way I learn best. 
> I’ve waded through SE, but have come up blank. Could you point me towards a 
> solution please.


___

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: Unicode filenames with Apple File System and UIManagedDocument

[Alastair Houghton]

On 23 Mar 2017, at 17:57, Ed Wynne  wrote:
> 
>> Shouldn’t the VFS layer actually be doing this? It is part of its whole 
>> raison d’être, no? Just have -[NSURL fileSystemRepresentation] normalize 
>> things according to the correct Unicode rules, and let the VFS layer 
>> translate that to HFS+’s normalization style when dealing with HFS+.
> 
> Yes, this.
> 
> Having the conversion only available up in the Cocoa layer is an incredibly 
> poor choice. It effectively means nothing at the BSD layer will be able to 
> properly normalize file names. Having it at the VFS layer is the most sane 
> option, even with the problems that causes.

It can’t really take place at the VFS layer, because the appropriate 
normalisation is filesystem specific - some filesystems don’t normalise, others 
do, and the exact rules differ.

It *could* take place in the filesystem driver, as happens currently for HFS+.  
The problem with that is that while your software will work fine on HFS+, it 
might break if given a different filesystem to run on, which is kind of what 
this thread is all about, no?  (And we already had similar problems with 
case-sensitive HFS+ too, which usually breaks certain big brand-name 
applications software.)  I have to say I’m generally in favour of APFS 
normalising Unicode names, but I can understand that there are reasons the APFS 
team might have decided not to (it’s really up to them to elucidate what those 
reasons were).

This is a rather horrible area of filesystem work, made worse by the fact that 
many historic filesystems don’t even bother storing what character encoding was 
used.  Indeed, on such systems it’s even possible that users will use different 
encoding in different directories (:-()

Clearly, encoding detailed knowledge of appropriate normalisation on a 
per-filesystem basis in end-user applications is not a sensible approach here.  
Apple suggesting that we normalise filenames before passing them to the BSD 
layer wouldn’t be the end of the world, but it might result in some 
applications not being able to cope with some otherwise valid filenames because 
the name on disk differs from the chosen normalisation.

Another option might be to add some flags to the BSD open() API (for instance, 
O_UNICODE and O_CASEFOLD) that cause it to use a Unicode-aware comparison 
routine inside the filesystem implementation, the idea being that it will open 
a file with the exact name passed if it exists, or, if that file doesn’t exist, 
it will enumerate the containing directory looking for one that matches.  
Sadly, this enumeration would need to be recursive (since the directory name 
might have the same problem).  The Foundation framework could then use the new 
flags to obtain reasonable behaviour.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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: Unicode filenames with Apple File System and UIManagedDocument

[Jens Alfke]

> On Mar 22, 2017, at 2:25 PM, davel...@mac.com wrote:
> 
> "Engineering has the following feedback for you:
> 
> iOS HFS Normalized UNICODE names , APFS now treats all files as a bag of 
> bytes on iOS . We are requesting that Applications developers call the 
> correct Normalization routines to make sure the file name contains the 
> correct representation.
> 
> We are now closing this bug report.

If Apple really is making developers responsible for Unicode normalization of 
filenames, that’s a big compatibility issue and they would need to educate 
developers, give them sample code, etc. In other words, something that would 
have been a big deal at last year’s WWDC when APFS was announced. I’m pretty 
sure that very few developers understand Unicode normalization (I don’t beyond 
a surface level), so Apple can’t expect them to take it on as an “oh, by the 
way” sort of thing.

Apple takes I18N pretty seriously, and I find it hard to believe that they’d 
change the filesystem in a way that could potentially cause huge problems 
accessing files with non-Roman names, without making sure that developers can 
handle the transition.

The above makes me doubt that this is really what’s going on. I’ve worked at 
Apple, and I know it’s entirely possible that the above quote is the result of 
a game of ‘Telephone’ in which the actual meaning’s gotten messed up when 
passed from engineering to tech support.

—Jens
___

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: programmatically tell when spotlight/mds is indexing

[corbin dunn]

Also, please log bugs requesting for public API to do this. Thanks!

corbin

> On Mar 23, 2017, at 9:53 AM, Saagar Jha  wrote:
> 
> I couldn’t find a public API, but Metadata.framework defines 
> _MDConfigCopyStoreInformation(NSString *path). It returns an dictionary 
> containing the key “CurrentlyScanning”, which you might find useful.
> 
> Saagar Jha
> 
>> On Mar 18, 2017, at 09:37, sqwarqDev > > wrote:
>> 
>> 
>>> On 18 Mar 2017, at 23:05, Jerome Krinock  wrote:
>>> 
>>> To generalize your question, you want to reverse-engineer some other app to 
>>> reveal some status information. I’ve had to do this a couple times.
>> 
>> Thanks for the thought, but my question was really just a sanity check to 
>> make sure that there isn’t an already existing public API I might have 
>> missed that a developer could use to query the status of mds. 
>> 
>> Any kind of guesswork about what files may or may not be open when mds is 
>> indexing would be a bit too hit and miss for what I need.
>> 
>> 
>> Best
>> 
>> 
>> Phil
>> @sqwarq

___

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: Unicode filenames with Apple File System and UIManagedDocument

[Ed Wynne]

> On Mar 23, 2017, at 1:40 PM, Charles Srstka  wrote:
> 
>> On Mar 23, 2017, at 3:50 AM, Alastair Houghton 
>>  wrote:
>> 
>> On 22 Mar 2017, at 19:13, Chris Ridd > > wrote:
>>> 
 On 22 Mar 2017, at 09:05, Alastair Houghton > wrote:
 
 In the context of filesystems (and specifically filenames), the phrases 
 “bag of bytes” and “bunch of bytes” have a fairly specific meaning.  The 
 point is that the filesystem doesn’t inspect the bytes it’s given, and 
 doesn’t care what they represent (about the only exception is that it 
 probably doesn’t support embedded NULs).  It isn’t suggesting that the 
 names are treated as an unordered set of bytes (that’d just be silly).  
 It’s just expressing the fact that the filesystem doesn’t care what they 
 are - it may compare them, and if it does so, it will use binary ordering 
 (not some other collation sequence) and won’t worry about things like case 
 or encoding at all.
>>> 
>>> That doesn’t sound sensible at all. It means you can create a filename with 
>>> a byte sequence that isn’t valid UTF-8 and which likely then cannot be 
>>> accessed by MacOS/iOS processes.
>> 
>> That isn’t possible on macOS - there’s a percent escaping mechanism built in 
>> to the kernel to prevent this problem.
>> 
>>> It means that you could create multiple files with the “same" name, and 
>>> that doesn’t sound like a win either. e.g. Aandi’s examples of LATIN SMALL 
>>> LETTER E (U+0065)
>>> COMBINING ACUTE ACCENT (U+0301) and LATIN SMALL LETTER E WITH ACUTE (U+00E9)
>> 
>> Yes, it does.
>> 
>>> How can a “next gen” filesystem avoid using Unicode rules when handling 
>>> filenames?
>> 
>> Well, if I had designed it, it wouldn’t.  But I didn’t.
>> 
>> To be fair, I can see arguments in favour of the bunch of bytes approach; 
>> the existing approach has created a problem in HFS+, in that the 
>> normalisation is essentially fixed for all time, and doesn’t correspond to 
>> the current version of Unicode.  It’s actually worse than it might be, 
>> because (IIRC) they fixed the normalisation *before* Unicode adopted a 
>> stability policy for normalisation...
>> 
>> But if the filesystem (or kernel) isn’t doing it, then IMO the Cocoa 
>> frameworks certainly should.
> 
> Shouldn’t the VFS layer actually be doing this? It is part of its whole 
> raison d’être, no? Just have -[NSURL fileSystemRepresentation] normalize 
> things according to the correct Unicode rules, and let the VFS layer 
> translate that to HFS+’s normalization style when dealing with HFS+.


Yes, this.

Having the conversion only available up in the Cocoa layer is an incredibly 
poor choice. It effectively means nothing at the BSD layer will be able to 
properly normalize file names. Having it at the VFS layer is the most sane 
option, even with the problems that causes.

-Ed


___

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: Unicode filenames with Apple File System and UIManagedDocument

[Charles Srstka]

> On Mar 23, 2017, at 3:50 AM, Alastair Houghton  
> wrote:
> 
> On 22 Mar 2017, at 19:13, Chris Ridd  > wrote:
>> 
>>> On 22 Mar 2017, at 09:05, Alastair Houghton >> > wrote:
>>> 
>>> In the context of filesystems (and specifically filenames), the phrases 
>>> “bag of bytes” and “bunch of bytes” have a fairly specific meaning.  The 
>>> point is that the filesystem doesn’t inspect the bytes it’s given, and 
>>> doesn’t care what they represent (about the only exception is that it 
>>> probably doesn’t support embedded NULs).  It isn’t suggesting that the 
>>> names are treated as an unordered set of bytes (that’d just be silly).  
>>> It’s just expressing the fact that the filesystem doesn’t care what they 
>>> are - it may compare them, and if it does so, it will use binary ordering 
>>> (not some other collation sequence) and won’t worry about things like case 
>>> or encoding at all.
>> 
>> That doesn’t sound sensible at all. It means you can create a filename with 
>> a byte sequence that isn’t valid UTF-8 and which likely then cannot be 
>> accessed by MacOS/iOS processes.
> 
> That isn’t possible on macOS - there’s a percent escaping mechanism built in 
> to the kernel to prevent this problem.
> 
>> It means that you could create multiple files with the “same" name, and that 
>> doesn’t sound like a win either. e.g. Aandi’s examples of LATIN SMALL LETTER 
>> E (U+0065)
>> COMBINING ACUTE ACCENT (U+0301) and LATIN SMALL LETTER E WITH ACUTE (U+00E9)
> 
> Yes, it does.
> 
>> How can a “next gen” filesystem avoid using Unicode rules when handling 
>> filenames?
> 
> Well, if I had designed it, it wouldn’t.  But I didn’t.
> 
> To be fair, I can see arguments in favour of the bunch of bytes approach; the 
> existing approach has created a problem in HFS+, in that the normalisation is 
> essentially fixed for all time, and doesn’t correspond to the current version 
> of Unicode.  It’s actually worse than it might be, because (IIRC) they fixed 
> the normalisation *before* Unicode adopted a stability policy for 
> normalisation...
> 
> But if the filesystem (or kernel) isn’t doing it, then IMO the Cocoa 
> frameworks certainly should.

Shouldn’t the VFS layer actually be doing this? It is part of its whole raison 
d’être, no? Just have -[NSURL fileSystemRepresentation] normalize things 
according to the correct Unicode rules, and let the VFS layer translate that to 
HFS+’s normalization style when dealing with HFS+.

Charles

___

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: programmatically tell when spotlight/mds is indexing

[Saagar Jha]

I couldn’t find a public API, but Metadata.framework defines 
_MDConfigCopyStoreInformation(NSString *path). It returns an dictionary 
containing the key “CurrentlyScanning”, which you might find useful.

Saagar Jha

> On Mar 18, 2017, at 09:37, sqwarqDev  wrote:
> 
> 
>> On 18 Mar 2017, at 23:05, Jerome Krinock  wrote:
>> 
>> To generalize your question, you want to reverse-engineer some other app to 
>> reveal some status information. I’ve had to do this a couple times.
> 
> Thanks for the thought, but my question was really just a sanity check to 
> make sure that there isn’t an already existing public API I might have missed 
> that a developer could use to query the status of mds. 
> 
> Any kind of guesswork about what files may or may not be open when mds is 
> indexing would be a bit too hit and miss for what I need.
> 
> 
> Best
> 
> 
> Phil
> @sqwarq
> ___
> 
> 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/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com

___

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: Unicode filenames with Apple File System and UIManagedDocument

[David Duncan]

I just want to remind everyone I’m *not* a file system’s engineer – I’m just 
trying to help Dave (and anyone else caught in this) make sure their app can 
find their files.

> On Mar 23, 2017, at 1:53 AM, Alastair Houghton  
> wrote:
> 
> On 22 Mar 2017, at 18:00, David Duncan  wrote:
>> 
>> So there was another explanation posted on the bug that I’m not certain you 
>> got, but which I think may explain.
>> 
>> Basically the concept is that since APFS doesn’t normalize file names, if 
>> you store file names in some other storage (say in your preferences) then 
>> what could happen is this:
>> 
>> 10.2: File is saved with a file name handed to the file system in NFC form. 
>> File system converts the file name to NFD. You store it as NFC.
>> 10.3: File system is converted to APFS, and the file name is NFD. You try to 
>> look up the file as NFC, and it fails.
> 
> This is going to cause problems, though, when things migrate from HFS+ to 
> APFS, because the HFS normalisation *isn’t* a standard one.  In particular, 
> it certainly *isn’t* NFD for the current version of Unicode.

Yes, that is the crux of Dave’s issue – HFS+ => APFS only translated the file 
names (from UTF-16 to UTF-8), it did not re-normalize them.

> The only obvious solution for that would be to have the HFS+ to APFS 
> migration tool *re-normalise* the filenames (maybe it does?), but that’s 
> bound to break things in the (presumably quite common) case where the 
> filename stored in e.g. a plist was originally obtained from the filesystem.

Arguably there is no way for the file system converter to know how it should 
renormalize file names. This is akin to case sensitive vs case insensitive file 
systems. If you ran a converter from a case insensitive file system to a case 
sensitive one, you could preserve the capitalization during the conversion, but 
file lookups that used the wrong case would fail after the conversion. But the 
converter can’t know you want to look up “foo” via “FOO” or “Foo” to do any 
kind of normalization. The difference here is that for the most part unicode 
normalization is invisible to the developer.

> 
> Kind regards,
> 
> Alastair.
> 
> --
> http://alastairs-place.net
> 

--
David Duncan


___

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: Unicode filenames with Apple File System and UIManagedDocument

[Alastair Houghton]

On 22 Mar 2017, at 18:00, David Duncan  wrote:
> 
> So there was another explanation posted on the bug that I’m not certain you 
> got, but which I think may explain.
> 
> Basically the concept is that since APFS doesn’t normalize file names, if you 
> store file names in some other storage (say in your preferences) then what 
> could happen is this:
> 
> 10.2: File is saved with a file name handed to the file system in NFC form. 
> File system converts the file name to NFD. You store it as NFC.
> 10.3: File system is converted to APFS, and the file name is NFD. You try to 
> look up the file as NFC, and it fails.

This is going to cause problems, though, when things migrate from HFS+ to APFS, 
because the HFS normalisation *isn’t* a standard one.  In particular, it 
certainly *isn’t* NFD for the current version of Unicode.

The only obvious solution for that would be to have the HFS+ to APFS migration 
tool *re-normalise* the filenames (maybe it does?), but that’s bound to break 
things in the (presumably quite common) case where the filename stored in e.g. 
a plist was originally obtained from the filesystem.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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: Unicode filenames with Apple File System and UIManagedDocument

[Alastair Houghton]

On 22 Mar 2017, at 19:13, Chris Ridd  wrote:
> 
>> On 22 Mar 2017, at 09:05, Alastair Houghton  
>> wrote:
>> 
>> In the context of filesystems (and specifically filenames), the phrases “bag 
>> of bytes” and “bunch of bytes” have a fairly specific meaning.  The point is 
>> that the filesystem doesn’t inspect the bytes it’s given, and doesn’t care 
>> what they represent (about the only exception is that it probably doesn’t 
>> support embedded NULs).  It isn’t suggesting that the names are treated as 
>> an unordered set of bytes (that’d just be silly).  It’s just expressing the 
>> fact that the filesystem doesn’t care what they are - it may compare them, 
>> and if it does so, it will use binary ordering (not some other collation 
>> sequence) and won’t worry about things like case or encoding at all.
> 
> That doesn’t sound sensible at all. It means you can create a filename with a 
> byte sequence that isn’t valid UTF-8 and which likely then cannot be accessed 
> by MacOS/iOS processes.

That isn’t possible on macOS - there’s a percent escaping mechanism built in to 
the kernel to prevent this problem.

> It means that you could create multiple files with the “same" name, and that 
> doesn’t sound like a win either. e.g. Aandi’s examples of LATIN SMALL LETTER 
> E (U+0065)
> COMBINING ACUTE ACCENT (U+0301) and LATIN SMALL LETTER E WITH ACUTE (U+00E9)

Yes, it does.

> How can a “next gen” filesystem avoid using Unicode rules when handling 
> filenames?

Well, if I had designed it, it wouldn’t.  But I didn’t.

To be fair, I can see arguments in favour of the bunch of bytes approach; the 
existing approach has created a problem in HFS+, in that the normalisation is 
essentially fixed for all time, and doesn’t correspond to the current version 
of Unicode.  It’s actually worse than it might be, because (IIRC) they fixed 
the normalisation *before* Unicode adopted a stability policy for 
normalisation...

But if the filesystem (or kernel) isn’t doing it, then IMO the Cocoa frameworks 
certainly should.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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: Unicode filenames with Apple File System and UIManagedDocument

[Quincey Morris]

On Mar 22, 2017, at 14:25 , davel...@mac.com wrote:
> 
> On Mar 22, 2017, at 2:00 PM, David Duncan  > wrote:
>> 
>> So there was another explanation posted on the bug that I’m not certain you 
>> got, but which I think may explain.
>> 
>> Basically the concept is that since APFS doesn’t normalize file names, if 
>> you store file names in some other storage (say in your preferences) then 
>> what could happen is this:

The “why” doesn’t matter at all. As I said before, the problem is that breaking 
the existing Cocoa file system API contract will break existing apps. It’s as 
simple as that.

Apple can certainly move the normalization out of the file system code into 
Cocoa frameworks code, but they can’t simply drop it. Imagine what would happen 
if they did. Within a few weeks, users would start reporting that they had lost 
access to some of their files. Not only existing files, but potentially files 
created after the conversion to APFS. 

Not only that, but the Cocoa frameworks would break, too. Any time a file name 
was programmatically manipulated in the frameworks, such as having a suffix 
appended that was taken from a string constant or a resource string, the 
resulting name would be vulnerable to reversion to non-NFD, and … blammo.

This isn’t viable.

> Do I use the following?
> 
> NSURL *url = [[self courseDirectory] 
> URLByAppendingPathComponent:name.decomposedStringWithCanonicalMapping];
> 
> Where [self courseDirectory] is a URL in English (assuming the sandboxed 
> Documents directory are in English for other locales) and name is the 
> NSString the user enters. 

That isn’t going to be enough. Your “courseDirectory” subdirectory of the 
Documents directory might have an English name, but:

1. There’s no guarantee that English names have only a single Unicode form. 
(You could make this assumption for ASCII-character names, though.)

2. It’s unlikely that the path to the Documents directory is in English, and 
it’s not under your control.
___

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: programmatically tell when spotlight/mds is indexing

[Rob Petrovec]

I’m not sure there is a way to tell if it is indexing other then to check for 
the existence of the mdworker process. But that won’t tell you if you are in 
the middle of a full index. It will just say that Spotlight is importing 
something, somewhere, for some reason which it does all the time.  If you 
listen for batch notifications from the query you should be able to show the 
user some data as it comes in so they don’t think that your app is hung.  
Alternatively, you could just set a timer for X seconds after the query has 
started and display “This may take a while” dialog or text somewhere in your UI.

—Rob


> On Mar 18, 2017, at 10:37 AM, sqwarqDev  wrote:
> 
> 
>> On 18 Mar 2017, at 23:05, Jerome Krinock  wrote:
>> 
>> To generalize your question, you want to reverse-engineer some other app to 
>> reveal some status information. I’ve had to do this a couple times.
> 
> Thanks for the thought, but my question was really just a sanity check to 
> make sure that there isn’t an already existing public API I might have missed 
> that a developer could use to query the status of mds. 
> 
> Any kind of guesswork about what files may or may not be open when mds is 
> indexing would be a bit too hit and miss for what I need.
> 
> 
> Best
> 
> 
> Phil
> @sqwarq
> ___
> 
> 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/petrock%40mac.com
> 
> This email sent to petr...@mac.com


___

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