Table Header row question

[Rick Corteza]

Hi there,

I have an NSPanel that I use as a log with 3 columns. All works well but when I 
first open the log and start to scroll the TableHeaderView jumps maybe 10 
pixels or so to the left and causing the headers to be misaligned. What could 
be causing this?

rc
___

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: Of course I forgot some NSTextFinder questions

[Daryle Walker]

> On Mar 20, 2017, at 1:41 PM, Quincey Morris 
>  wrote:
> 
> On Mar 20, 2017, at 04:58 , Daryle Walker  > wrote:
>> 
>>> If all the strings were concatenated together would be the ‘x’ in "fox”.
> 
>> Is there a off-by-one bug with the end of the second string? Or am I really 
>> misunderstanding Apple’s counting strategy? The second string seems to be 
>> only 9 characters long. And shouldn't index 18 point to the first character 
>> of the third string instead?
> 
> There’s clearly an omission in that sentence in the documentation, and it 
> appears to mean to say: If all the strings were concatenated together, the 
> 18th character would be the ‘x’ in “fox”.
> 
> Looking at the example concatenation in the next paragraph, it appears that 
> the expectation is that the “conceptually concatenated string” has spaces 
> inserted between the substrings, and that would account for the extra 
> character in the “fox” text. My guess is that putting conceptual spaces in 
> the conceptual concatenation has something to do with the proper recognition 
> of word boundaries (in some languages), but it’s not clear how that works in 
> practice.
> 

There’s nothing conceptual about; it’s a different bug instead!

A lot of new(-ish) Apple API don’t get guides, but have semi-extensive 
instruction in the AppKit (or whatever) notes for the first version of macOS 
the API premiered. The Mac OS X 10.7 Lion part of the 10.11-and-before AppKit 
notes 
()
 uses this very example, but there is a space character before the “brown”! So 
the problem is there was a transcription error between the AppKit notes and the 
API page. (But there isn’t an extra space before the third string or another 
space either at the end of the third string or the start of the fourth.)

> A bug report would probably be appropriate.

— 
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 21, 2017, at 1:06 AM, Jens Alfke  wrote:
> 
> 
>> On Mar 20, 2017, at 2:23 PM, davel...@mac.com wrote:
>> 
>> NSURL *url = [[self courseDirectory] URLByAppendingPathComponent:name];
> 
> There’s nothing wrong with that call; it’s the canonical way to add a path 
> component to a URL, filesystem or not.
> 
>> NSURL *url = [NSURL fileURLWithFileSystemRepresentation:[name 
>> fileSystemRepresentation] isDirectory:YES relativeToURL:[self 
>> courseDirectory]];
> 
> This call doesn’t make sense. You’re converting to filesystem representation 
> and then back again, for no reason.
> 
> What Apple suggested is to Unicode-normalize the filename before adding it to 
> the URL. Did you try doing that?
> 
> —Jens

Jens,

I’m trying to find out what that means. Someone suggested off-list to me that I 
should be calling this:

https://developer.apple.com/reference/foundation/nsstring/1409474-decomposedstringwithcanonicalmap?language=objc

Is that correct?

So based on that, I think it means I should do:

NSURL *url = [[self courseDirectory] 
URLByAppendingPathComponent:name.decomposedStringWithCanonicalMapping];

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

Handling Cocoa Bindings over a tree of View Controllers

[Daryle Walker]

A design for my third window iteration involves using several NSViewController 
subclasses in a UI tree. The current (i.e. second) version just has the root 
NSViewController and a bunch of NSView objects. There is a NSObjectController 
and a NSArrayController to bind the various view objects to my CoreData-based 
document data. 

Since all the objects are together, I can make a big Bindings network. The new 
design would spread the components. I need the object controllers to 
synchronize their editing notifications. I'm wondering how.

I'm half asleep, but I'm thinking of starting with the NSWindowController with 
a reference to the model and one NSObjectController. That object controller 
points to the model and it's managed context. For all the NSViewControllers in 
the tree, they'll use the first object controller as their represented object 
and reference it for their Bindings needs. Would that work?

Sent from my iPhone
___

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

[Jean-Daniel]

