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