Re: Cocoa framework or Object class to uncompress files

[Quincey Morris via Cocoa-dev]

No. There’s no solution there. The Archive framework makes uncompressing of raw 
data easy, including the compression format that’s normally used inside .zip 
files, but it doesn’t actually read .zip file format. The file format and the 
compression algorithm are, in effect, unrelated to each other.

It’s not extremely hard to read the .zip file format directly, though there’s 
not really a single standard of which parts of the spec actually need to be 
implemented. I implemented something based on this:

https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

but the implementation is not mine to give away, sorry.

> On Oct 24, 2022, at 19:19, Marco S Hyman via Cocoa-dev 
>  wrote:
> 
>> I'm hoping there's a built-in solution or framework that I'm just 
>> overlooking.
> 
> Guess: The Apple Archive framework
> 
> https://developer.apple.com/documentation/applearchive

___

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: Building for 10.12

[Quincey Morris via Cocoa-dev]

(Resending because I forgot to cc the list)

On Mar 20, 2022, at 08:09, Gabriel Zachmann via Cocoa-dev 
mailto:cocoa-dev@lists.apple.com>> wrote:
> 
> Apparently, this caused it:
> 
> Symbol not found: _AVAudioSessionInterruptionNotification
> 
> Yes, I am using that function, and yes, it seems to be available only on 
> macOS 11 and higher.

AVAudioSession doesn’t exist on macOS, in any version. I see that the 
documentation page for AVAudioSessionInterruptionNotification lists it 
incorrectly as supported on macOS 11+, but I can’t find anything in the SDK 
headers to suggest where that incorrect information came from.

The real question is how the macOS target compiled at all. Can you shed any 
light on how you got as far as linking, with an unknown 
_AVAudioSessionInterruptionNotification symbol in your target?
___

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: Security scoped bookmarks example?

[Quincey Morris via Cocoa-dev]

On Mar 4, 2020, at 06:12 , Gabriel Zachmann via Cocoa-dev 
 wrote:
> 
>// load new image from disk
>NSURL * url = [NSURL fileURLWithPath: [self absolutePathFor: filename_] 
> isDirectory: NO];  
>// filename_ is one of the paths from the list of images under the user 
> selected directory
>// at this point, url is a proper URL, I have checked
> 
>[url startAccessingSecurityScopedResource];
>CGImageSourceRef sourceRef = CGImageSourceCreateWithURL( (CFURLRef) url, 
> NULL );

This isn’t even nearly correct. You *must* call 
“startAccessingSecurityScopedResource” on a URL that was reconstituted from a 
security scoped bookmark. According to this, you called it on a URL that you 
arbitrarily created. Why would you even expect that to work? If it did, then 
you could access any file without user permission, and security scoped URLs 
would have no purpose.

> I create the SSB like this:
> 
>directoryBookmark_ = [dir bookmarkDataWithOptions: 
> NSURLBookmarkCreationWithSecurityScope | 
> NSURLBookmarkCreationSecurityScopeAllowOnlyReadAccess
>   includingResourceValuesForKeys: nil
>relativeToURL: nil
>error: ];

So, you created a security scoped bookmark, then what did you do with it? You 
should store it in user defaults, then load it from user defaults the next time 
your code starts up, reconstitute it back into a security scoped URL, and then 
use *that* URL (literally that object, not a different instance based on the 
same path) as the base URL for all the image file URLs you need.

Note that you don’t need the bookmark to be reconstituted while your code is 
still running after using the open panel, because the URL that the open panel 
returns is *already* a security scoped URL in the current process. You only 
need to use the bookmark if your code starts up again in a new process.

Note also that you must not *re*-create the bookmark from a reconstituted URL. 
That doesn’t work. You must create the security scoped bookmark *only* from the 
fresh URL that the open panel gives you. Store it once, then keep 
reconstituting it as needed.
___

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: Confusion about screen resolution

[Quincey Morris via Cocoa-dev]

On Feb 22, 2020, at 20:56 , Richard Charles  wrote:
> 
> I am just curious, have you actually seen a 3X backing store or is this just 
> a surmise?

Well, I can never remember what I’ve actually seen, so I just threw it in 
there. :) It’s used on iOS, but maybe not Mac.

___

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: Confusion about screen resolution

[Quincey Morris via Cocoa-dev]

On Feb 22, 2020, at 15:31 , Gabriel Zachmann via Cocoa-dev 
 wrote:
> 
> I was always under the impression that the backing store is 2x the size of 
> the display.
> That should be then 2x( 2880 x 1800 ), i.e., 5760 x 3600 , shouldn't it?
> 
> So, either the frameRect should be 2880x1800  or 5760 x 3600 , both would 
> make sense to me.

As multiple people have said, this isn’t true any more.

If you go to the Displays pane of System Preferences, and choose the Scaled 
option, you will see (at least, I see on a 27” iMac) 5 different size settings. 
Each one of the represents a different screen size *in points*. The smaller the 
dimensions in points, the larger a point is, since the point size is 
“stretched” to fit the physical display.

The way things are now, starting from the selected Displays pane point size, 
whatever that happens to be, the backing store is 2x or 3x — an integral scale 
*up* — and the result is scaled — typically *down* by a non-integral amount — 
to the hardware physical pixel dimensions of the screen.

None of this should matter to your code.

> I am just curious, how do they do that given the fact that they first render 
> it into a backing store and then scale it down by some very odd factor, which 
> is definitely not 2 or 1 or some other similar "easy" case. How is that I am 
> not seeing any resampling artefacts.

It works because of the implicit scaling up to an abnormally high resolution in 
the backing store. The introduces enough detail so that the fractional 
scale-down factor looks great in most cases. (However, if you try some of the 
extreme scaled Display resolutions, you’ll probably think they look a bit soft 
or fuzzy.)

___

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 of paths through sandbox

[Quincey Morris via Cocoa-dev]

On Feb 12, 2020, at 08:56 , Gabriel Zachmann  wrote:
> 
> So rather than having the last part being chopped off (which is the important 
> part),
> I would like to remove the beginning of the path, since that is unimportant.

For partial paths, you can try converting the URLs to URLComponents, then 
constructing a relative URL whose base URL is the directory you searched in. 
That might give you a relative path that you can display.

If that doesn’t give a suitable result, you’ll have to do a bit of work, but 
not much. Starting from a file URL, starting taking the last component of the 
URL (property “lastPathComponent”), and building it up into a path string. Keep 
removing the last component until the shortened URL equals the pictures 
directory.

That’s a bit hand-wavy on the details, but it shouldn’t be too hard to code.

___

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 of paths through sandbox

[Quincey Morris via Cocoa-dev]

On Feb 11, 2020, at 09:00 , Gabriel Zachmann via Cocoa-dev 
 wrote:
> 
> I have a question regarding the proper handling of paths under Catalina,
> some of which go through the Container, some don't.
> 
> More specifically, I get the Pictures folder using this line of code:
> 
>  dir_to_scan = [NSHomeDirectory() stringByAppendingPathComponent: 
> @"Pictures/"]

Well, don’t do that. :)

Instead, use one of the two NSFileManager methods that find the Pictures 
directory for you:

URLsForDirectory:inDomains:
URLForDirectory:inDomain:appropriateForURL:create:error:

(You can specify nil for the “appropriateForURL” parameter.) Specify 
NSPicturesDirectory for the directory parameter, and NSUserDomainMask for the 
domain.

Note that the documentation says you can use URLs in the query’s search scopes, 
so you don’t need to convert to paths at all.

> This gives me a path like
> /Users/zach/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Pictures

> EXCEPT, apparently, Spotlight gives me paths starting with 
> /Users/zach/Pictures !
> (which does make some sense.)

Yes, some of the items in the container, which are named as if they are 
standard directories, are actually symbolic links to the real directories 
outside the container.

> Problem is that I can't just do
> 
>   [ array_with_all_images addObject: [path substringFromIndex: ([dir_to_scan 
> length] + 1)] ];

What is this supposed to be an array of? File names? Partial paths underneath 
~/Pictures? If the latter, why get partial paths at all, why not just make an 
array of URLs?


___

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: Swift -> Obj-C: return __kindof Something

[Quincey Morris via Cocoa-dev]

There’s now a Swift equivalent (loosely): “some NSManagedObject”. It’s 
sometimes referred to as a “reverse generic”, or “opaque type” because it hides 
the actual type behind a larger class type or protocol. The evolution proposal 
is here, if you want all the gory details:


https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md
 


The problem is, it was designed mainly for return types, and I’m not sure it’s 
entirely easy to use for a stored property. On top of that, it may not work 
with an optional base type.

Still, it might be worth looking into. Again, ask on the Swift forum for 
guidance. You’ll get good answers.

> On Nov 11, 2019, at 18:06 , Steve Christensen  wrote:
> 
> I’m trying to get the same class-or-subclass behavior during compilation.

___

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: Thoughts on Objective-C++

[Quincey Morris via Cocoa-dev]

On Nov 11, 2019, at 17:05 , Turtle Creek Software via Cocoa-dev 
 wrote:
> 
> I didn't mean to start a language war, because it's not about C++ vs
> Objective-C or Swift.

I’ve been staying out of this, because you’ve seemed impervious (in the last 
few weeks since this topic has been discussed) to acknowledge any opinion other 
than your own. Now I’m just angry.

*Of course* you meant to start a language war. You said:

> I was originally going to post about how modern C++ has far surpassed
> Objective-C. Then suggest that Cocoa would work better if Obj-C were a
> superset of C++ rather than plain C.

Them’s fighting words — especially in a space like this that is inhabited by 
other highly opinionated people. If you don’t want to start a language war, 
stop posting here and go away.

The other thing you said:

> However, after consideration, it seems obvious that Apple will never do
> that. Instead, Objective-C and Cocoa will be deprecated soon, replaced by
> Swift and SwiftUI. That way there is just one shiny new closed system for
> all Apple hardware. So much simpler.

is both clueless and passive aggressive. Enough already.

___

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: Preventing app from being restored or saving info in "Saved Application State"

[Quincey Morris via Cocoa-dev]

On Nov 10, 2019, at 17:39 , Lars C. Hassing via Cocoa-dev 
 wrote:
> 
> I believe data in "~/Library/Saved Application State" is being used for this,
> how can I programmatically in app two tell that restoration is not useful ?
> 
> I’ve tried myMainWindow.restorable = NO.

The thing that’s relaunching your app isn’t state restoration, which is only 
about restoring state of and within windows.

If you’re talking about the “Reopen” button in the dialog that says your app 
crashed, I think that’s CrashReporter or some similar system component, and I’m 
not aware of any way of controlling the buttons it offers you.

So, the answer depends on what you’re asking.

— If you’re asking whether it’s possible to suppress the option to relaunch the 
crashed app, then no, I don’t believe there is.

— If you’re asking whether it’s possible for the app to suppress state 
restoration, if it’s launched via *any* unexpected mechanism, then I think 
you’re barking up the wrong tree. It’s just as wrong for your app to relaunch 
without state restoration as it to relaunch with state restoration. You would 
need to find a way of detecting that it was not launched by the correct base 
app (e.g. inter-process communication with that app, if it’s running), but I 
doubt there’s any built-in thing you could use for that either.

___

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: Swift -> Obj-C: return __kindof Something

[Quincey Morris via Cocoa-dev]

> On Nov 11, 2019, at 15:07 , Steve Christensen via Cocoa-dev 
>  wrote:
> 
> Some existing Obj-C methods are of the form:
> 
>   + (nullable __kindof NSManagedObject) someFooThing;
> 
> Right now I have
> 
>   class var someFooThing: NSManagedObject?

AFAIK, “__kindof” only affects the ability to assign one Obj-C class pointer to 
a variable of a different but compatible (kind of) type. It doesn’t change the 
actual type of the variable, nor does it (again AFAIK) change the ability to 
assign without errors in Swift. Also see here for some informative discussion:

https://stackoverflow.com/questions/31399208/ios-kindof-nsarray 


I suggest you ask about this on forums.swift.org . If 
there’s an alternative, someone there will know.

___

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: Need for Swift

[Quincey Morris via Cocoa-dev]

OK, apologies in advance for toes trodden on or sensibilities offended, but it 
sounds like it’s time for my anti-optional-whining rant. :)

The really important thing about using Swift is that you *have to* learn to 
change the way you think about dealing with nil values. It’s not quite 
literally true (but it’s close) that in Obj-C you want to defer dealing with 
nil values *as long as possible*, while in Swift you want to deal with nil 
values *immediately*.

Putting this another way, the rule you should live and breathe is, “Don’t let 
optionals propagate through your code.”

There are some exceptions to this principle. For example, if you’re parsing a 
name string for first, middle and last name, and the middle name is optional, 
you might well choose to carry the middle name forward as `String?` (an 
optional string). But you should typically start by writing your code as if 
there are no optionals, and eliminate/resolve them as they appear.

For example, it’s a really bad idea to write code like this:

let url = URL(string: “some string”)
/* … things involving `url?` … */

It’s much better to deal with the optional right away. For example:

let url = URL(string: “some string”)! // no more optional, when your 
URL string is known good

Or, if your string can be genuinely an invalid URL string:

guard let url = URL(string: “some string”) else { /* deal with the 
error condition and … */; return } // or break or whatever

Not only does it take practice to remember to do things this way round, but 
also I *guarantee* you that it will throw your tried and trusted Obj-C code 
design patterns into chaos. You must, I’m afraid, suffer through this, long 
enough until your brain “flips” and starts pouring out code that is Swift-like 
in Swift, not Obj-C-like in Swift.

It actually took me about a year, back in the Swift 2 days, to figure out that 
I needed to write Swift like Swift, not like Obj-C, and a year or two to get 
comfortable with that. But I was slow and stupid: it shouldn’t really need to 
take that long. It just takes a willingness to spend time writing and rewriting 
sections of code until you get to that “Aha!” moment. That’s when you will 
become a Swift fan.

There’s nothing truly wrong with Obj-C as a language, and there’s no need to 
diss it in order to appreciate Swift. But the two have different coding 
patterns, and if you want to use Swift professionally you will need to learn 
and practice its natural coding patterns. (If you don’t, that’s fine too!)