> Le 21 mars 2017 à 12:03, davel...@mac.com a écrit :
> 
>> 
>> On Mar 21, 2017, at 1:06 AM, Jens Alfke  wrote:
>> 
>> 
>>> On Mar 20, 2017, at 2:23 PM, davel...@mac.com wrote:
>>> 
>>> NSURL *url = [[self courseDirectory] URLByAppendingPathComponent:name];
>> 
>> There’s nothing wrong with that call; it’s the canonical way to add a path 
>> component to a URL, filesystem or not.
>> 
>>> NSURL *url = [NSURL fileURLWithFileSystemRepresentation:[name 
>>> fileSystemRepresentation] isDirectory:YES relativeToURL:[self 
>>> courseDirectory]];
>> 
>> This call doesn’t make sense. You’re converting to filesystem representation 
>> and then back again, for no reason.
>> 
>> What Apple suggested is to Unicode-normalize the filename before adding it 
>> to the URL. Did you try doing that?
>> 
>> —Jens
> 
> Jens,
> 
> I’m trying to find out what that means. Someone suggested off-list to me that 
> I should be calling this:
> 
> https://developer.apple.com/reference/foundation/nsstring/1409474-decomposedstringwithcanonicalmap?language=objc
>  
> 
> 
> Is that correct?
> 
> So based on that, I think it means I should do:
> 
> NSURL *url = [[self courseDirectory] 
> URLByAppendingPathComponent:name.decomposedStringWithCanonicalMapping];
> 
> Thanks,
> Dave Reed
> 


This is what the reply suggest but that make no sens for me. If you are 
accessing the file using URL, that the work of the framework to convert the URL 
into the right file system representation.

That said, if using name.decomposedStringWithCanonicalMapping fix your problem, 
so go with it.


___

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

[Aandi Inston]

Is the question, what is canonical mapping? I'm going to assume it is, so I
can share what I found when I hit much the same issue. This is mostly from
memory so let's hope it's right.

Take the word Café. How many Unicode characters is this and what are they?
Turns out there are two answers. The last character as seen on screen is a
lower case e with an acute accent.
Let's ignore C,a,f as they are the same in all answers.  First answer: é is
'LATIN SMALL LETTER E WITH ACUTE' (U+00E9). We'll call this "composed". In
UTF-8 that's two bytes, 0xC3 0xA9. (This is the answer you'd often get, but
it's not the only answer, and not the one Apple filesystems like.)

Second answer uses an accent character. These are designed to appear in the
same space as another character. So combine "e" and an acute accent (like a
floating, slanted apostrophe) and we have "é". This means you could get the
same result from the two Unicode characters LATIN SMALL LETTER E (U+0065)
COMBINING ACUTE ACCENT (U+0301). We'll call this "decomposed". In UTF-8
that would be 0x65 0xCC 0x81: three bytes, two characters, combine to a
single character. (This is the one Apple filesystems like).

When you're typing in a word processor, or showing an alert, it hardly
matters how you create the e acute. Both look the same. But searching may
be a problem (not discussed) as may showing items in alphabetical order
(also not discussed).

Let's imagine now we have a filename Café. This could be represented in
UTF-8 bytes as 0x41 0x61 0x66 0xC3 0xA9 (composed), or as 0x41 0x61 0x66
0x65 0xCC 0x81 (decomposed). But ultimately there needs to be a set of bits
on disk, in a directory, saying the name of the file. When searching for a
file we could have three choices (a) these two composed/decomposed are
separate file names for two distinct files - whose name will look the same
(b) these are the same file, which means all file access by name, and
searching has to compose or decompose for comparison purposes (c) only one
is allowed and the other is rejected or invalid.

Where are we? A bit of (b) and a bit of (c). Finder and file dialogs always
decompose what is typed, and this is stored as the string of bits giving
the file name. It seems that some APIs will automatically decompose their
input, and others won't, and we may be in transition [to judge from the bug
response]. So for safety, use a method that decomposes. (Unicode define at
least two other types of de/composition, not discussed).

Apple calls decomposed "canonical". This is fine, except that Unicode
refers to both "canonical decomposition" (what Apple filenames need) and
 "canonical composition" (the opposite). So if handling names via an Apple
API made for filenames we are fine to talk of canonical file names. But if
handling names with a general Unicode API, we need to understand that this
means "canonical decomposition" rather than "canonical composition".

On 21 March 2017 at 11:03,  wrote:

>
> > What Apple suggested is to Unicode-normalize the filename before adding
> it to the URL. Did you try doing that?
>
> I’m trying to find out what that means.
___

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 21, 2017, at 8:33 AM, Jean-Daniel  wrote:
> 
> 
>> Le 21 mars 2017 à 12:03, davel...@mac.com a écrit :
>> 
>>> 
>>> On Mar 21, 2017, at 1:06 AM, Jens Alfke  wrote:
>>> 
>>> 
 On Mar 20, 2017, at 2:23 PM, davel...@mac.com wrote:
 
 NSURL *url = [[self courseDirectory] URLByAppendingPathComponent:name];
>>> 
>>> There’s nothing wrong with that call; it’s the canonical way to add a path 
>>> component to a URL, filesystem or not.
>>> 
 NSURL *url = [NSURL fileURLWithFileSystemRepresentation:[name 
 fileSystemRepresentation] isDirectory:YES relativeToURL:[self 
 courseDirectory]];
>>> 
>>> This call doesn’t make sense. You’re converting to filesystem 
>>> representation and then back again, for no reason.
>>> 
>>> What Apple suggested is to Unicode-normalize the filename before adding it 
>>> to the URL. Did you try doing that?
>>> 
>>> —Jens
>> 
>> Jens,
>> 
>> I’m trying to find out what that means. Someone suggested off-list to me 
>> that I should be calling this:
>> 
>> https://developer.apple.com/reference/foundation/nsstring/1409474-decomposedstringwithcanonicalmap?language=objc
>> 
>> Is that correct?
>> 
>> So based on that, I think it means I should do:
>> 
>> NSURL *url = [[self courseDirectory] 
>> URLByAppendingPathComponent:name.decomposedStringWithCanonicalMapping];
>> 
>> Thanks,
>> Dave Reed
>> 
> 
> This is what the reply suggest but that make no sens for me. If you are 
> accessing the file using URL, that the work of the framework to convert the 
> URL into the right file system representation.
> 
> That said, if using name.decomposedStringWithCanonicalMapping fix your 
> problem, so go with it.

Unfortunately, I can't tell. One user told me he couldn't open his files (with 
Arabic names) after upgrading to iOS 10.3 public beta. He then changed the 
names to English names and was able to open the files. He sent me some sample 
files that I can open (but they were zipped by my app and then unzipped by me) 
so I honestly can't tell if any of these changes have different effects. With 
all the options I've tried, I can open the files on my 10.2 and my 10.3 
developer device.

If he creates files with Arabic names on 10.3 he can open them so something 
happened in the 10.2 to 10.3 (which is why I suspect APFS) upgrade that 
prevents files created with 10.2 from being opened with 10.3.

My plan to test it is to take a file created with 10.2 using an Arabic name and 
see what happens when I upgrade my regular phone to 10.3 but obviously that's 
time consuming and I only plan to do that upgrade once since it's a pain to 
downgrade (and not certain it would be possible with the APFS change).

That's why I keep emailing about this - I can't test it and can't find specific 
documentation from Apple that says exactly how to create a NSURL from a 
NSString that may contain Unicode characters.

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: Handling Cocoa Bindings over a tree of View Controllers

[Keary Suska]

> On Mar 21, 2017, at 6:26 AM, Daryle Walker  wrote:
> 
> A design for my third window iteration involves using several 
> NSViewController subclasses in a UI tree. The current (i.e. second) version 
> just has the root NSViewController and a bunch of NSView objects. There is a 
> NSObjectController and a NSArrayController to bind the various view objects 
> to my CoreData-based document data. 
> 
> Since all the objects are together, I can make a big Bindings network. The 
> new design would spread the components. I need the object controllers to 
> synchronize their editing notifications. I'm wondering how.
> 
> I'm half asleep, but I'm thinking of starting with the NSWindowController 
> with a reference to the model and one NSObjectController. That object 
> controller points to the model and it's managed context. For all the 
> NSViewControllers in the tree, they'll use the first object controller as 
> their represented object and reference it for their Bindings needs. Would 
> that work?