People have been offering opinions all day of what Swift is like, compared to 
other languages. One point that doesn’t get mentioned is that Swift was 
intended to fill the hole where (so to speak) Obj-C 3.0 or 4.0 would go. A lot 
of its syntax and philosophy is intended to do what we did comfortably in 
Obj-C, but with more efficiency in the task of actual code writing. It’s 
evolved away from Obj-C in some fairly weird ways, but I’ll happily defend my 
belief that it *is* a more efficient way to write code.

I loved Obj-C for 15 years (or so). Now I write Swift almost exclusively.

/end rant

> On Oct 14, 2019, at 20:44 , Laurent Daudelin via Cocoa-dev 
>  wrote:
> 
> I’ve been wondering the same thing. I thought that maybe because I was biased 
> toward Obj-C. But if it wasn’t for the editor, damn, I don’t know how many 
> times I would have to go back to unwrap one of those optionals. Are people 
> supposed to know instinctively when you unwrap with “?” and when you do with 
> “!”? I’m not there yet, even though I’ve been doing almost a year of Swift so 
> far...

___

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: NSScrollView showing part of view with white space above

[Quincey Morris via Cocoa-dev]

On Oct 13, 2019, at 06:30 , Aandi Inston via Cocoa-dev 
 wrote:
> 
> If the NSScrollView is scrolled upwards, the content in the window moves down 
> (as normal). What we now see is a large white space at the top of the 
> NSScrollView, and below that the same view portion we first saw.

It sounds like your NSView actually has white space at the top.

However, IB historically has a problem where its knowledge of the NSScrollView, 
the NSClipView and the client view gets messed up, and it mis-positions things 
rather than enforcing the correct relative positioning.

I think you have to start by logging the bounds of all three views (don’t 
forget the NSClipView!), but make sure you convert all of their coordinates to 
a *common* coordinate system (such as window coordinates), otherwise it can be 
too hard to compare them. Do this once initially, then again after you’ve 
scrolled all the way to the top.

You also haven’t mentioned whether your view is using auto-layout. Your view 
may be resizing to meet some auto-layout constraints, dumping all of your 
subviews at the bottom.

___

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: Views without any layout constraints may clip their content or overlap other views

[Quincey Morris via Cocoa-dev]

On Sep 26, 2019, at 10:55 , Laurent Daudelin  wrote:
> 
> I’m pretty much in the same situation. There seems to be something going on 
> behind the scene. I also observed that when I started adding constraints, I 
> would suddenly get many warnings and errors, some alluding to missing “y" 
> location where I can clearly see one constraint addressing that “y” location.

What you say sounds correct to me:

Richard’s description *is* the old behavior, just with a slightly different UI. 
The root view cannot be constrained via auto-layout relative to its ancestor, 
because by definition it occupies the entire geometry defined by its view or 
window controller. I assume it’s set to “Translates autoresizing mask into 
constraints” to *prevent* you from adding constraints, not because its 
autoresizing mask is *actually* translated into constraints (although I guess 
it may be so, as some internal implementation detail).

Subviews, in the past, had the automatic behavior (except for special cases 
like views inside scroll views). If you didn’t add any constraints, the IB 
inspector showed the autoresize mask UI with the springs and struts behaviors. 
As soon as you added any auto-layout constraints, that went away and the frame 
was completely controlled by auto-layout.

The problem with multiple warning and errors when you start adding constraints 
has been around for a while. Xcode is just bad at knowing when the view is 
properly constrained, although I’m prepared to concede that there are cases 
where it correctly complaining, even though the constraints *look* complete to 
our meager human brains.

On top of that, Xcode is really lousy at diagnosing real layout issues at the 
right level of the view hierarchy. It (pre-Xcode 11, I haven’t played with the 
new version yet) would be unable to confirm that a view was properly 
constrained if a subview wasn’t properly constrained, but would complain about 
the parent view, not the subview.

On top of *that*, Xcode was incredibly bad at adding missing constraints. It 
would often add constraints that didn’t actually fix the problem, leading to 
other errors, or fail to add the constraints it said was going to add.

But there’s more! Xcode would *also* fail to re-evaluate constraints properly 
*even after you or it fixed the problems by adding the right constraints*. The 
error messages would often continue to be displayed, but if you quit Xcode and 
started it again with the same project open, the errors would no longer be 
there. (!)

As I said, I haven’t had a chance to find out whether Xcode 11 is any better at 
all of this. The only advice I can give is to be persistent, to be thorough, 
and to think outside the box (literally).
___

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: Questions regarding release

[Quincey Morris via Cocoa-dev]

On Sep 25, 2019, at 13:52 , Rob Petrovec via Cocoa-dev 
 wrote:
> 
>> Is the IOObjectRelease() right or wrong ?
>   I’m not entirely sure since I can’t find the docs for 
> IOServicePortFromCGDisplayID.

Given that the code fragment shows it as a message being sent to “self”, this 
looks like Gabriel’s own method. By the standard Obj-C clang naming 
conventions, this should return a non-owning (+0) reference, so it should not 
be released without being explicitly retained.

My guess is that it actually returns a +1 reference, but uses a non-standard 
naming convention. In that case, the code is correct as written (although 
unclear because it doesn’t follow the naming conventions).

___

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: Confusion about release mode in Xcode

[Quincey Morris via Cocoa-dev]

On Sep 25, 2019, at 14:44 , Gabriel Zachmann via Cocoa-dev 
 wrote:
> 
> I have tried to create a new scheme, then changed the Build Configuration to 
> "Release".
> But in
>  Build Phases ⟶ Copy Files 
> it still says that the product is copied from ... build/Debug.
> (The destination is /Users/home/Library/Screen Savers)
> I have deleted it and added it to the Copy Files phase again, same result.

Assuming that you’re copying an item that is listed in the navigator pane, then 
the correct thing to do is to select it in the navigator, show the File 
inspector, and change the Location popup to “Relative to Build Products”.

However, if this is the Products group, when I looked at a project of mine, 
Xcode 11 doesn’t let me change that popup — it’s already locked to “Relative to 
Build Products”. So, I’m not sure if there’s something else going on 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: Views without any layout constraints may clip their content or overlap other views

[Quincey Morris via Cocoa-dev]

> On Sep 23, 2019, at 13:58 , Laurent Daudelin via Cocoa-dev 
>  wrote:
> 
> OH?!? That’s why I can’t find it. And now that you mention Xcode 11, I 
> remember having to install the command line tools a couple of days ago. It 
> must have been automatically updated as it is my current setting in the App 
> Store app.

> 

> Thanks James, I won’t search for it anymore!


From the Xcode 11 release notes:

> NSView  and UIView 
>  have a layout mode 
> option in the Size inspector to explicitly opt into “translates autoresizing 
> mask into constraints”. The default setting is “Automatic”, which is the 
> existing behavior. “Automatic” implies that “translate autoresizing mask into 
> constraints” is off when a view affect by constraints in the storyboard or 
> .xib file, but on if unconstrained. (37352354)
> Improved the reliability of Auto Layout constraint generation with “Add 
> Missing Constraints”. (43694622)


___

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: Moving cells in a UITableView

[Quincey Morris]

On May 17, 2019, at 14:09 , Carl Hoefs  wrote:
> 
> Is this a bug, or is it documented behavior?
> 
> Without the following setting:
> 
>self.tableView.autoresizingMask |= UIViewAutoresizingFlexibleWidth;
> 
> a UITableView won't permit reordering of the table's cells.

I think the problem is that reordering requires the cells to be dragged by the 
reordering control at the right-hand end. If your cells don’t resize properly, 
the reordering control can be outside the table view, and reordering can’t be 
done.

You need to make sure the cells resize properly (and autolayout is probably a 
better choice than autoresizing masks).
___

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: Moving cells in a UITableView

[Quincey Morris]

On May 16, 2019, at 14:29 , Carl Hoefs  wrote:
> 
> iOS 12.2
> 
> I want to allow the user of my iPhone app to finger-reorder the rows in a 
> UITableView.
> 
> I set tableView.editing=YES, and I receive 2 callbacks for each row in the 
> table:
> 
> (1) -tableView:editingStyleForRowAtIndexPath: --> return 
> UITableViewCellEditingStyleNone.
> (2) -tableView:canMoveRowAtIndexPath: --> return YES.
> 
> (The table displays rows that are shifted to the right to allow for an 
> editing icon (insert/delete), but as I am reordering rows, there's no icon 
> displayed.)
> 
> I cannot move the rows in the table.
> The callback -tableView:moveRowAtIndexPath:toIndexPath: does not get called.
> 
> My code used to work pre-iOS 12. Am I using the wrong 
> UITableViewCellEditingStyle?

I think you need cell.showsReorderControl = YES;

___

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: NSTextField "Discard Change"

[Quincey Morris]

On Apr 27, 2019, at 10:26 , Richard Charles  wrote:
> 
> Contrary to the documentation NSTextField does not support the NSEditor 
> protocol.

Well, I apologize for not researching my answer better when I answered before. 
However, be careful of what you assume from the documentation. NSTextField may 
not conform to the new *format* NSEditor protocol, but that doesn’t stop it 
from conforming to the informal protocol, if that’s what it always did.

In that regard, you can see this discussed here:

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html#//apple_ref/doc/uid/20002373-200965
 


That’s a very old document (Leopard era), and it says this:

> NSEditor/NSEditorRegistration
> 
> Together the NSEditorRegistration and NSEditor protocols allow views to 
> notify a controller that an edit is underway and to ensure that any pending 
> edits are committed as and when necessary.
> 
> The NSEditorRegistration informal protocol is implemented by controllers to 
> provide an interface for a view—the editor—to inform the controller when it 
> has uncommitted changes. When an edit is initiated, the view sends the 
> controller an objectDidBeginEditing: message. When the edit is complete (for 
> example when the user presses Return) the view sends an objectDidEndEditing: 
> message.
> 
> The controller is responsible for tracking which editors have uncommitted 
> changes and requesting that they commit or discard any pending edits when 
> appropriate—for example, if the user closes the window or quits the 
> application. The request takes the form of a commitEditing or 
> discardEditingmessage, defined by the NSEditor informal protocol. 
> NSController provides an implementation of this protocol, ***as do the 
> Application Kit user interface elements that support binding***.

(my emphasis in that last sentence)

I can also confirm, from having relied on this behavior for a decade or more, 
binding a text field to a NSObjectController *does* result in the text field 
committing editing when the controller asks it to.

In general, the NSObjectController, which implements both NSEditorRegistration 
and NSEditor, presents itself as a single editor to its “owning” controller, 
such as a NSDocument or NSViewController — but unfortunately not 
NSWindowController. When told to commit or discard its edits, the 
NSObjectController translates that into commit or discard messages for the 
NSEditor objects it owns).

On Apr 27, 2019, at 10:26 , Richard Charles  wrote:
> 
> Sending the array controller bound to the text field a discardEditing message 
> does’t work either.

I’m a bit confused by this. Why would you have a text field bound to an array 
controller? Are you talking about text fields in table view cells, where the 
table content is bound to an array controller? That’s a more complex scenario.

Describing these scenarios in words doesn’t seem to shedding much light on the 
subject. Maybe this is something you could put into a test project?
___

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: NSTextField "Discard Change"

[Quincey Morris]

On Apr 5, 2019, at 20:55 , Richard Charles  wrote:
> 
> Sending the text field an abortEditing message does not work. How can changes 
> to the text field be discarded?

Caveat: I don’t know the answer to what you’re asking, but I suspect you may be 
asking the wrong question.

First of all, what does “does not work” mean?

Second, looking at the documentation here:

https://developer.apple.com/documentation/appkit/nscontrol 


the “abortEditing” method is listed under “Managing the Field Editor”. I 
suspect it’s actually used internally to manage the relationship between the 
text field’s cell and the field editor, and not to manage the editing state of 
the control as a while. This method is probably just the wrong hammer for this 
nail.

Third, what I think you’re looking for is “discardEditing”, which is a part of 
the NSEditor protocol, to which NSTextField conforms. However, I’m not entirely 
sure about timing, whether it’s reasonable to invoke in response to 
“attemptRecoveryFromError:…”. But maybe.

Note that the documentation for NSEditor shows its methods as deprecated:

https://developer.apple.com/documentation/appkit/view_management/nseditor 


I believe this is a documentation error. At some point, NSEditor was converted 
from an informal protocol to a formal protocol (so it would translate into 
Swift properly), and that causes this error in the documentation. If you look 
at the actual header file (NSKeyValueBinding.h), you can see that the formal 
NSEditor protocol has no deprecations:

> @protocol NSEditor 
> 
> - (void)discardEditing;// …
> - (BOOL)commitEditing;// …


as well as the deprecations of the information protocol methods:

> @interface NSObject (NSEditor)
> - (void)discardEditing NS_DEPRECATED_MAC(10_0, API_TO_BE_DEPRECATED, "This is 
> now a method of the NSEditor protocol.");
> - (BOOL)commitEditing NS_DEPRECATED_MAC(10_0, API_TO_BE_DEPRECATED, "This is 
> now a method of the NSEditor protocol.");







___

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: Trouble assigning datasource and delegate to an instance of NSTableView

[Quincey Morris]

On Mar 28, 2019, at 15:58 , Peter Hudson  wrote:
> 
> @interface  ImportTool  NSEncoding> : NSObject

You’re Doing It Wrong™. You mean:

> @interface  ImportTool : NSObject  NSTableViewDelegate, NSEncoding>


I don’t know what it means the way you wrote it. Something about lightweight 
generic syntax, perhaps?   
___

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: Drawing boxes around each digit entered in UITextField (Number Pad)

[Quincey Morris]

On Feb 9, 2019, at 12:36 , Devarshi Kulshreshtha  
wrote:
> 
> Am I missing any important property in X axis from the calculation due to
> which I am unable to get properly aligned bounding box over each digit?

Yes, you’re Doing It Wrong™. :)

Glyphs are laid out along the line according to their advance widths, not their 
bounding box widths. That means the *width* of the box you draw should be the 
advance width (minus any thickness of the box border that lies outside the box 
rect, minus any spacing you want between the boxes horizontally). The *height* 
of the box should be something big enough to hold the digit (e.g. font ascent + 
font descent). The *origin offset* of the box should be a multiple of the 
advance width.

https://developer.apple.com/documentation/coretext/1511265-ctfontgetadvancesforglyphs
 


This is still going to be problematic sometimes, depending on the font. There’s 
nothing preventing glyphs from being wider than their advance width, and you 
have no control over that. Also, there’s no guarantee that all the digits have 
the same advance width (“lining numerals”), although it’s typically true of 
fonts made for use on computers. You might want to force a monospaced font for 
the text field. Also, be careful with non-Roman fonts: the conventions for 
digits might be different.
___

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: Questions regarding the sandbox in iOS

[Quincey Morris]

Actually, I believe this should be:

chdir(docsSandbox.fileSystemRepresentation)

even though that’s often going to end up being the same C-string in both cases.

> On Feb 5, 2019, at 12:29 , Carl Hoefs  wrote:
> 
> Yes, chdir(docsSandbox.UTF8String) works perfectly!


___

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: Crash in terminate: on Mavericks

[Quincey Morris]

On Jan 21, 2019, at 09:39 , James Walker  wrote:
> 
> I used LLDB, and said
> 
> env NSZombieEnabled=YES
> 
> before starting the process.

You should turn on zombies from the Diagnostics panel of your target’s scheme, 
or (as Ken suggested) use Instruments. 

> The backtrace doesn't show any of my code, …

Er, it sure looks like it does:

> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   ???   0x00010c3013e6 0 + 4499444710

…
> 17  com.apple.AppKit  0x7fff93342783 NSApplicationMain + 
> 940
> 18  ???   0x0001034e3f10 0 + 4350426896
> 19  ???   0x000102e3e034 0 + 4343455796

Lines 0, 18 and 19 look like locations in your code, unsymbolicated.

> …so I'm not sure how to proceed

You could try symbolicating the crash log.

> 3   com.apple.AppKit  0x7fff93355e79 -[NSApplication 
> windows] + 17
> …
> 6   com.apple.AppKit  0x7fff935d7347 -[NSApplication 
> terminate:] + 1671

So, your application appears to be terminating, and as part of that process 
something seems to be happening with windows, likely closing of windows. It’s 
extremely easy to get into an order-of-deallocation problem with views, view 
controllers, delegates and other objects, leading to a dangling pointer to an 
unallocated object. It’s also extremely for common that the timing differs by 
macOS version, which means it might crash in some versions, not in others.

___

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: Quick sanity check for iOS AVAudioSession

[Quincey Morris]

That all looks correct to me.

> On Nov 29, 2018, at 06:22 , Eric E. Dolecki  wrote:
> 
> Does this seem about right?

___

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: Xcode 10 and disable layer backed windows in Mojave

[Quincey Morris]

On Oct 25, 2018, at 05:31 , Georg Seifert  wrote:
> 
> When I build my app with Xcode 10, Mojave uses the new layer backed windows.

I’m not sure what that means. I don’t recall anything new about windows or 
layer backing in Mojave (but I may have missed something, of course).

> My view drawing is (not yet) able to dealt with layer backed views. 

The storyboard default for this did change at some point — but pre-Mojave, I 
thought. Anyway, if you don’t want layer-backed views, you can turn the option 
off in the View Effects inspector (the rightmost tab of the IB inspector 
panel). I believe you’ll have to do this for each root view.
___

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: touchesMoved value setting

[Quincey Morris]

On Sep 18, 2018, at 06:15 , Eric E. Dolecki  wrote:
> 
> Once the distance number gets high enough, I start to get tVal values of 2,
> 3, 4, etc. I think my logic is messed up here.

Yes, it’s messed up. Instead of this:

>currentValue = currentValue ± tVal

you need this:

>currentValue = originalValue ± tVal // original value at time of 
> touchesBegan


and ‘distanceValue’ has to be the *accumulated* distance since the 
touchesBegan. Trying to do this using the distance moved since the last 
touchesMoved is wrong.

BTW, I think it’s easier to use a UIPanGestureRecognizer.

___

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: Bothersome "NSView-Encapsulated-Layout-Height" constraint?

[Quincey Morris]

On Aug 30, 2018, at 17:23 , Demitri Muna  wrote:
> 
> I tried to force this by adding two constraints, 2 pixels above and below the 
> image, then got this:
> 
> 2018-08-30 14:55:36.807612-0400 Nightlight[78272:15775715] [Layout] Unable to 
> simultaneously satisfy constraints:
> (
>" 16   (active)>",
>" (active, names: DE_DataCell:0x60c000188470, '|':DE_DataCell:0x60c000188470 
> )>",
>" (active, names: DE_DataCell:0x60c000188470, '|':DE_DataCell:0x60c000188470 
> )>",
>" DE_DataCell.height == 12   (active, names: DE_DataCell:0x60c000188470 )>"
> )

“Encapsulated layout height” sounds like one of the constraints that IB adds to 
your layout when it’s under-constrained at design time. Are you adding the 
other constraints at run time?

___

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: NSComboBox

[Quincey Morris]

On Jul 25, 2018, at 15:40 , Casey McDermott  wrote:
> 
> I forgot to mention that the lists may contain 10,000s of items. Maybe 
> 100,000s. 
> Typing to select from NSPopUpButton works OK for short lists.  I just made a 
> test 
> popup with 300 items and it's already awkward.  10K would be absurd.
> 
> These are business records, and users may data enter hundreds a day.  They 
> want 
> to tab, type a few letters to select a customer, tab to the next field, type 
> a bit to
> select an inventory item, etc.  Type a customer that doesn't exist and it 
> should beep 
> and ignore the keystrokes.  If they need to enter a new customer, it's a 
> right-click, 
> then a panel to enter more than just the name.
> 
> Our current interface does use popup buttons for some things, but people 
> complain
> about them.  They don't want to take hands off keyboard.  We plan to convert 
> those 
> to combo boxes so it can be completely mouseless.

If that’s your use case, there’s something else gong on at the heart of this.

What value — if there are tens of thousands of items — is there in popping 
anything up at all, whether it’s a combo-box-style popup or a menu-style popup? 
It seems that you should just validate the text field every stroke, and provide 
the rest of the field as soon as what is typed becomes unique. Or does the user 
need to scan the list of near-matches for some reason?

Another approach to this might be to be something like autocomplete, but where 
you don’t start offering autocompletions until enough text has been entered to 
limit the possibilities to a manageable number of choices. Text fields have 
built-in support for autocomplete, although IIRC it gets a bit harder if the 
completions are context sensitive — if typing more characters changes the list 
of possibilities, rather than just limiting it. (Xcode’s autocompletions are 
content sensitive in this sense, but Xcode has its own implementation unrelated 
to NSTextField’s.)

Or, use a table view next to the text field, and programmatically scroll to the 
area of the list that matches what the user has typed so far. NSTableView is 
essentially optimized for displaying small fragments of huge lists, so it might 
be better than trying to stuff all those entries in a combo box.


___

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: Exception handling

[Quincey Morris]

On Jun 14, 2018, at 11:33 , Casey McDermott  wrote:
> 
> However, simply replacing the C++ throw with a Cocoa exception via
> [NSException raise : errString  format : errString]; seems to work great.
> Apparently it unwinds the call stack and is swallowed in the run loop.  

Yes, but do be careful about exceptions thrown off the main thread. In (say) 
GCD-owned threads, there’s nothing AFAIK to catch exceptions, and as someone 
already mentioned, NSExceptions can’t successfully cross dylib/framework 
boundaries.

___

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: Exception handling

[Quincey Morris]

On Jun 13, 2018, at 19:22 , Casey McDermott  wrote:
> 
> Nearly always, the event loop is the best place to escape to.


This is not how current thinking goes, unless you mean something different from 
what I think you’re saying.

If you’re implementing sanity (“should not happen”) checks, then the belief 
that it’s safe to shrug and return to the event loop is just false. It would be 
true if no significant state was preserved across event loop iterations, but 
that’s not nearly true — and likely extremely *un*true for those APIs and 
libraries that are complicated enough for the checks to fail sometimes. It’s 
simply not safe to branch out of lower-level code unless *all* of the code has 
been explicitly designed for that usage style.

It’s better to simply log the error and crash.

For recoverable errors in Obj-C code, you’re better off just doing the work of 
returning a “success or not” value along with a NSError out parameter. It’s a 
bit of grunt work to add this to existing code, but it’s probably worthwhile. 
(This would include having failable class init’s that have an outError 
parameter, which is not a common pattern, though it should be.)

The real problem comes, however, when you consider multiple threads. You can 
certainly catch NSExceptions in a sendEvent: override on the main thread, but 
in modern Cocoa programming there are many situations where you’re running your 
code on a background thread (e.g. GCD), and there’s not always an event loop or 
any good place to catch exceptions.

The situation with C++ exceptions is a bit different. You can basically do 
whatever you want with those (including using them for flow control), but 
there’s still nowhere central to catch uncaught exceptions, and you still have 
to worry about multithreading.

I may be out on my lonesome here, but if you want a robust app, I really think 
you have exactly 2 error handling patterns:

1. Returning false/nil with an outError parameter for recoverable errors, and 
always testing the result at every level.

2. Throwing NSExceptions for unrecoverable errors, and letting the app crash 
immediately.


___

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: runModalSession handling

[Quincey Morris]

On Apr 5, 2018, at 15:27 , Tom Doan  wrote:
> 
> I checked and none of my stopModalWithCodes are being fired, so the result 
> code has to be coming off the system dialog. I did a kludge where I used 100 
> and 101 for my own stop codes, and continued on 0 and 1, and that seemed to 
> work around this

This does sound like a bug, but it’s hard to know. Using different stop codes 
seems like a rational way to approach the problem.

Other possibilities you might investigate:

1. Close the modal window before using the NSOpenPanel, then reopen it with a 
new modal session afterwards.

2. Display the NSOpenPanel as a sheet on the modal window, rather than a 
separate window.

Is Carbon involved here in any way? This code looks like it was Carbon once, at 
least.

___

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: Harmful Notification Post Rate

[Quincey Morris]

On Mar 30, 2018, at 12:22 , Richard Charles  wrote:
> 
> My custom view implements -[NSResponder mouseDragged:] but this has never 
> caused any problems.

I don’t have much to suggest except “try stuff”. I’d try to see what happened 
if I commented out the “mouseDragged” override, if I commented out its contents 
(so that it swallowed the event), and if I commented out its contents but added 
[super mouseDragged: event] to pass the event up the chain.

I wonder if the message reflects the amount of time your mouseDragged is taking 
to handle the event? Maybe 112.994 is “harmful" only because it’s detected that 
your code can’t handle that many per second.

It’s also possible that message is something you can validly ignore. Does it 
happen in a release build, too?

Lastly, what kind of input device is producing these rates? Is it a mouse or a 
trackpad or something else? There might be something to chase after in that 
direction.

___

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: Harmful Notification Post Rate

[Quincey Morris]

On Mar 29, 2018, at 21:00 , Richard Charles  wrote:
> 
> How can I figure out what notification is posting at a high rate?

Not sure, but have you turned on “NSWindow.acceptsMouseMovedEvents” by any 
chance?
___

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: CoreText: determine symbol's characteristics: diacritic/space/cluster/wordbreak/etc

[Quincey Morris]

On Mar 18, 2018, at 13:11 , Ernesto Monde  wrote:
> 
> I want to know same amount of information about the string/glyphs
> being processed - it would be great to know how to extract it.

You can get some of this information by comparing against CharacterSet (in 
Swift, or NSCharacterSet in Obj-C). You can get some more sophisticated 
information using NSLinguisticTagger. There is currently no mechanism to get 
Unicode characteristics directly, although this is coming to Swift in the 
future.
___

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: Using NSFetchedResultsController with many-to-many relationship

[Quincey Morris]

On Mar 10, 2018, at 13:06 , Steve Christensen  wrote:
> 
> Don't complicate your life by managing multiple NSFetchedResultsControllers. 
> Just create a single one that returns Club entities.

The other valid approach, I think, is to “join” the two entities. That is, 
introduce a third entity, say “Membership” which represents a single Person 
belonging to a single Club. Person then becomes one-to-many for Membership, and 
Club becomes one-to-many for Membership, and there is no many-to-many 
relationship any more.

There is still complication in doing the kind of enumerations needed for a 
table view, but life is generally easier without many-to-many relationships.
___

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: WatchKit Baby Apps

[Quincey Morris]

On Feb 28, 2018, at 11:36 , Charles Jenkins  wrote:
> 
> I wanted to develop my own timer and repetition counter

Given that this doesn’t sound like it’s going to be a store app (with IP 
ownership consequences), I would suggest submitting that entire project as a 
radar, with a problem description along the lines of “WatchKit sucks! See 
inside for details!”.

I know the bug reporter seems like a black hole, but I have some faith that if 
SW engineers can see an actual example of what sucked, they can see how they 
could give you a better environment to work in, or they can see how they need 
to do a better job of explaining how to do things like your task.

This probably wouldn't produce any immediate results, but it has some chance of 
affecting some future directions.

FWIW


___

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: NSSecureCoding & NSAttributedString

[Quincey Morris]

On Feb 19, 2018, at 10:32 , Markus Spoettl  wrote:
> 
> for the exact purpose of replacing classes