You didn’t sat whether your data model is monolithic (e.g. all properties of a 
single object) or a strcutured collection of objects, but in any case I have 
implemented similar structures and I would say that, generally, if your design 
warrants distinct component views, then your data model also warrants 
encapsulating the corresponding data components. I.e. the data structure would 
mirror the view structure to some extent. This isn’t necessary, but IMHO is 
clearer. Worst case you simply set every view controller’s representedObject to 
the entire document model. 

I don’t recommend creating complex binding chains as they can be difficult to 
manage and debug. You only need an object controller for each view, and there 
is no need for controllers to synchronize as that will happen automatically 
with model changes.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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

Odd UILabel behavior on tvOS

[Eric E. Dolecki]

I have a view & I update a label within it. Super simple.

My string is like
label.text = "Connecting to \"\(useName)\""

I want the double quotes around that variable. As soon as the useName
variable (a string) is inserted, anything after that does not go into the
label.

label.text = "Connecting to \"\(useName) muwahahaha"
- no muwahahaha in the label.

What might be happening? I feel stupid here.
___

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

Printing in Swift

[David Delmonte]

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.


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.

Thanks
___

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: Odd UILabel behavior on tvOS

[Eric E. Dolecki]

Sorry. My argument name to set the string was "string" and that prevented
operation evidently.

On Tue, Mar 21, 2017 at 10:43 AM Eric E. Dolecki  wrote:

> I have a view & I update a label within it. Super simple.
>
> My string is like
> label.text = "Connecting to \"\(useName)\""
>
> I want the double quotes around that variable. As soon as the useName
> variable (a string) is inserted, anything after that does not go into the
> label.
>
> label.text = "Connecting to \"\(useName) muwahahaha"
> - no muwahahaha in the label.
>
> What might be happening? I feel stupid here.
>
___

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

[Giacomo Tufano]

If Apple Support says (as It said) "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.” then I think that the solution will be to 
decompose the bytes so that the “bag of bytes” or the “normalized names” are 
the same. From the name of the API I *suppose* that [NSString 
decomposedStringWithCanonicalMapping] will do, but it needs to be tested, 
because the point is that on APFS you need to apply the same (de)composition 
that iOS HFS does (so to have the same bytes when asking for the file name).
Btw: I think this is a significant difference in filename management that I 
think will bite many developers, it should be fixed at file system level, IMHO… 
but who knows what the other implication are… 

My 2 €cents,
Gt

> Il giorno 21 mar 2017, alle ore 15:18, Aandi Inston  ha 
> scritto:
> 
> Is the question, what is canonical mapping? I'm going to assume it is, so I
> can share what I found when I hit much the same issue. This is mostly from
> memory so let's hope it's right.
> 
> Take the word Café. How many Unicode characters is this and what are they?
> Turns out there are two answers. The last character as seen on screen is a
> lower case e with an acute accent.
> Let's ignore C,a,f as they are the same in all answers.  First answer: é is
> 'LATIN SMALL LETTER E WITH ACUTE' (U+00E9). We'll call this "composed". In
> UTF-8 that's two bytes, 0xC3 0xA9. (This is the answer you'd often get, but
> it's not the only answer, and not the one Apple filesystems like.)
> 
> Second answer uses an accent character. These are designed to appear in the
> same space as another character. So combine "e" and an acute accent (like a
> floating, slanted apostrophe) and we have "é". This means you could get the
> same result from the two Unicode characters LATIN SMALL LETTER E (U+0065)
> COMBINING ACUTE ACCENT (U+0301). We'll call this "decomposed". In UTF-8
> that would be 0x65 0xCC 0x81: three bytes, two characters, combine to a
> single character. (This is the one Apple filesystems like).
> 
> When you're typing in a word processor, or showing an alert, it hardly
> matters how you create the e acute. Both look the same. But searching may
> be a problem (not discussed) as may showing items in alphabetical order
> (also not discussed).
> 
> Let's imagine now we have a filename Café. This could be represented in
> UTF-8 bytes as 0x41 0x61 0x66 0xC3 0xA9 (composed), or as 0x41 0x61 0x66
> 0x65 0xCC 0x81 (decomposed). But ultimately there needs to be a set of bits
> on disk, in a directory, saying the name of the file. When searching for a
> file we could have three choices (a) these two composed/decomposed are
> separate file names for two distinct files - whose name will look the same
> (b) these are the same file, which means all file access by name, and
> searching has to compose or decompose for comparison purposes (c) only one
> is allowed and the other is rejected or invalid.
> 
> Where are we? A bit of (b) and a bit of (c). Finder and file dialogs always
> decompose what is typed, and this is stored as the string of bits giving
> the file name. It seems that some APIs will automatically decompose their
> input, and others won't, and we may be in transition [to judge from the bug
> response]. So for safety, use a method that decomposes. (Unicode define at
> least two other types of de/composition, not discussed).
> 
> Apple calls decomposed "canonical". This is fine, except that Unicode
> refers to both "canonical decomposition" (what Apple filenames need) and
> "canonical composition" (the opposite). So if handling names via an Apple
> API made for filenames we are fine to talk of canonical file names. But if
> handling names with a general Unicode API, we need to understand that this
> means "canonical decomposition" rather than "canonical composition".
> 
> On 21 March 2017 at 11:03,  wrote:
> 
>> 
>>> What Apple suggested is to Unicode-normalize the filename before adding
>> it to the URL. Did you try doing that?
>> 
>> I’m trying to find out what that means.
> ___
> 
> 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/gt%40iltofa.com
> 
> This email sent to g...@iltofa.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...@ma

Re: Unicode filenames with Apple File System and UIManagedDocument

[Charles Srstka]

> On Mar 21, 2017, at 9:13 AM, davel...@mac.com wrote:
> 
>> 
>> On Mar 21, 2017, at 8:33 AM, Jean-Daniel > > wrote:
>> 
>> 
>>> Le 21 mars 2017 à 12:03, davel...@mac.com a écrit :
>>> 
 
 On Mar 21, 2017, at 1:06 AM, Jens Alfke  wrote:
 
 
> On Mar 20, 2017, at 2:23 PM, davel...@mac.com wrote:
> 
> NSURL *url = [[self courseDirectory] URLByAppendingPathComponent:name];
 
 There’s nothing wrong with that call; it’s the canonical way to add a path 
 component to a URL, filesystem or not.
 
> NSURL *url = [NSURL fileURLWithFileSystemRepresentation:[name 
> fileSystemRepresentation] isDirectory:YES relativeToURL:[self 
> courseDirectory]];
 
 This call doesn’t make sense. You’re converting to filesystem 
 representation and then back again, for no reason.
 
 What Apple suggested is to Unicode-normalize the filename before adding it 
 to the URL. Did you try doing that?
 
 —Jens
>>> 
>>> Jens,
>>> 
>>> I’m trying to find out what that means. Someone suggested off-list to me 
>>> that I should be calling this:
>>> 
>>> https://developer.apple.com/reference/foundation/nsstring/1409474-decomposedstringwithcanonicalmap?language=objc
>>> 
>>> Is that correct?
>>> 
>>> So based on that, I think it means I should do:
>>> 
>>> NSURL *url = [[self courseDirectory] 
>>> URLByAppendingPathComponent:name.decomposedStringWithCanonicalMapping];
>>> 
>>> Thanks,
>>> Dave Reed
>>> 
>> 
>> This is what the reply suggest but that make no sens for me. If you are 
>> accessing the file using URL, that the work of the framework to convert the 
>> URL into the right file system representation.
>> 
>> That said, if using name.decomposedStringWithCanonicalMapping fix your 
>> problem, so go with it.
> 
> Unfortunately, I can't tell. One user told me he couldn't open his files 
> (with Arabic names) after upgrading to iOS 10.3 public beta. He then changed 
> the names to English names and was able to open the files. He sent me some 
> sample files that I can open (but they were zipped by my app and then 
> unzipped by me) so I honestly can't tell if any of these changes have 
> different effects. With all the options I've tried, I can open the files on 
> my 10.2 and my 10.3 developer device.
> 
> If he creates files with Arabic names on 10.3 he can open them so something 
> happened in the 10.2 to 10.3 (which is why I suspect APFS) upgrade that 
> prevents files created with 10.2 from being opened with 10.3.
> 
> My plan to test it is to take a file created with 10.2 using an Arabic name 
> and see what happens when I upgrade my regular phone to 10.3 but obviously 
> that's time consuming and I only plan to do that upgrade once since it's a 
> pain to downgrade (and not certain it would be possible with the APFS change).
> 
> That's why I keep emailing about this - I can't test it and can't find 
> specific documentation from Apple that says exactly how to create a NSURL 
> from a NSString that may contain Unicode characters.
> 
> Thanks,
> Dave Reed