Well, it’s not a cuckoo’s egg attack if the secure decoder is looking for the 
replacement cuckoo class, I guess. What still worries me is that you substitute 
with a class that doesn’t have the expected behavior *in context* (you: "Of 
course this loses the attribute's real values”).

However, as I said before, I’m not very good about reasoning out security 
threats, and so tend to be over-suspicious of creative solutions.

___

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: NSSecureCoding & NSAttributedString

[Quincey Morris]

On Feb 19, 2018, at 01:42 , Markus Spoettl  wrote:
> 
> I'm not sure where the NSAccessibility… keys are defined


https://developer.apple.com/documentation/foundation/nsattributedstringkey

> I found a workaround for the problem for classes that are not NSSecureCoding 
> compliant:
> 
> First I sub-class the offending class, implementing the NSSecureCoding 
> protocol, […].
> 
> Then I set up the class as substitution for the original in the 
> NSKeyedUnarchiver using -setClass:forClassName:.

Yikes! So you hack the unarchiving process to substitute a malfunction class 
for the real one, in order to protect the unarchiving process from being 
hacked? Is this really safer than not using secure coding at all? (That’s a 
genuine question. Maybe this *does* plug the hole.)
___

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: NSSecureCoding & NSAttributedString

[Quincey Morris]

On Feb 18, 2018, at 14:27 , Markus Spoettl  wrote:
> 
> yet this works (don't know why)

I did this in Swift (so I could use a playground):

> print (NSTextTab.self.conforms (to: NSSecureCoding.self)) // true
> print (NSTextList.self.conforms (to: NSSecureCoding.self)) // true
> print (NSShadow.self.conforms (to: NSSecureCoding.self)) // false

___

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: NSSecureCoding & NSAttributedString

[Quincey Morris]

On Feb 18, 2018, at 14:01 , Markus Spoettl  wrote:
> 
> Arrays are easy to enforce but dictionaries are really a weak spot.  For 
> starters you can't define which classes are acceptable as keys and which as 
> values. What if you have collection classes as values, what layout is 
> acceptable in sub-entries? None of that is expressible.

Arrays aren't safe from structural attacks, I think. There’s no way of 
expressing an array of *only* some element class — an actual element that is an 
array of the stated element class will pass the global check.

> As for additional NSAttributeString "companion" classes, I'm still open for 
> suggestions.

I dunno. I always though of the attributes as something extensible, but I guess 
they’re not really. (They can’t be, in NSAttributedString is an interchange 
format between apps.) Looking at the documented list, I would be worried about 
NSTextAttachment, which isn’t even documented as conforming to NSSecureCoding. 
Those NSAccessibility… keys don’t look too safe either.

At this point, though, I don’t trust myself to reason about what’s safe and 
what’s not.

___

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: NSSecureCoding & NSAttributedString

[Quincey Morris]

On Feb 18, 2018, at 10:30 , Markus Spoettl  wrote:
> 
> The decoder isn't terribly concerned with where the individual classes will 
> occur, just that they might.

I was going to reply that it’s stupid that it behaves like this, but I guess it 
makes some sense after all. The secure coding protection against class 
substitutions can be global like this, since class identities are global in the 
archive.

Still, you should probably assert “[notes isKindOf: [NSAttributedString 
class]]” immediately after that decode. Maybe I’m overthinking it, but I’d 
worry that your workaround enables some other kind of attack. For example, 
without the check, a maliciously-crafted archive that cause “notes” to be a 
NSTextTab could potentially crash your app, and that in turn might open up a 
vulnerability.

___

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: NSSecureCoding & NSAttributedString

[Quincey Morris]

On Feb 17, 2018, at 20:34 , Glenn L. Austin  wrote:
> 
> Or encode/decode them using Coding, then encode/decode the resulting encoded 
> attributed string data using SecureCoding.

Markus already said that archives exist with normally-encoded attributed 
strings, so that precludes changing the archive format in the way you say.

But that does suggest a partial alternative. In the object that decodes the 
attributed string, Markus can turn “usesSecureCoding” off for that decode only 
(in the coder object, which has this property defined). This won’t be secure 
against attacks via the objects *in* the attributed strings, but it would 
protect the rest of the archive.

It might even work to @try/@catch the decode with the setting on, before 
turning it off and retrying if an exception occurs, which would provide secure 
coding for any macOS version that doesn’t have this bug.

But a bug report or a TSI seems like a prudent act before committing to a hacky 
solution or giving up.


___

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: NSSecureCoding & NSAttributedString

[Quincey Morris]

On Feb 16, 2018, at 15:58 , Alex Zavatone  wrote:
> 
> So, splitting the solution into separate archival and unarchiving into 2 
> sections, where the unsupported classes are handled separately is the ugly 
> but required path to take?  

It’s hard to say in general, because having an attributed string suggests it 
might need to be decoded by other software, so hacks could be problematic.

Unless someone has a bright idea, I don’t any way around concluding that 
NSAttributedString can’t be used with NSSecureCoding.


___

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: NSSecureCoding & NSAttributedString

[Quincey Morris]

On Feb 16, 2018, at 15:06 , Alex Zavatone  wrote:
> 
> do you think that this be a case when it’s best to encrypt the strings 
> yourself with an HMac256 method on the attributed strings?

There’s no actual encryption in NSSecureCoding, it’s just about making sure 
that malicious classes aren’t substituted for the intended ones. You *could* 
introduce extra security, but at some point you’d have to hand the plain ol' 
raw data over to a NSKeyedUnarchiver, so the extra stuff wouldn’t help.

___

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: NSSecureCoding & NSAttributedString

[Quincey Morris]

On Feb 16, 2018, at 14:13 , Markus Spoettl  wrote:
> 
> how can I go about decoding NSAttributedString

I just tried in a playground, and the problem is in NSParagraphStyle, not 
NSAttributedString. It looks like it falls foul of the known secure coding 
issue about decoding arrays of unknown type. (NSTextTab is the only class that 
lives in an array within a paragraph style.)

That means NSParagraphStyle doesn’t actually conform to NSSecureCoding, and 
therefore nor does NSAttributedString, when any non-default tabs are present. 
It’s not clear that there’s an easy workaround. The only thing I can think of 
is to archive the text tabs separately, and somehow re-install them on the 
relevant paragraph styles after decoding, but that’s going to be a huge PITA in 
general.


___

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: Checking if a string is valid JSON

[Quincey Morris]

On Jan 29, 2018, at 13:30 , Saagar Jha  wrote:
> 
> Uhh…JSONDecoder swallows all of JSONSerialization’s errors and wraps it into 
> its own 
> .
>  I’m not sure this counts as “more detailed”.

Well, it presents all of JSONSerialization’s errors as DecodingError, but these 
are not all the DecodingErrors it can present. Also, AFAICT from a brief look 
at that code, DecodingError has a “codingPath” value that apparently locates 
the error within the source string. That seems unique to JSONDecoder.

OTOH, it may be that JSONSerialization errors are in fact as informative as 
JSONDecoder errors, in which case I mostly retract my comment. (I still think 
JSONDecoder is a better choice.)

___

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: Checking if a string is valid JSON

[Quincey Morris]

On Jan 29, 2018, at 12:42 , Eric E. Dolecki  wrote:
> 
> So this would do it?

I would strongly recommend using JSONDecoder instead of JSONSerialization. The 
errors JSONDecoder throws are AFAIK more detailed than JSONSerialization, and 
will tell you the exact location in the string of any error you find.

Also, FWIW, I beg you not to use this pattern (if you actually do, outside of 
this sample fragment):

>let jsonData = jsonString.data(using: String.Encoding.utf8)
>   …
>_ = try JSONSerialization.jsonObject(with: jsonData!)


but do this instead:

>let jsonData = jsonString.data(using: String.Encoding.utf8)!
>   …
>_ = try JSONSerialization.jsonObject(with: jsonData)


That is, don’t let optionals “escape” from the place where they first appear. 
If, in real code, you’re going to make the string decoding failure a handled 
error too, then this would of course become:

>if let jsonData = jsonString.data(using: String.Encoding.utf8) {
>   …
>   …
>_ = try JSONSerialization.jsonObject(with: jsonData)


where the optional still doesn’t escape from its point of appearance.

___

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: Scroll views

[Quincey Morris]

Well, I can’t figure out if IB supports your scenario in Xcode 9.2. In part, IB 
has some bugs in displaying the correct set of constraints error messages. In 
some cases, it displays errors for the wrong view; in some cases, it displays 
out-of-date messages until you rebuild the project, or close and re-open the 
project.

I did remember that Kyle Sluder had posted about this before, and I was able to 
track down this post here:


http://www.cocoabuilder.com/archive/cocoa/326783-guidelines-for-using-autolayout-with-nsscrollview.html#326786
 


The relevant text is:

> The biggest issue with using auto layout in an NSScrollView's document view 
> is that NSScrollView itself is completely unaware of auto layout. Thus, it 
> relies on the behavior provided by setting 
> translatesAutoresizingMaskIntoConstraints=YES on its subviews so it can 
> continue to use -setFrame: to position them even if auto layout is turned on 
> for the window.
> 
> At this point it's worth noting another difference between NSScrollView and 
> UIScrollView: UIScrollView directly manipulates its own bounds.origin to 
> perform scrolling of its entire subview hierarchy. The contentSize property 
> dictates the size of the scrollable region.
> 
> NSScrollView, on the other hand, doesn't actually do any scrolling on its 
> own: it delegates that responsibility to an NSClipView. The scroll view 
> positions the clip view and scrollers (if they are visible) using -setFrame:. 
> Rather than exposing a contentSize property, NSClipView observes the frame of 
> _one specific subview_ called its documentView. This view's frame.size 
> becomes the equivalent of UIScrollView's contentSize.
> 
> In order to perform scrolling correctly, the documentView's frame.origin must 
> lie at (0,0) in the clip view's bounds coordinate system. NSClipView, like 
> NSScrollView, is unaware of auto layout, so it uses -setFrameOrigin: to put 
> the document view at (0,0). If auto layout gets turned on for the window, 
> this position gets turned into a pair of constraints with a priority of 1000 
> (required).
> 
> Two more constraints will be synthesized to define the width and height of 
> the document view. These constraints are the problem. In either direction, 
> one of two kinds of constraints will be generated, depending on the 
> documentView's autoresizing mask for that direction:
> 
> 1. If the view is stretchable in that direction, a constraint will be 
> installed relating the opposing edge of the documentView to the edge of the 
> superview.
> 
> 2. If the view is not stretchable in that direction, a constraint will be 
> installed dictating the absolute value of the documentView's frame.size in 
> that dimension.
> 
> Like all autoresizing-mask constraints, these constraints are required 
> (priority 1000). Because the entire constraint system is solved at once, it 
> should be intuitive that any constraints that attempt to influence the size 
> of the documentView will conflict with either the constraints installed by 
> the clip view on the documentView and/or with the constraints installed by 
> the scroll view on the clip view.
> 
> So we have a dilemma. We need to somehow break the bidirectionality of the 
> relationship between the clip view and the documentView. There is no 
> straightforward way to express this using the constraints API, but it is 
> indeed possible without resorting to mucking with private internal details.
> 
> In other words, we want to somehow run layout of arbitrary constraints on our 
> documentView's subtree and retrieve the resultant frame of the documentView 
> without involving the documentView itself in our constraint system. Once we 
> have the right values, we can use -setFrameSize: on the documentView; the 
> clip view will notice and it will update its scrollable area.
> 
> The way we accomplish this is to install another view in our subtree and 
> define all our constraints relative to _that_ view. I'm going to call this 
> the adaptor view. The documentView installs constraints to keep the adaptor 
> view's top and leading margins equal to zero, but critically it does NOT 
> install any constraints on the trailing or bottom edges. This leaves the 
> adaptorView's width and height free to be defined by its content's layout.
> 
> The documentView signs up for frame change notifications from the adaptor 
> view. Whenever it changes its frame, the documentView calls [self 
> setFrameSize:] with the same size.  Then the clip view hears about this, and 
> the scroll view reflects the correct document size. For this to work, the 
> documentView's autoresizing mask should be set to width and height 
> NON-stretchable, that way when the clip view resizes (perhaps during window 
> dragging) it doesn't resize your documentView.
> 
> If you're laying out the contents of your scroll view in IB, the 

Re: Scroll views

[Quincey Morris]

On Jan 19, 2018, at 12:36 , Jeremy Hughes  wrote:
> 
> If you add a scroll view in Interface Builder, that’s how it is set up for 
> you by Interface Builder. You don’t have to add an autoresizing mask or use 
> it to pin the document edges - because Apple has already done that for you! 
> So you’re confirming my view that it’s confusing.

IB doesn’t know what you intend, so this is a case where you do need to go in 
and change the settings to what you need. In this cases, there are 3 things to 
think about:

1. You need to constrain the NSScrollView to (usually) fill up the view it’s 
in. You can do this by turning on all 6 arrows inside the resize control in the 
inspector.

2. You can only edit the outer 4 arrows of the NSClipView but you generally 
shouldn’t change the default setting at all.

3. For a document view that scrolls vertically, turn on the 3 horizontal resize 
arrows, turn off the 3 vertical ones. (I was wrong before, you *do* have to 
turn on the center one. I believe this is different to how this worked in 
earlier versions of Xcode.)

Because of #3, the document view height is now whatever it’s created at in IB, 
which by default is the same size as the clip view. You must set it to whatever 
you really need, in IB or later in code.

For example, I created a project and put a scroll view inside the root content 
view. The default height was about 250, so I tried making the document view 500 
instead. By putting some subviews inside this document view, I was able to see 
that the view scrolled correctly when the app runs. Resizing the window did 
what seemed to be a reasonable thing (the top left visible pixel before the 
resize stayed at the top left of the visible rect during the resize).

All of this is exactly what I would expect, and you should be able to reproduce 
this behavior.

> I mentioned in my follow-up email that I need to use explicit constraints in 
> order to avoid conflicts between autoresize constraints and the constraints 
> I’m adding to a subview. In order to avoid horizontal scrolling I’ve added 
> explicit constraints to pin the left and right edges of the “document” view 
> to its superview.

Yep, that part is the same as #3 above.

> Interface Builder complains if I don’t also add vertical constraints, so I’ve 
> done that, but made the bottom constraint into a placeholder (“Remove at 
> build time”). Your email suggests that I can also make the top constraint 
> into a placeholder. I’ve tried that now, and it seems to work fine. It also 
> makes sense :)

Using placeholder constraints makes no sense to me.

First of all, you need to understand that in current versions of Xcode, IB 
translates those resizing control arrows into constraints for you, unless you 
add *explicit* constraints that it regards as overriding this “free” 
translation. This means that those arrows are *not necessarily* honored. If 
you’re getting messages about missing constraints, then that means you’ve added 
some subview constraints that prevent the document view height constraint from 
being inferred.

What you actually do about such messages depends on what size you want for the 
document view. 

— If you want a one-time fixed height, you should add an explicit height 
constraint. 

— If you want a fixed height (that is, not derived from the subviews by 
auto-layout) that changes at various times according to decisions made in code, 
you should add an explicit height constraint and modify the constraint at 
run-time. 

— If you want a height that is derived from the subviews, you need to add 
sufficient constraints within the document view, and between the document view 
and its child views, to satisfy auto-layout’s requirements. In this case, there 
should be *no* vertical constraints relating the document view to its superview.

If your application is swapping subviews into the document view at run-time, 
then you have a couple of points to remember:

— You don’t want IB to provide default constraints on the document view. You 
should probably write code to remove any existing constraints from the document 
view before you swap in new subviews. (Even if you turn off all the arrows in 
the IB resize control, it’s not obvious to me that IB won’t add a height 
constraint anyway.)

— The document view’s vertical auto-layout universe is self-contained. You need 
to ignore the clip view or any other ancestor views, but make sure you 
establish a complete set of vertical constraints between the document view and 
its children. Whether that resizes or preserves the document view height is up 
to you.

___

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 

Re: Scroll views

[Quincey Morris]

On Jan 19, 2018, at 04:28 , Jeremy Hughes  wrote:
> 
> Summarising: it seems that to get a vertically scrolling view that works as 
> expected, the content view must be set to be flipped (no way of doing this in 
> IB) and the flexible-height arrow must be turned off. The top-margin line can 
> also be turned off, but it actually makes no difference if it is on or off.
> 
> Does anyone have a way to make sense of this or is it just inherently 
> confusing?

In general, you should *not* use autoresizing masks on the document view, 
precisely because the point of a scroll view is that the document view’s size 
is *unrelated* to the size of the piece of window real estate (the clip view) 
in which it is displayed. This is made worse if you also use autoresizing masks 
to pin the document view’s edges to the clip view, because the point of 
scrolling is to change the position of the document view origin relative to the 
clip view origin. Pinning the origin just conflicts with that.

IOW, you should set the size of the document view absolutely, either one time 
initially or whenever the size needed to encompass the contents changes. You 
may or may not need to set the position of the document view relative to the 
clip view initially or whenever the document view size changes, depending on 
whether the default behavior is what you want.

All of that is true for using auto-layout constraints, too.

However, in the case of a view like a text view which (for horizontal writing 
systems) can wrap its contents to a fixed width, it’s common to pin the 
left/right edges of the document view to the left/right edges of the clip view. 
(In terms of the autoresizing control, that means turning on the outer arrows 
on the left and right sides, and turning off the inner horizontal arrow.) In 
that case, there is never any actual horizontal scrolling, because the two 
views are the same width.

So:

1. Don’t pin any of the edges of the document view to the clip view, except 
when you want the widths to match.

2. Set the height of the document view manually to the size that encompasses 
all of its scrollable content. You can do this one time in IB, one time in 
code, or whenever the needed size changes, depending on how your app works.

___

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: Deciphering an error message on an iOS UITextField subclass.

[Quincey Morris]

On Jan 17, 2018, at 17:58 , Alex Zavatone  wrote:
> 
> Cell does not have this problem and is the proper subclass. It properly 
> reports both its class and the expected result for if it is a kind of 
> UITableViewCell class.

What the debugger is telling you is from run-time examination of the class 
info, so it will tell you the correct class. OTOH to evaluate a debugger 
expression (such as “cell.dataField”), the debugger uses the clang compiler (in 
effect), using compile-time info. That means it matters how and where the 
“cell” variable or property is declared.

I can’t tell from your most recent response whether you’re referring to 
run-time or compile-time information, so I can only ask the same question 
again: What is the *declared* type of the variable or property “cell”?

Also, even though you might have reason to think it’s pointless, what does the 
debugger produce for the following command?

po ((InsetUITextField*) cell).dataField


___

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: Deciphering an error message on an iOS UITextField subclass.

[Quincey Morris]

On Jan 17, 2018, at 17:24 , Alex Zavatone  wrote:
> 
> Am I right in assuming that Xcode thinks that the subclass has 2 possible 
> UITextField parent classes?

Well, the error message about ambiguity is confusing enough that it’s worth a 
bug report (even if it’s only a minor problem).

What is the type of the variable or property “cell”? It sounds like it’s just 
UITextField, in which case the “cell.dataField” expression isn’t valid. Try 
casting it explicitly:

po ((InsetUITextField*) cell).dataField

and see what the debugger says.

___

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: Popup-Menu Binding issue in Cell-based NSTableView

[Quincey Morris]

On Jan 1, 2018, at 01:46 , Motti Shneor  wrote:
> 
> Selected Object  bound to Measurements Array Controller, Controller Key: 
> arrangedObjects, Model Key Path: species, Allows Editing Multiple Values 
> Selection, Conditionally Sets Enabled, Creates Sort Descriptor

Your functional problem is here. You need to bind “Selected Object” to a 
*single* object, but you’ve bound it to the array of measurements. If you only 
have one row selected, it sort of works because bindings “deliberately” 
conflates an object with an array of one object or an array of the same object 
repeatedly, because … bindings. As soon as you have multiple rows selected, the 
functionality goes south.

Secondarily, your intention seems to be that choosing the popup in *one* of the 
selected rows should change the species in *all* of the selected rows. You 
can’t (or, probably can’t, though there might be a trick that does it) use a 
per-row control like this, and you’ll have to write code to transfer the 
per-row choice to all the other selected rows. The correct UI for this is to 
use a detail view — IOW, put the popup button outside the table, and have that 
single button reflect the species of the selected row, or of the selected rows. 
In that case, you might be able to get the desired functionality by binding 
“Selected Object” the Measurement Array Controller’s “selection” or 
“selectedObjects” controller key.

> When the content of a popup-button-cell is populated by binding - Can I still 
> apply NSMenu Validation protocol to that menu, and Filter/Enable/Disable menu 
> items as user clicks to open the menu?
> When the editing is done via the “Selected Object” binding - can I still 
> somehow intervene and “Catch” the change in code before it happens?

You can use KVC’s validation protocol (validate) with bindings, but you’re 
limited in what you can change.

But, how you proceed with this depends on whether you really want one menu 
choice to change all selected rows or just one row.

___

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: Data, enumerateBytes: separate blocks?

[Quincey Morris]

On Dec 27, 2017, at 11:59 , Daryle Walker  wrote:
> 
>> guard let firstBreak = index(where: {
>> [MyConstants.cr, MyConstants.lf].contains($0)
>> }) else { return nil }

I would be inclined to code it like this:

> guard let firstBreak = index(where: {
> $0 == MyConstants.cr || MyConstants.lf == $0
> }) else { return nil }

It *should* be possible for the compiler to optimize your version to this, at 
least in a release build, but after a certain amount of complexity in the 
source, it might be asking too much.

Since your test result showed “contains” actually being invoked, you know you 
have that overhead, and also I wonder if there’s some overhead in setting up 
the array value for every byte.

> I wonder if using something like [2]


*My* [2]? I dunno exactly, the difference is that it eliminates the invocation 
of “index(where:)” for each byte. It’s not clear whether the current (or the 
upcoming) Swift compiler could actually inline the method, which would make it 
a wash, or if the overhead is worth worrying about.

My advice is, as usual, don’t go to extraordinary lengths to optimize something 
unless you know you have a performance problem, and breaking out of a pure 
Swift idiom might be a little extraordinary. 

___

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: Data, enumerateBytes: separate blocks?

[Quincey Morris]

On Dec 25, 2017, at 10:23 , Daryle Walker  wrote:
> 
> What happens if whichever byte value is second is gigabytes away from the 
> first?

Your Data extension code doesn’t solve that problem anyway:

> var firstCr, firstLf: Index?
> enumerateBytes { buffer, start, stop in
> if let localLf = buffer.index(of: ParsingQueue.Constants.lf) {
> firstLf = start.advanced(by: buffer.startIndex.distance(to: 
> localLf))
> stop = true
> }
> 
> if let firstCrIndex = firstCr, firstCrIndex.distance(to: 
> start.advanced(by: buffer.count)) > 2 {
> // No block after this current one could find a LF close 
> enough to form CR-LF or CR-CR-LF.
> stop = true
> } else if let localCr = buffer.index(of: 
> ParsingQueue.Constants.cr) {
> firstCr = start.advanced(by: buffer.startIndex.distance(to: 
> localCr))
> stop = true
> }
> }


In the case where the Data object is *one* multi-GB buffer, if it doesn’t 
contain a LF you will search gigabytes for the non-existent LF before searching 
them again for the CR. Even if you’re lucky and the Data object is multiple 
smallish-buffers, you will still search all the buffers that don’t have a CR 
for a LF, before you find the one that does have a CR.

So, if your goal is to minimize searching, you have to search for CR and LF 
simultaneously. There are two easy ways to do this:

1. Use “index(where:)” and test for both values in the closure.

2. Use a manual loop that indexes into a buffer pointer (C-style).

#1 is the obvious choice unless invoking the closure is too slow when a lot of 
bytes need to be examined. #2 would use “enumerateBytes” to get a series of 
buffer pointers efficiently, but there is no boundary code to be tested, since 
you’re only examining 1 byte at a time.

Once you have the optional indices to the first CR or LF, and you find you need 
to check for a potential CR-LF or CR-CR-LF, you can do that by subscripting 
into the original Data object directly, outside of the search loop.

This approach would eliminate the problematic test case, and (unless I’m 
missing something obvious) have the initial search as its only O(n) 
computation, everything else being O(1), i.e. constant and trivial.

___

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: NSDocument autosave in place – possible data loss?

[Quincey Morris]

On Dec 24, 2017, at 16:36 , Alan Snyder  wrote:
> 
> But suppose the document is autosaved between the cut and paste, and the app 
> or system crashes before the next autosave.
> 
> Would the content then be lost, and would the user even know?

1. Without autosave, the history of your document as represented on disk is 
logically like this:

… Save … Save … Save

In the case of a crash, you can go back to the last save, which may or may not 
be recent. In your scenario, you might not lose data due to a cut that’s not 
pasted, but (as we all know from personal experience in the bad old days) 
you’ll probably lose some other important edit(s) since the last explicit save.

With autosave, the history starts to look like this:

… Save … Autosave … Autosave … Save … Autosave … Autosave … Autosave

In a sense, you’re no worse off after a crash, because you can hop back to the 
last save. This isn’t *quite* true, because with autosave you might 
explicitly-save less often than in the old days, but whether it’s practically 
better or worse depends on what changes you make and when.

2. Autosave tries not to expose users to the kind of data loss you describe. 
Changing the NSDocument object will (in general) reset the autosave timer, so 
it’s extremely unlikely your document will get autosaved right after the cut. 
(The timer is about 20 seconds, so if you wait that long before pasting, an 
autosave can intervene.)

3. Turning on autosave-in-place also turns on document versioning. A new 
version is create on every explicit save, and at *some* autosaves (though the 
documentation says not all). That means you have a reasonable chance to browse 
the document version history to look for the data you cut (and lost in a crash).

4. If you’re really worried about it, there might be something you can do with 
persisting undo information (at least back to, say, the last explicit save) in 
your document. It’s probably hard to design your app so that undo actions are 
serializable, but probably not impossible.

Overall, though, I think the answer is that autosave-in-place is a usability 
win in general, and protects the data more often that loses 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: Data, enumerateBytes: separate blocks?

[Quincey Morris]

On Dec 24, 2017, at 04:45 , Charles Srstka  wrote:
> 
> you could consider making its interface take generic collections of UInt8

This would not solve the *general* problem Daryle raised. He’s looking for a 
way to test the logic of some buffer-boundary-crossing code, which makes sense 
only if he has multiple buffers, which means he must be using “enumerateBytes”, 
which not supported by Collection. If he doesn’t use enumerateBytes, 
then he doesn’t need anything but Data anyway.

However, considering what appears to be the *actual* problem (finding the first 
CR or CR-LF or CR-CR-LF separator in a byte sequence), he could use Data 
without using enumerateBytes, and still not risk copying the data to a 
contiguous buffer.

This solution would use Data’s “index(of:)” to find the first CR, then a 
combination of advancing the index and subscripting to test for LF in the 
following 1 or 2 positions.

___

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: Data, enumerateBytes: separate blocks?

[Quincey Morris]

On Dec 23, 2017, at 23:03 , Daryle Walker  wrote:
> 
> The library doesn’t need DispatchData, just my test case (and only as posing 
> as a Data instance).

You *could* try moving the logic that’s inside your current enumerateBytes 
closure to a new method, and just call the method from the closure. Then, write 
another method in the test target, similar to the one that uses enumerateBytes, 
but manually breaks the original Data object into smaller ones (based on, say, 
an array of start indexes that a test can pass in), and feed those sequentially 
to the new method with the moved logic.

That would test your boundary-crossing code, which seems to be the point here. 
(It would actually test it better, because you could automate testing of lots 
of boundary positions.)

> It doesn’t seem I can do it without heroic measures by making a mixed 
> Swift/Objective-C test project. And even if that is possible, I don’t even 
> know if the Swift Package Manager supports it.

Or, do this anyway. A mixed project is not "heroic measures”, it’s likely one 
file with 5 lines of Obj-C code. And surely you can test whether SwiftPM 
supports the mix in about 5 seconds, just with placeholder code in a single .m 
file.

___

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: Data, enumerateBytes: separate blocks?

[Quincey Morris]

On Dec 22, 2017, at 08:48 , Daryle Walker  wrote:
> 
> DispatchData would need to be convertible to Data.  Is there a way to do the 
> conversion in Swift?

Actually, on consideration, I think not. It would be if DispatchData was 
bridgeable like Data, but it isn’t, and I don’t see any way of extracting its 
underlying reference. This leaves you with two options that I can see:

1. Use an Obj-C helper function, taking an array of input buffers, and 
returning a dispatch_data_t object that combines them, cast to a NSData*. You 
can then use the returned reference as Data.

2. Move your Data extension to DispatchData. That’s what I was asking about 
earlier — is there any reason why you couldn’t just use DispatchData rather 
than Data, in all the code that deals with this data set? In that case, you can 
just build the DispatchData in Swift.

IAC, you should probably submit a bug report. Since dispatch_data_t is 
documented to be a subclass of NSData, there should probably be a mechanism for 
getting Data and DispatchData values as equivalents of each other, without any 
unprovoked copying of the underlying data.

___

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: Data, enumerateBytes: separate blocks?

[Quincey Morris]

On Dec 21, 2017, at 18:04 , Daryle Walker  wrote:
> 
> when multiple blocks are used

At this point, I don’t understand what you don’t understand. Here’s a code 
fragment that works in a playground:

> import Foundation
> 
> let buffer1: [UInt8] = [1,2]
> let buffer2: [UInt8] = [3,4,5,6]
> 
> var data = DispatchData.empty
> data.append (buffer1.withUnsafeBytes { DispatchData (bytesNoCopy: $0) })
> data.append (buffer2.withUnsafeBytes { DispatchData (bytesNoCopy: $0) })
> 
> print (data.count)
> data.enumerateBytes {
>   bytes, index, stop in
>   print (bytes.count, index, bytes [0])
> }

producing this output:

> 6
> 2 0 1
> 4 2 3

Isn’t this what you were asking for: a loop enumerating each of the contiguous 
portions of a larger data set?

___

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: Creating NSTableView programmatically

[Quincey Morris]

On Dec 20, 2017, at 18:55 , Rob Petrovec  wrote:
> 
> Not for nothin', but I don’t think bindings have died.

So, let me respond jointly to all of the comments similar to this.

Of course bindings haven’t “died”, in the sense that no one *uses* them any 
more. My point was that bindings, as a conceptual software design paradigm or 
implementation framework for the general presentation or handling of data, 
don’t have much significance any more. We don’t sit down and *design* bindings 
for our apps, typically. We just bind things together when their values need to 
track each other. This should be understood as a simplification, not a denial 
that some people still get into them more deeply.

Consider also that there have been no functional improvements made to bindings 
since 10.5 (at least, I can’t think of even one), and that bindings were *not* 
taken over to iOS in 2008.

Of course, this is no rejection of KVO, which remains essential and creatively 
productive, despite being mechanically outdated.
___

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: Creating NSTableView programmatically

[Quincey Morris]

On Dec 20, 2017, at 01:23 , Eric Matecki  wrote:
> 
> The sole purpose of my project is to learn how bindings works, it has no 
> practical application per se.

Bindings exist to support the use of NIB-based UI behavior. All bindings work 
the same way, in the sense that they tie together the values of properties in 
each of two objects, so that a change in one appears as a change in the other, 
in either direction. This sort of equivalent to mutual KVO-observation with 
mutual updating, except that only the property in the target object (the one 
bound *to*) is actually a property in the KVC sense. The “property” in the 
source object (the one bound *from*) is a notional identifier that may or may 
not correspond to a true property of the object.

For example, when binding the content of a NSTextView, you bind the “value” 
binding to a NSString property of some other object. There is no “value” 
property, the binding name is meaningful only as a binding name. That means 
that all of the binding names have to be documented somewhere, and that happens 
to be the Cocoa Bindings Reference document, which is a long list of classes 
and the bindings that have been defined to exist in each.

That tells you what any given binding is for (provided you can understand what 
the documentation says, which is more of a problem than it ought to be), but it 
doesn’t tell you when you should use the binding. That you kinda figure out by 
trial and error. You can figure out when you need to use the NSTextView “value” 
binding, for example, and you can probably figure out the font and point size 
bindings, but go look at the bindings for NSPopUpButton and you’re gonna be 
scratching your head.

> I wonder how IB manages conflicts when merging your code back to the main 
> branch

Ever since version  of Xcode, IB manages this by using a XIB 
file as the source code of a compiled NIB file, and a XIB file is text in some 
kind of XML format. That means it can be diff’ed and merged, hence managed via 
source control. You can see this yourself by switching the assistant editor to 
show the version history, and the main view will switch from a graphic canvas 
to a long, long text description.

> The original code used all the same three array controllers, with the exact 
> same subclassing of the target's one.

This is where I take the fifth. 

When bindings were introduced, back in 10.3 or 10.4, then refined in 10.5, it 
looked very much like Apple was trying to sell a sort of data-manipulation 
“language” constructed out of bindings and NS…Controller classes. While this 
worked great for pushing glue code out of .m source files and into .nib files 
(this predated .xib files), it’s was too general, too inscrutable and too 
clumsy to have much wider appeal. In effect, the whole thing with bindings died 
at 10.5, except for the part where they were used within IB to hook up specific 
controls to specific properties. That part is really all we use today.

This particular sample app comes from about the 10.4 era, ideologically if not 
actually. It illustrates how to do things no one really wanted to do after 
about 2005. Your current project is archeology, not development.

> In the sample I have, I can't find any binding involving "selectionIndexes", 
> neither in the code nor in the NIB.
> It still works without them.
> Or, more precisely, without them being *explicitly* bound somewhere, and 
> that's the kind of magic I hate.


Well, it’s not quite magic, but nearly. This *isn’t* documented anywhere, or 
(if it was) it was documented in an old version of the Table View Programming 
Guide that no longer exists.

In a NSCell-based table view (the only kind at the time this sample app was 
written), when you bind table columns to a property of an array controller, 
something (the table view? the NIB-loading mechanism? IDK exactly) notices that 
the table view is missing its “content” binding and binds it to the array 
controller. Then it also binds the “selectionIndexes” binding. Most people 
don’t explicitly know that, because it just works and so they don’t have to 
think about it. It’s only when something is arranged differently (like using a 
table view without an array controller, or … what you’re doing) that anyone 
notices.

This is one reason why we generally use XIB/NIB files instead of code — it 
allows us to let IB to worry about the magic, so we don’t have to. (FWIW, stuff 
like this is one reason why IB is huge, slow and buggy. Every tiny detail of 
every old NIB behavior in every macOS version has to be religiously preserved 
in IB.)

>   @property(readonly, copy) NSIndexSet *selectionIndexes;

> So I can change a readonly property thru bindings ?

It’s … um … not readonly. But the setter method looks like this:

> - (BOOL)setSelectionIndexes:(NSIndexSet *)indexes;

which is to say, it’s not exactly a setter because it returns a value. If, 
however, you squint and ignore the return value, it 

Re: Pasteboards and NSSecureCoding

[Quincey Morris]

On Dec 19, 2017, at 18:32 , Jeremy Hughes  wrote:
> 
>> On 20 Dec 2017, at 02:22, Jeremy Hughes > > wrote:
>> 
>> What I don’t like about [NSArray.self] is that it’s an artefact of bridging. 
>> I’m not actually using it in the encoder:
>> 
>> coder.encode(arrayOfInts, forKey: kArrayKey)
> 
> The declaration:
> 
> encode(_ object: Any?, forKey key: String)
> 
> seems to indicate that it encodes any object

Yeah, you’re right, it’s secure on the decoding side only. 

This “encode” method is @objc, as I think you already noted, which AFAIK means 
that if the value is an array, it’s going to be automatically bridged to a 
NSArray. I would also expect it to become NSArray*, but I can’t 
remember the rules, so I won’t go out on that limb. I also haven’t looked at 
secure decoding recently, so I don’t know why or if the absence of the element 
type matters when you’re securely decoding. It used to.

Note that the first parameter (“Any?”) doesn’t have to be an object in Swift, 
although an object reference is required for the Obj-C method underneath. If 
it’s a non-object in Swift, it’s actually passed as an opaque object that wraps 
the Swift value.

After a while, you start to feel you need a ouija board to figure this stuff 
out. As an alternative, if you are in control of both encoding and decoding, 
and don’t need Obj-C compatibility inside the archive, you might do better to 
use encode/decodeEncodable instead of encode/decodeObject. That takes type 
bridging out of the picture, and trill preserves Swift types.

The last piece of this is that you should use one of the “decodeTopLevel…” 
methods to decode the root object of your archive, for example 
“decodeTopLevelDecodable(_:forKey:)”. This enables the relatively new — only 5 
years old! — failable decoding mechanism, where an error is thrown at the top 
level if any of the decoding fails anywhere in the archive, distinguishing 
failure from an init?(coder:) method that merely returns nil to signify an 
optional value that isn’t present. (You use “failWithError” to supply an error 
if you need to fail the decoding.)

Putting all that together, you can use NSKeyedArchiver/Unarchiver to encode and 
decode more or less completely in the Swift domain (Codable), with proper error 
handling and no obscure messing around with the types.
___

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: Pasteboards and NSSecureCoding

[Quincey Morris]

> On Dec 19, 2017, at 17:38 , Jeremy Hughes  wrote:
> 
> let array = decoder.decodeObject(of: [[Int].self], forKey: kArrayKey) as! 
> [Int]
> 
> gives an error:
> 
> Cannot invoke 'decodeObject' with an argument list of type '(of: 
> [[Int].Type], forKey: String)’

The class must be a kind of AnyClass, so you can’t specify a struct type. Sorry 
I sent you off in the wrong direction on that.

> The code I mentioned in my follow-up email seems to work:
> 
> let array = decoder.decodeObject(of: [NSArray.self], forKey: kArrayKey) as! 
> [Int]

That will compile, but might not work. If you’re doing *secure* decoding then 
the array of types must contain NSArray *and* the type of the elements in the 
array. 

However, if you’re not doing secure decoding (and I don’t think you’re required 
to, even if secure encoding was used to create the archive), then 
[NSArray.self] should work.
___

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: Pasteboards and NSSecureCoding

[Quincey Morris]

On Dec 19, 2017, at 17:09 , Jeremy Hughes <moon.rab...@virginmedia.com> wrote:
> 
> In a previous discussion, Quincey Morris wrote:
> 
>> The solution is to fall back to an explicit NSSet object:
>> 
>>  let classes = NSSet (objects: NSArray.self, MyElementClass.self)
>>  let myArray = coder.decodeObjectOfClasses (classes, forKey: “myArray”)
> 
> So I’ve tried:
> 
> let allowedClasses = NSSet(objects: NSArray.self, Int.self)

That looks like Swift 3 code. The current version of the function is like this:

> @nonobjc func decodeObject(of classes: [AnyClass]?, forKey key: String) -> 
> Any?


so you’d specify [NSArray.self, .self] for the first parameter. 
(Note, it’s a Swift-specific wrapper function, not just a direct API 
translation.)

You’ll have to figure out what type to use for the Ints. If they were actually 
saved compatibly with Obj-C, the Ints will actually be NSNumbers, and you’ll 
need to say “NSNumber.self”. If the Ints are stored opaquely as Ints, I guess 
it would be Int.self. You should be able to figure out the right type by trial 
and error, I’d say.

(Actually, if the array itself was saved opaquely, then you’ll need something 
like [[Int].self], I guess. This is an area subject to automatic bridging, so 
what you get depends on the exact code used to encode the archive.)

___

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: Data, enumerateBytes: separate blocks?

[Quincey Morris]

On Dec 19, 2017, at 14:57 , Daryle Walker  wrote:
> 
> What are the hoops/bridges required?

I think I was referring to what Wim Lewis said, which is that you can create 
DispatchData values (or perhaps dispatch_data_t objects), but you’re going to 
have to forcibly cast from dispatch_data_t to its superclass, and then bridge 
that to Data.

However, if you’re going to the trouble of creating DispatchData values, you 
may as well use those directly, rather than bridging across to Data. The 
decision may depend on exactly which APIs you need to use to process the data.

___

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: Creating NSTableView programmatically

[Quincey Morris]

On Dec 19, 2017, at 02:24 , Eric Matecki  wrote:
> 
> When I select a row in a NSTableView, that selection doesn't "make it" all 
> the way to update the controller...

I masochistically downloaded your project, and I think it’s a perfect example 
of why not to do this. There is so much glue code that it's impossible to tell 
whether your code is any more than locally correct (that is, beyond whether 
each line of code does what it purports to do). But all that aside…

— I think it’s a tragic mistake to subclass a NSArrayController. The class is a 
largely inscrutable black box of glue code, and any code that you add is thrown 
into the black hole. (I admit this is only an opinion. Others may love this 
kind of self-inflicted pain.)

— I think it’s *probably* a mistake to use NSArrayControllers *at all* in this 
project, where you’re trying to implement a specific UI. A NSArrayController is 
a generalized collection of behaviors intended to be used to support a large 
generality of UI designs in a NIB file. That level of generality isn’t 
necessary when you’re writing UI code directly, without using NIBs. It’s the 
equivalent of using a dictionary with string keys to represent properties, 
instead of declaring the actual properties you want.

— Your actual problem is that selection doesn’t work because you didn’t connect 
up the right pieces to make it work. For example, I fixed it for the first 
table by adding one line of code in the “buildGUI” method:

>   [combatantsTable bind: @"content"  toObject: self.combatantsController  
> withKeyPath: @"arrangedObjects"  options: 0]; // existing code
>   [combatantsTable bind: @"selectionIndexes" toObject: 
> self.combatantsController withKeyPath: @"selectionIndexes" options: 0]; // 
> added code


IOW, the array controller doesn’t know what the current selection is unless you 
tell it. I didn’t try to fix any of the other tables, but presumably they have 
the same problem.

___

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: Creating NSTableView programmatically

[Quincey Morris]

On Dec 12, 2017, at 02:12 , Eric Matecki  wrote:
> 
> In the case of NSTableCellView, neither binding works... I don't get any 
> exception or crash, but nothing is displayed inside my table view (although 
> it's size suggests the four rows are there).

This was a conceptual failure on my part, since I’ve never actually created a 
NSTableCellView manually. The cell view has “imageView" and “textField” 
outlets, but they’re not connected to anything by default, and the cell view 
has no subviews by default. (One or both subviews is present and connected when 
you do this in IB, because IB uses a preconfigured cell view hierarchy.)

If you want to use a text view, you will have to subclass NSTableCellView to 
add a “textView” outlet. or you can use a text field with the existing 
“textField” outlet. Either way, you’ll need to create the text-displaying 
subview, and set the corresponding outlet.

>[view  bind: @"value"  toObject: tableView  withKeyPath: 
> @"objectValue.name"  options: 0];  // wrong, but works

I have no idea why that works, it makes no sense whatever.

You’re still missing some stuff, BTW:

— For proper table view behavior, you really should create the cells by 
invoking "makeView(withIdentifier:owner:)”, so that the table view can manage 
the lifetimes and reusability of the cell views. However, this mechanism is 
intended to work with a NIB for the table cell view. This can either come from 
the table view’s own NIB file (via a private mechanism that IB sets up for you) 
or a freestanding NIB file (which you must register with the table view 
manually). Since you have neither, you will (I guess) need to let the cell 
creation portion of the "makeView(withIdentifier:owner:)” API fail, when a cell 
view isn’t being reused, then create your cell view manually.

Technically, you don’t have to do this, I suppose, but you said you were trying 
to learn what normally goes on, and cell view caching is what normally happens.

— You didn’t embed your table view in a scroll view. 

If it can’t scroll, the table view isn’t much use.

> How do you "ignore" what you don't need in an NSTableCellView ?

As I said, I was confusing two things. Most standard cells created in IB are 
just text, and have no image view.

> And when I add a subview to one, how do I arrange (layout) it's content

The usual ways, which is to say: add layout constraints, or set the frame 
manually if you’re not using autolayout.

> It's still weird (to me) to bind an object's binding to one of it's own 
> properties.

It’s just a special case of a “derived” property. It’s not so unusual for an 
object to observe one of its own properties in order to provide a KVO compliant 
value for another property. Anyway, in this case, it’s conceptually binding to 
a different object (the one referenced by “objectValue”) to get its “name” 
property. The indirection falls out of the division between standard behavior 
and custom behavior that’s built into the table view design.

> Too bad that bindings are fading away

I don’t think bindings are fading away. They can’t, while they’re the only way 
to connect UI elements without custom glue code. However, the design is ancient 
(IIRC, bindings were introduced in macOS 10.3, and refined in 10.4, and really 
nothing has changed since then).

What has fallen away (because it never really got off the ground) was the use 
of *custom* bindings, in part because no one could understand what to do, and 
because they really needed the IB customization features introduced in Xcode 
3.0 (or was it earlier?) and killed off in Xcode 3.1 (or thereabouts).

In modern terms, bindings are a horrible hack, and that’s why (I assume) they 
were never taken over to iOS.

___

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: Creating NSTableView programmatically

[Quincey Morris]

On Dec 11, 2017, at 10:19 , Alastair Houghton  
wrote:
> 
> NSTableViewCell is the old way to do it, before view-based tables were the 
> norm

In this case, I think “NSTableViewCell” is a typo in the documentation. In the 
following tables, it refers to the binding target as “Table Cell View”, not 
“Table View Cell”. NSCell-based tables did use cell class names with the 
pattern “NS…Cell”, but NSTableViewCell wasn’t one of them AFAIK. (In iOS, of 
course, the equivalent cell view is UITableViewCell, just to keep us on our 
toes.)


On Dec 11, 2017, at 05:53 , Eric Matecki  wrote:
> 
> I made my own text field class according to this (in NSTableCellView's doc) :

I think you’re still kinda Doing It Wrong™. The standard (and, I believe, 
recommended) way to do this is to create an instance of NSTableCellView, which 
has the “objectValue” property, along with other potentially useful behaviors 
for cell views (such as identifiers that allow the NSTableView to cache and 
manage cell views). 

In a very unusual or complex case, you might subclass NSTableCellView to add 
properties or behaviors to it, but it’s normally not necessary. Custom 
properties, for example, can be carried around by the object referred to by 
“objectValue”, and custom behaviors can sometimes be implemented as part of the 
delegate.

Instead of using a cell view other than a NSTableCellView or subclass, it’s 
usual to *add subviews* for things like text fields and buttons. That separates 
the behavior of the cell *as a cell* (such as being cached for the table view) 
from the view hierarchy represented by the cell. However, if your cell just 
needs to contain a text field, you don’t need to add one yourself, because 
NSTableCellView already contains a NSTextField subview that you can just *use*. 
It also contains NSImageView subview that you can use or ignore.

> Now I can see all the names :)

One reason to use a NSTableCellView instead of a control sum as a text field is 
that the cell view’s size is *forced* to the dimensions required by the table 
view row. That means you have no control of the placement of the contents 
relative to the row. For a text field, for example, you have no direct way of 
controlling the margins surrounding the text. This approach also limits the use 
of autolayout, which may or may not be an issue in your project.

> - (NSView *)tableView:(NSTableView *)tableView  
> viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row {
>NSTextView*  view = [[NSTextView  alloc]  init];
> …

You say “text field” everywhere, but you actually create a text view. I don’t 
get a sense of which one you really want to use, but using a separate 
NSTextView for each row of the table could end badly, and subclassing 
NSTextView is probably a code smell.

___

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: Data, enumerateBytes: separate blocks?

[Quincey Morris]

On Nov 28, 2017, at 11:32 , Wim Lewis  wrote:
> 
> The only documentation of this is in the 10.9 release notes

That’s what I was thinking of — thanks for clarifying.

I believe that there is one more little piece to this that’s more recent. Since 
(after that 10.9 change) the NSData class had to become (publicly) aware that 
subclasses might contain discontiguous data, the opportunity arose for Cocoa to 
leverage this in other scenarios, where dispatch_data_t (aka DispatchData in 
Swift) wasn’t involved. That’s good in general, as a performance enhancement 
for code that cares to enumerate the block ranges, but it happens behind the 
scenes.

By contrast, AFAIK the only mechanism for 3rd party code to *forcibly* create 
NSData objects with discontiguous data buffers is via 
dispatch_data_t/DispatchData. For that reason, it might make more sense for 
Daryle to work in the DispatchData domain rather than the plain Data domain. 
However, as you say, there’s a bridge involving some simple hoops available if 
necessary.


___

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: Data, enumerateBytes: separate blocks?

[Quincey Morris]

On Nov 27, 2017, at 22:36 , Daryle Walker  wrote:
> 
> Is there a way to make a (NS)Data that uses multiple contiguous blocks?

You mean multiple *non-contiguous* blocks??

The only way I know of forcing Data to use multiple blocks is via DispatchData.

(In recent OS versions, Data and DispatchData are sort of the same thing, but I 
don’t remember where this is described.)

___

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: Getting immutable UIImage data pointer without copy?

[Quincey Morris]

On Nov 14, 2017, at 20:11 , Rick Mann  wrote:
> 
> The bigger question is around the copy.

In general, the answer must be that a copy ought to be expected. That’s because 
a data provider is not required to have a data buffer, so there’s not 
necessarily any underlying data to access directly. (The actual data could be 
streamed, or generated procedurally.) If you can limit the kinds of image 
sources, you might get a more specific answer.

___

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: Getting immutable UIImage data pointer without copy?

[Quincey Morris]

(resent to the list)

On Nov 14, 2017, at 18:36 , Rick Mann > wrote:
> 
> Is there a way to get at the underlying raw image data for a given UIImage 
> (in an immutable buffer) in Swift?
> 
> Does this end up making copies? (For bonus points, what's the array magic?)
> 
> let img: UIImage = UIImage(named: "MyImage")
> let data: CFData? = img.CGImage.dataProvider.data
> let dataArray: [UInt8] = 

There are some simple answers, but the correct answer is “it depends”. For 
example, you can do this:

> var data = Data ([1,2,3,4])
> print (data [3])

In other words, seeing a Data instance as an array of bytes is simple. Or, if 
you want to do something more like the old days in Obj-C, you can do this:

> data.withUnsafeBytes {
> (bytes: UnsafePointer) in
> print (bytes [3])
> }

which (in some sense) gives you a raw-ish pointer to the underlying data, 
inside the closure. (The latter, which a different generic specialization type, 
is also what you’d use if you wanted to access pairs of bytes as UInt16 values, 
etc.)

Back to original problem, the following code in a playground works:

> let img = UIImage(named: "Image”)! // I used a PNG image so the data is simple
> let data = img.cgImage!.dataProvider!.data! as Data
> print (data [0], data [1], data [2], data [3])

The last part of this is (a) whether you can always get the raw data as bytes, 
(b) what those bytes represent, and (c) does this kind of approach make a copy? 
The answer is “I don’t know”, because it’s going to depend on the format of the 
image and the particular data provider. AFAIK, both the array treatment and the 
UnsafePointer treatment require a continuous underlying buffer, so if the data 
provide build the data using multiple partial buffers, I suppose there has to 
be a copy to meet the API semantics.

You could also iterate through a Data object using a for loop (and general 
collection/sequence methods as required). Since that would access only 1 byte 
at a time, I’d expect there’s no copy involved, but who knows what the 
performance might be in general.

Does any of that help?
___

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: NSTimer not firing when computer is inactive for a while.

[Quincey Morris]

On Nov 14, 2017, at 16:57 , Quincey Morris 
<quinceymor...@rivergatesoftware.com> wrote:
> 
> I would suggest you try setting the QoS to at least “utility”, perhaps even 
> “user initiated”.

To clarify: *what* you set to a different QoS depends on the nature of the 
thing you described as a “background process”. For example, if you’re using 
XPC, I think you can change the QoS of the XPC service as a whole. Changing the 
QoS of a particular thread may not be the correct solution.

___

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: NSTimer not firing when computer is inactive for a while.

[Quincey Morris]

On Nov 14, 2017, at 16:43 , Nathan Day  wrote:
> 
> I have a background process that uses an NSTimer that is set to fire every 
> minute, but when the computer is inactive for a while it will stop firing

My guess is that it’s not a problem with the timer, but with the quality of 
service (QoS) of the thread that’s servicing the timer. If this is a background 
process, it may be that the default QoS is “background”, which allows the 
system to defer execution indefinitely. I would suggest you try setting the QoS 
to at least “utility”, perhaps even “user initiated”.

___

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: unable to update UI on main thread in 10.13

[Quincey Morris]

On Oct 27, 2017, at 07:40 , sqwarqDev  wrote:
> 
> It seems to be when the superAttributedString is added that I get the 
> warnings.

— Is that backtrace from the main thread?

— The symptoms you describe might be explained if the text storage is holding 
on to a reference to the attributed string object you set, and you subsequently 
modify the same attributed string object. After you “push” the object in 
“superAttributedString” to the main thread, do you create a new object in that 
variable? What happens if you set a copy of the attributed string into the text 
storage? Something like:

>   
> self.profilerTextView.textStorage?.setAttributedString(self.superAttributedString.copy
>  ())

Better still, don’t store the attributed string persistently anywhere, but pass 
it through the background processing then on to the main thread as a parameter 
to the updateUI function.

Also, in this context:

> I AM seeing odd behaviour in 10.13 (the attributed string is supposed to bold 
> certain parts of the text, but one time in ten or so in 10.13 it just goes 
> gung-ho and bolds the lot)

it sounds like it could be a thread safety issue, which could lead to both this 
and the original problem.

___

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: [ANN] Nursery Framework 1.0.1 (build with Xcode 9) released

[Quincey Morris]

I haven’t studied your code, but based on the information you gave earlier, 
here are some suggestions:

Kidnapper: maybe “collector”, “reclaimer”
Peephole: maybe “window”, “aperture” (opening), “frame”, “segment”
Stalker: “seeker” or “scanner” 
Stalk: “seek” or “scan”
Play Lot: not sure what this is for, could be “sandbox” (area to experiment 
in), “cache” (area holding objects temporarily), “group”, “context”
Pupil: again, not sure what this is for

Of course, these words don’t fit into a theme. It’s probably safer at this 
point to use neutral words.


___

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: [ANN] Nursery Framework 1.0.1 (build with Xcode 9) released

[Quincey Morris]

Akifumi,

Alex Zavatone is just one voice. Not everyone has the same opinion.

I am *not* offended at calling a class “NUKidnapper”.

If the English naming is a problem, then I suggest you name the classes in 
Japanese (romaji). TBH, I don’t see why English speakers must demand English 
names.

Of course, I’m just one voice, too.

> On Oct 26, 2017, at 16:34 , Akifumi Takata  wrote:
> 
> Dear Alex Zavatone,
> 
> I understood that the words I chose are very problematic in English-speaking 
> countries.
> 
> I need help from those with fluent English to solve the problem.


___

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 using NSTimer in privileged helper tool

[Quincey Morris]

On Oct 20, 2017, at 03:23 , Mark Allan  wrote:
> 
> That worked with the block-based NSTimer API but not the selector-based API.  
> I tried changing it to 'currentRunLoop' which got rid of the crash, but the 
> timer never fired.

This is pure guesswork, but I suspect this is what was going on:

— When you scheduled the timer on the main run loop, it was actually being 
scheduled on the main app’s run loop. When it was block based, only the block 
had to be passed across the XPC interface (which somehow works), but when it 
was selector-based, the timer itself had to be passed (which doesn’t work). 
Admittedly this is a pretty silly explanation, but it may have some relation to 
the truth.

— When you scheduled the timer on the current run loop, everything was fine 
either way, except the run loop *wasn’t running* in the XPC thread, so the 
timer never fired.

This is similar to a problem that came up on the developer forums a few weeks 
ago. A developer was using Disk Arbitration callbacks to monitor volumes being 
mounted, and tried to move that code to an XPC process. The callback was 
scheduled on the run loop, yet it was never called. There was more recent API 
that was block-based instead, and that turned out to work fine in an XPC 
process. The fact that scheduling on the run loop didn’t crash indicated that 
there *was* a run loop, but the fact that the callbacks didn’t fire suggested 
that it wasn’t running.

___

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 using NSTimer in privileged helper tool

[Quincey Morris]

On Oct 19, 2017, at 09:04 , Mark Allan  wrote:
> 
> Terminating app due to uncaught exception 'NSInvalidArgumentException', 
> reason: '*** -[NSXPCEncoder _checkObject:]: This coder only encodes objects 
> that adopt NSSecureCoding (object is of class '__NSCFTimer').'

It’s very suspicious that the timer itself would be encoded, since that would 
suggest that the timer itself is being passed back across the interface to the 
main app. What does the backtrace look like? Ideally there would be something 
there that tells you what it’s trying to do at that time.

I don’t know, but I suspect that the block-based NSTimer methods might differ 
from the selector-based ones in that they use GCD rather than the run loop. If 
you look at the documentation, the old methods say "schedules it on the current 
run loop”. The new methods do not.

That suggests the possibility of using dispatch_source_create and 
dispatch_source_set_timer directly to create a GCD-based time. It’s not quite 
as convenient to code, but not hard to get right.

___

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: [NSButton state] must by used from the main thread

[Quincey Morris]

On Sep 26, 2017, at 08:19 , Jens Alfke  wrote:
> 
> You’re assuming it’s a synthesized getter, but there’s no reason it couldn’t 
> be a custom method that does arbitrary computation before returning the 
> value, and there’s no way to know whether that work is thread-safe or not.

It is, in a sense, “even worse” than that. Even with a synthesized getter, you 
might get a bad value, if it’s a non-synthesized, non-trivial setter. For 
example, it’s possible to pass an arbitrary number to the NSButton.state 
setter, but the getter is supposed to return one of three values (on, off, 
mixed). If the setter stores the input value transiently, before replacing it 
with the legal equivalent, that could lead to a failure in using the getter.

___

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: [NSButton state] must by used from the main thread

[Quincey Morris]

On Sep 26, 2017, at 01:16 , Tamas Nagy  wrote:
> 
> but “state” of the NSButton is a NSInteger property, so that should be safe 
> to read from a background thread, right?

Not necessarily. If the setter is thread-unsafe, then it’s possible that the 
getter may retrieve an incorrect value.

It’s not clear whether Apple has audited methods to determine thread safety (so 
that such reported errors represent an actual pitfall), or whether there is a 
general restriction on settable properties of UI objects. Either way, prudence 
dictates that you heed the warning and change the code.

Now that I think about it, getting a button state on a background thread does 
seem like an odd thing to do. Except in the simplest of cases, it does seem to 
open up the possibility of race conditions, since the “when” of the value might 
matter, relative to the timing of the surrounding code.

___

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: Inserting a button into another application's toolbar

[Quincey Morris]

On Sep 18, 2017, at 14:35 , Nick  wrote:
> 
> adding/injecting a toolbar icon with a custom handler code into the main 
> window of the application

Isn’t that a massive security violation? Assuming you could get an icon into 
the toolbar (NSToolbar), it would need an action method to handle a click on 
the icon. If you could inject an action method, a malicious actor could inject 
arbitrary code into any app.

You might be able to get *near* your intended approach by using a service:

developer.apple.com/documentation/appkit/core_app/services_functions

___

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: Dealing with validModesForFontPanel signature change

[Quincey Morris]

On Sep 14, 2017, at 09:07 , David Catmull  wrote:
> 
> Are there any other options?

It looks like an unintentional error in the 10.13 SDK. If you look at other 
“enforcement” types, such as Notification.Name, they’ve been given a 
backwards-compatible availability, since they are value-compatible. (They have 
to be, because the Cocoa methods haven’t changed.)

I don’t see any immediate solution within Swift syntax. The only solution I can 
think of is to use an Obj-C “bridge", where you implement the override method 
in Obj-C, and have the override call a Swift method that doesn’t use the 
MaskMode type. (The old numeric masks are still available in the 10.13 SDK as 
deprecated global constants.)

Unfortunately, this is a bit messy to do. The cleanest way I can think of is to 
create a NSObject subclass (in Obj-C) that has the override and a dummy 
Swift-compatible replacement method that the override calls. Your class would 
then subclass this, and override the dummy method.

Make sure you submit a bug report. If the availability is intentional, then 
they need at least to be able to tell you how to write the override with 
backward compatibility.

___

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: Why are some Core Graphics APIs "hidden" from Swift?

[Quincey Morris]

On Aug 30, 2017, at 14:04 , Rick Mann  wrote:
> 
> But the X, Y versions have a double underscore:
> 
>CGContext.__addArc(x1: CGFloat, y1: CGFloat, x2: CGFloat, y2: CGFloat, 
> radius: CGFloat)
> 
> Why is this?

I believe the double-underscore prefix indicates an Obj-C API that is exposed 
through Swift but not intended for general use. It may be that it’s there for 
3rd party developers who insist on using that particular API, or it may be for 
the Swift compiler to call through to. There is generally a better (simpler) 
API that does the same thing.

In this case, it may be that the x/y plus 1/2 coordinate pattern is an outlier, 
and Swift standardizes on points instead, in geometrical methods. You can pass 
CGPoint(x: x1, y:y1) and CGPoint (x: x2, y: y2) into the other API. My guess is 
that Swift generates the exact same code for the parameters in either case, 
because it can *always* inline the CGPoint creation methods. You’re not paying 
a performance or code size penalty, and you are gaining consistency.

I don’t know if my reasoning is correct, but it’s an argument that can be made 
in other similar cases too, so I think it’s something like that.

___

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: NSDocument -canCloseDocumentWithDelegate::: not called when terminating

[Quincey Morris]

On Aug 30, 2017, at 06:18 , Jonathan Mitchell  wrote:
> 
> My documents have a lot of variable user cancellable activity that must run 
> prior to document closure regardless of whether the document is dirty or not.

> My solution is to run a termination preflight that processes my clean 
> documents prior to allowing actual termination,

There’s a difference between your scenario and the one in the thread you linked 
to. In your case, you don’t need to write anything to the document itself, you 
say.

I think it’s a (slight) conceptual mistake to tie the termination processing to 
the document machinery, especially as overriding NSDocumentController is a bit 
hacky even when done right. I also think it’s a mistake to override 
“terminate:”, because it’s just an action method and you can’t be certain that 
it’s actually going to be called. (The standard menu item could have a 
different action method name in the future, or there may be paths within Cocoa 
that don’t invoke the action method.)

Instead, the “applicationWillTerminate:” override of your app delegate seems 
like the right place, especially because it explicitly permits you to delay 
terminate while you do stuff, without having to run the run loop manually.  
That’s the *point* of the “applicationWillTerminate:” mechanism.

The consequence of using this override, though, is that documents may already 
have been closed. So, what I would suggest is maintaining a separate pool of 
“tasks” (a set of document references would be the simplest approach). In an 
override of “close”, start the user cancellable activity and remove the 
corresponding task from the pool. In “appWillTerminate:”, trigger any remaining 
tasks, and send the termination reply when they’re all done.

The reason I’m suggesting “close” rather than “canClose…” is just that it’s 
simpler, and it avoids getting tangled up in any possible code path where the 
close is prevented.

___

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: XCTest and window restoration

[Quincey Morris]

(resent because I forgot to copy the list)

On Aug 24, 2017, at 17:30 , Samuel Williams > wrote:
> 
> What am I doing wrong?

Nothing wrong, AFAICT. There is a scheme run option for disabling state 
restoration. Maybe setting that option for your testing schemes will solve your 
problem.

___

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: NSMutableParagraphStyle -paragraphSpacingBefore

[Quincey Morris]

On Aug 22, 2017, at 10:02 , Jonathan Mitchell  wrote:
> 
> I don’t seem to be having much luck getting NSMutableParagraphStyle 
> -paragraphSpacingBefore to render.

To render where? I have never found a way of getting it to be honored at the 
*top* of a text container, only after a non-empty, non-trivial paragraph of 
text.

___

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: Question about Audio for iOS (SessionCategory?)

[Quincey Morris]

On Aug 18, 2017, at 10:47 , Eric E. Dolecki  wrote:
> 
> I would assume that the audio would come back up. And wouldn't think my app 
> would pause Apple Music when it starts up...

Unless someone else jumps in with the answer, I’d say it’s TSI time!

___

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: NSUserDefault controller bindings - observeValueForKeyPath called twice?

[Quincey Morris]

On Aug 18, 2017, at 02:23 , Nick  wrote:
> 
> The problem is that observeValueForKeyPath is being called twice every time
> I move the slider or enter a new value in the edit.

This may be an artifact of updating the “model” (i.e. UserDefaults”) via a 
binding, and you may not be able to control it. I would suggest not wasting any 
effort on preventing the double notification, but rather filter unnecessary 
notifications in your observer method. (You can set the options for passing the 
new and old values into the observer method, if you don’t wan’t to track the 
actual values yourself.)

___

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: Question about Audio for iOS (SessionCategory?)

[Quincey Morris]

On Aug 18, 2017, at 10:10 , Eric E. Dolecki  wrote:
> 
>try audioSession.setCategory(AVAudioSessionCategoryPlayback, with: 
> [.allowBluetooth, .mixWithOthers])

According to the documentation, AVAudioSessionCategoryPlayback will “interrupt” 
other audio that *doesn’t* have the mixWithOthers option, and this is defined 
here:


https://developer.apple.com/library/content/documentation/Audio/Conceptual/AudioSessionProgrammingGuide/HandlingAudioInterruptions/HandlingAudioInterruptions.html
 


That makes it sound like it’s up to the *other* application to resume after an 
interruption, and it’s not under your control. What’s odd is that the first 
table here:


https://developer.apple.com/library/content/documentation/Audio/Conceptual/AudioSessionProgrammingGuide/AudioSessionCategoriesandModes/AudioSessionCategoriesandModes.html
 


says this behavior can be changed by an “override switch” without saying what 
that means. This page:


https://developer.apple.com/library/content/documentation/Audio/Conceptual/AudioSessionProgrammingGuide/AudioSessionBasics/AudioSessionBasics.html
 


suggests that it might mean the category options, but it’s not clear. Have you 
tried the “duckOthers” option, as well as or instead of “mixWithOthers”?

___

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: transition custom views

[Quincey Morris]

On Aug 10, 2017, at 11:38 , J.E. Schotsman  wrote:
> 
> No, it’s a xib-based app.

I think it’s a bit harder, because with a storyboard you can use segues, and 
set them up in IB.

With the proviso that I haven’t tried what I’m about to suggest, here’s how I 
understand what you’d need to do:

1. Make a separate XIB file for a view controller (parent) and separate XIB 
files for a view controller for each view that your popup switches between 
(children).

2. Delete the tab that you previously were using for this from the window XIB 
(or wherever it is).

3. Instantiate the parent view controller and child view controllers from their 
various NIBs, and assemble them into a hierarchy (2 deep) using the parent’s 
addChildViewController, or setting the childViewControllers array directly.

3. Programmatically (e.g. in a viewDidLoad or windowDidLoad) create a new 
NSTabViewItem using the init(viewController:) initializer.

4. Add this new tab to your tab view.

5. Invoke transition(from:to:options:completionHandler:), probably in an action 
method in the parent view controller, to switch between its child views.

(“Parent” in this case means relative to the switchable view. It is, of course, 
nested within the tab view/view controller hierarchy.)

If you don’t want to create a new tab programmatically, you can avoid that step 
by keeping the existing tab item, with nothing in its view, and adding the 
parent view controller’s view as a subview of the tab item’s (now empty) view, 
introducing an extra level of views.

Also, you’ll need to pay attention to auto-layout constraints, to make sure 
that the the tab view sizes propagate down to the sub-hierarchy you add.

As I say, I haven’t tried this, so I may be overlooking something crucial, but 
I think this would be the general approach.


P.S. If you don’t need to use "transition(from:to:options:completionHandler:)” 
specifically, there are likely easier ways of getting much the same effect. For 
example, you implement the contents of *that* one tab’s view as a nested 
tab-less tab view, and use tab switching of the inner tab view when choosing an 
item in the popup. That leaves child view controllers out of the picture, which 
simplifies the necessary infrastructure. If you really want child view 
controllers (which is a good thing!), you have to do something like the above, 
or switch to a storyboard and use segues.


___

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: transition custom views

[Quincey Morris]

On Aug 10, 2017, at 08:36 , J.E. Schotsman  wrote:
> 
> I would like to use the  transition(from:to:options:completionHandler:)  
> method of NSViewController but the tab view item's viewController property is 
> nil.

Are you using a storyboard for the window?


___

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: Is "-init" really needed?

[Quincey Morris]

I don’t have a problem with using “new” vs. alloc/init, but there are a couple 
of technical issues hiding behind this, though in current practice they make 
little difference.

1. NSObject has “new” with a standard meaning. That means you can use “new” on 
any subclass where it’s OK to use the simple “init” without parameters. 
However, for classes that need parameters, or have multiple inits, there’s no 
standard “newWithX:…” class method unless you provide it yourself.

You can’t really provide this for Cocoa classes (you could try adding it via a 
category, but this seems like a bad idea), which means your code uses a mixture 
of strategies to create instances, even of the same class, depending on the 
parameters needed. If that doesn’t bother you, fine. This is purely a matter of 
preference.

2. In modern Obj-C, a class method beginning with “new…” is specially 
meaningful to the compiler under ARC. By default, it has +1 ownership semantics 
for the returned reference. Using Jens’ earlier example, that means that the 
following are subtly different:

>   [NSArray array] // +0 semantics
>   [NSArray new]   // +1 semantics

For custom “new…” methods, the declaration can override the default semantics 
with a compile-time attribute, which means you cannot in general be certain of 
the semantics without looking at the declaration.

Of course, if the *calling* code is also ARC, then it doesn’t matter, because 
ARC keeps track of the semantics for you.

So, as I said, little practical difference.
___

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: Best practice with NSProgressIndicator

[Quincey Morris]

On Jul 28, 2017, at 14:16 , Mark Allan  wrote:
> 
> Reducing the frequency of NSXPC messages was a secondary goal to figuring out 
> how often the main app ought to be updating the UI.

I’d be interested in knowing why you didn’t say that the other way round. 
Surely reducing the frequency of the XPC *progress* messages eliminates the 
need for the main app thread to do anything special?

___

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: Best practice with NSProgressIndicator

[Quincey Morris]

On Jul 28, 2017, at 08:57 , Mark Allan  wrote:
> 
> I have an app with a helper tool that performs some lengthy process in a loop 
> and reports progress to the user.  It works out how many iterations of the 
> loop will be needed, sets the progressbar.maxValue, and then increments the 
> progress bar's value on each iteration.

Can you clarify this description? Is the helper tool running in a separate 
process, in which case how (and how often) is it reporting progress back to the 
app? Is it the helper tool that’s looping progressbar.maxValue times? What is 
the app doing while the helper tool is running?

Also, it seems like a “code smell” if the code that’s iterating millions of 
times is updating a progress bar directly. Actually, two issues:

1. In a MVC design, code that’s calculating like this is generally part of the 
model, and shouldn’t be aware of what UI element is reporting progress, even 
though the model may provide some progress information.

2. The iteration is presumably on a background thread, and it’s not clear how 
you transfer the progress information safely to the main thread.

The normal solution to #1 is some kind of observation (of the progress 
information), and to #2 is some kind of trampoline. Both of those techniques 
lend themselves to thinning the frequency of UI updates, so you have choices 
about how to do that.

I’m agnostic on timer vs. elapsed-time update thinning. Both are easy enough to 
do, once you figure out *where* to do them.

___

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: Who owns a child view controller?

[Quincey Morris]

On Jul 14, 2017, at 11:43 , Greg Parker  wrote:
> 
> it would be deallocated after the callee relinquishes ownership and before 
> the caller can retake ownership

See? I tried to reason about retain counts, and got it wrong. :)


___

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: document-scoped bookmark

[Quincey Morris]

On Jul 14, 2017, at 11:57 , J.E. Schotsman  wrote:
> 
> I want to create document-scoped security bookmarks.
> However, there seems to be no API for this.

Huh? It’s described here:

https://developer.apple.com/library/content/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW16
 


(under the heading “Security-Scoped Bookmarks and Persistent Resource Access”), 
plus this:

https://developer.apple.com/library/content/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/uid/TP40011195-CH4-SW18
 


(“Enabling Security-Scoped Bookmark and URL Access”)

___

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