Maybe you could make a debug build and send it to him (can you do that on iOS?) 
with some code that logs the raw Unicode characters of the filenames in the 
directory, without the name getting changed/decomposed/recomposed/etc by the 
zip/unzip process, and have him send you the output. Something like:

void LogFilenames(NSURL *url) {
DIR *dir = opendir(url.fileSystemRepresentation);

struct dirent *file;
while ((file = readdir(dir))) {
NSData *nameData = [[NSData alloc] initWithBytes:file->d_name 
length:file->d_namlen];

NSLog(@"%@", nameData);
}

closedir(dir);
}

This’ll be in UTF-8 instead of the underlying UTF-16, of course, but it should 
still be useful in figuring out what’s going on.

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

[Alastair Houghton]

On 21 Mar 2017, at 12:33, Jean-Daniel  wrote:
> 
> This is what the reply suggest but that make no sens for me. If you are 
> accessing the file using URL, that the work of the framework to convert the 
> URL into the right file system representation.

Agreed, IMO the framework should be responsible for Unicode normalisation.  
It’s only at the BSD layer where you *might* be responsible for it yourself, 
but this isn’t about making BSD API calls, right?  It’s the Cocoa API we’re 
dealing with here.

This *should* be abstracted.  If it isn’t, it’s a bug.

(Having vaguely followed this thread for a while, if I had to guess what 
happened here, I’d guess there’s some kind of bug in the HFS+ to APFS upgrade 
routine that’s causing the Unicode filenames from the HFS+ system to get messed 
up somehow.)

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: UITextField width of UIAlertController -addTextFieldWithConfigurationHandler:

[Carl Hoefs]

Thanks for the hint. In the debugger I discovered that what looks to be a 
UITextField displayed across the bottom of the alert is actually implemented as 
a private object of class UIAlertControllerTextField.

So I can restrict the text to a portion of the textfield, but I can't find a 
way to shorten the textfield's displayed width. Setting UIBorderStyleNone also 
has no effect. I can change the font characteristics, but no layout/display 
characteristics of the "textfield" itself appear to be directly changeable. 

-Carl


> On Mar 20, 2017, at 10:05 PM, Saagar Jha  wrote:
> 
> I haven’t tested this, but have you tried calling [self layoutIfNeeded] in 
> the completion block of [self presentViewController:animated:completion]?
> 
> Saagar Jha
> 
>> On Mar 20, 2017, at 16:09, Carl Hoefs > > wrote:
>> 
>> iOS 10.2.1
>> 
>> I'm using UIAlertController -addTextFieldWithConfigurationHandler: to 
>> display an alert with a textfield. 
>> 
>> Is there any way to shorten the width of the displayed textfield? I've tried 
>> setting its frame/bounds, but it has no effect.
>> 
>> -Carl
>> 
>> ___
>> 
>> 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: UITextField width of UIAlertController -addTextFieldWithConfigurationHandler:

[Carl Hoefs]

Alternately, is there a way to configure the alert to defer the launch of the 
keyboard until/unless the user wants to edit the textfield (by touching it)? 
Generally it won't need to be edited, maybe just the first time or so, thus 
having the keyboard always coming up would be distracting.

- Carl

> On Mar 21, 2017, at 12:12 PM, Carl Hoefs  
> wrote:
> 
> Thanks for the hint. In the debugger I discovered that what looks to be a 
> UITextField displayed across the bottom of the alert is actually implemented 
> as a private object of class UIAlertControllerTextField.
> 
> So I can restrict the text to a portion of the textfield, but I can't find a 
> way to shorten the textfield's displayed width. Setting UIBorderStyleNone 
> also has no effect. I can change the font characteristics, but no 
> layout/display characteristics of the "textfield" itself appear to be 
> directly changeable. 
> 
> -Carl
> 
> 
>> On Mar 20, 2017, at 10:05 PM, Saagar Jha  wrote:
>> 
>> I haven’t tested this, but have you tried calling [self layoutIfNeeded] in 
>> the completion block of [self presentViewController:animated:completion]?
>> 
>> Saagar Jha
>> 
>>> On Mar 20, 2017, at 16:09, Carl Hoefs >> > wrote:
>>> 
>>> iOS 10.2.1
>>> 
>>> I'm using UIAlertController -addTextFieldWithConfigurationHandler: to 
>>> display an alert with a textfield. 
>>> 
>>> Is there any way to shorten the width of the displayed textfield? I've 
>>> tried setting its frame/bounds, but it has no effect.
>>> 
>>> -Carl
>>> 
>>> ___
>>> 
>>> 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/newslists%40autonomy.caltech.edu
> 
> This email sent to newsli...@autonomy.caltech.edu


___

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: UITextField width of UIAlertController -addTextFieldWithConfigurationHandler:

[Saagar Jha]

That should be lot easier; just set yourself as the text field’s delegate and 
override textFieldShouldBeginEditing.
Saagar Jha

> On Mar 21, 2017, at 12:24, Carl Hoefs  wrote:
> 
> Alternately, is there a way to configure the alert to defer the launch of the 
> keyboard until/unless the user wants to edit the textfield (by touching it)? 
> Generally it won't need to be edited, maybe just the first time or so, thus 
> having the keyboard always coming up would be distracting.
> 
> - Carl
> 
>> On Mar 21, 2017, at 12:12 PM, Carl Hoefs > > wrote:
>> 
>> Thanks for the hint. In the debugger I discovered that what looks to be a 
>> UITextField displayed across the bottom of the alert is actually implemented 
>> as a private object of class UIAlertControllerTextField.
>> 
>> So I can restrict the text to a portion of the textfield, but I can't find a 
>> way to shorten the textfield's displayed width. Setting UIBorderStyleNone 
>> also has no effect. I can change the font characteristics, but no 
>> layout/display characteristics of the "textfield" itself appear to be 
>> directly changeable. 
>> 
>> -Carl
>> 
>> 
>>> On Mar 20, 2017, at 10:05 PM, Saagar Jha  wrote:
>>> 
>>> I haven’t tested this, but have you tried calling [self layoutIfNeeded] in 
>>> the completion block of [self presentViewController:animated:completion]?
>>> 
>>> Saagar Jha
>>> 
 On Mar 20, 2017, at 16:09, Carl Hoefs >>>  
 >> wrote:
 
 iOS 10.2.1
 
 I'm using UIAlertController -addTextFieldWithConfigurationHandler: to 
 display an alert with a textfield. 
 
 Is there any way to shorten the width of the displayed textfield? I've 
 tried setting its frame/bounds, but it has no effect.
 
 -Carl
 
 ___
 
 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/newslists%40autonomy.caltech.edu
>>  
>> 
>> 
>> This email sent to newsli...@autonomy.caltech.edu 
>> 
___

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: UITextField width of UIAlertController -addTextFieldWithConfigurationHandler:

[Carl Hoefs]

Thanks, that got it going.  It's a compromise. Maybe the options will be 
expanded in future iOS releases...
-Carl

> On Mar 21, 2017, at 12:39 PM, Saagar Jha  wrote:
> 
> That should be lot easier; just set yourself as the text field’s delegate and 
> override textFieldShouldBeginEditing.
> Saagar Jha
> 
>> On Mar 21, 2017, at 12:24, Carl Hoefs > > wrote:
>> 
>> Alternately, is there a way to configure the alert to defer the launch of 
>> the keyboard until/unless the user wants to edit the textfield (by touching 
>> it)? Generally it won't need to be edited, maybe just the first time or so, 
>> thus having the keyboard always coming up would be distracting.
>> 
>> - Carl
>> 
>>> On Mar 21, 2017, at 12:12 PM, Carl Hoefs >> > wrote:
>>> 
>>> Thanks for the hint. In the debugger I discovered that what looks to be a 
>>> UITextField displayed across the bottom of the alert is actually 
>>> implemented as a private object of class UIAlertControllerTextField.
>>> 
>>> So I can restrict the text to a portion of the textfield, but I can't find 
>>> a way to shorten the textfield's displayed width. Setting UIBorderStyleNone 
>>> also has no effect. I can change the font characteristics, but no 
>>> layout/display characteristics of the "textfield" itself appear to be 
>>> directly changeable. 
>>> 
>>> -Carl
>>> 
>>> 
 On Mar 20, 2017, at 10:05 PM, Saagar Jha >>> > wrote:
 
 I haven’t tested this, but have you tried calling [self layoutIfNeeded] in 
 the completion block of [self presentViewController:animated:completion]?
 
 Saagar Jha
 
> On Mar 20, 2017, at 16:09, Carl Hoefs   
>  >> wrote:
> 
> iOS 10.2.1
> 
> I'm using UIAlertController -addTextFieldWithConfigurationHandler: to 
> display an alert with a textfield. 
> 
> Is there any way to shorten the width of the displayed textfield? I've 
> tried setting its frame/bounds, but it has no effect.
> 
> -Carl
> 
> ___
> 
> 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/newslists%40autonomy.caltech.edu
>>>  
>>> 
>>> 
>>> This email sent to newsli...@autonomy.caltech.edu 
>>> 

___

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 20, 2017, at 14:23 , davel...@mac.com wrote:
> 
> "iOS HFS Normalized UNICODE names , APFS now treats all file[ name]s 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."

I’ve been letting this simmer for a couple of days now, and I’ve come to the 
conclusion that it’s — sincere apologies to the unnamed Apple engineer who 
wrote it — as dumb as dirt.

— It’s not a "bag of bytes”, because bags of stuff are generally understood as 
unordered sets, and I doubt that’s what’s intended. It has to be a sequence of 
bytes.

— It’s not a sequence of bytes, because *everything* is a sequence of bytes, 
except perhaps things that are just a sequence of bits. It’s a sequence of 
bytes that represents a human-readable name. We have a word for that already: 
string.

— It’s not just a string, it has to be a string in a known encoding. Otherwise, 
how could you ever mount an external drive on a different computer? The 
encoding has to be pre-specified for APFS, or it has to be stored in metadata 
on each volume.

— It’s not just going to be a string of known encoding, it’s going to be 
Unicode. That’s going to be true even if the fact is specified in volume 
metadata and it’s theoretically possible to create APFS volumes with 
non-Unicode file names. Anything other than Unicode would, at this point, be a 
crime against humanity.

— It’s not just going to be Unicode, it’s going to be UTF-8 or UTF-16 or 
UTF-32. Again, it might be one of these code-point sizes by definition, or any 
of them according to volume or file metadata. If the code point size isn’t 
determinable in one of these ways, the names cannot be interpreted.

— Ditto endianness (for UTF-16 or UTF-32).

— What we’re left with is that, apparently, APFS is a normalization-sensitive 
file system (by analogy with the case-sensitive file system that iOS already 
has): it’s capable of giving different files the same names, that differ only 
in capitalization and normalization. Except, no. There’s no “correct” or 
“incorrect” for iOS file name capitalization — you can create and use files 
following your own private rules for capitalization — but according to the 
above quote it is “correct” to normalize APFS file names, and presumably 
incorrect to leave them unnormalized.

— So, if unnormalized names are not “correct”, then it’s not a 
normalization-sensitive file system either.

— What are we left with? Well, the same file naming system as iOS HFS+, with 
the actual normalization left out. Great. No developer is ever going to forget 
to handle that, right?

Is that the bottom line? Actually, no. Here’s the bottom line:

— If Apple did this, *every* existing app would instantly break. All of them. 
(The only exceptions perhaps being apps that don’t ever construct a path string 
or URL.) That’s apparently what happened to Dave. His perfectly correct app 
*broke*.

Is *that* the bottom line? I doubt it. I don’t believe the above quoted 
statement can be correct. I could believe that normalization is being moved out 
of the file system code, but it would have to be moved to (e.g.) the Cocoa 
frameworks, still “downstream” of the file-handling APIs. It can’t go upstream 
of the public APIs without breaking an API contract that has existed for the 
16+ years since OS X 10.0.

Is there anything wrong with my reasoning here?

___

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