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

[J.E. Schotsman]

> On 10 Aug 2017, at 19:38, Quincey Morris 
>  wrote:
> 
> 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?

No, it’s a xib-based app. I am using Xcode 8.3.3, Xcode 3.2 compatible format.

Jan E.

___

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?

[Jean-Daniel]

> Le 10 août 2017 à 16:09, Charles Srstka  a écrit :
> 
>> On Aug 10, 2017, at 8:59 AM, Alastair Houghton 
>>  wrote:
>> 
>> On 10 Aug 2017, at 14:57, gerti-cocoa...@bitart.com 
>>  wrote:
>>> 
>>> On Aug 10, 2017, at 02:18, Alastair Houghton  
>>> wrote:
 
 Personally I *would* still discourage +new in favour of class-specific 
 convenience constructors because I think it’s less expressive and also 
 less consistent (e.g. +array is better, in my opinion, than +new, not 
 least because +arrayWithObjects: and others exist).
>>> 
>>> [NSArray new] := [[NSArray alloc]init]
>>> 
>>> [NSArray array] := [[[NSArray alloc]init]autorelease]
>>> 
>>> +array and friends came along with the introduction of autorelease pools, 
>>> to replace +new with something that didn't imply ownership (the oft 
>>> mentioned special meaning of "new" as prefix). So while with ARC they are 
>>> essentially equivalent, previously they were not.
>> 
>> Yes, I know that, thanks.
>> 
>> The point is, with ARC, they’re equivalent, and most new code uses ARC, so, 
>> again, I’d discourage +new in favour of class-specific convenience 
>> constructors.
>> 
>> Kind regards,
>> 
>> Alastair.
> 
> They’re equivalent syntactically, but performance-wise, +array and friends 
> will cause the object to be put into an autorelease pool. Therefore, +new is 
> better for performance.

Putting an object into an autorelease pool is very cheap. It is just a write of 
the pointer value in a thread local array. When using ARC, the object is still 
pushed in the autoreleased stack, but it may be immediately pop by the caller. 
So yes, +array still have a couple of additional operations to perform,  but it 
should be mesure to tell if this is significant performance wise.

___

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

transition custom views

[J.E. Schotsman]

Hello,

In a Mac app I have a window with a tab view.
One of the tabs contains custom views between which the user can switch with a 
popup menu.
I would like to use the  transition(from:to:options:completionHandler:)  method 
of NSViewController but the tab view item's viewController property is nil.
Am I out of luck or does a solution exist?

TIA,

Jan E.

___

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?

[John McCall]

> On Aug 10, 2017, at 11:13 AM, Charles Srstka  wrote:
>> On Aug 10, 2017, at 9:44 AM, Alastair Houghton 
>>  wrote:
>> 
>> On 10 Aug 2017, at 15:24, Jeremy Hughes > > wrote:
>>> 
 On 10 Aug 2017, at 15:15, Alastair Houghton > wrote:
 
 On 10 Aug 2017, at 15:09, Charles Srstka > wrote:
> 
> They’re equivalent syntactically, but performance-wise, +array and 
> friends will cause the object to be put into an autorelease pool. 
> Therefore, +new is better for performance.
 
 Not with ARC they don’t.  The ARC logic circumvents the autorelease pool 
 in that case.
>>> 
>>> Are you sure?
>> 
>> Yes, I’m sure.  At the call site, ARC causes the compiler to emit a call to 
>> objc_retainAutoreleasedReturnValue() or 
>> objc_unsafeClaimAutoreleasedReturnValue(), while in the method itself, ARC 
>> will use objc_autoreleaseReturnValue() or 
>> objc_retainAutoreleaseReturnValue().  The latter looks at the code for the 
>> call site and, assuming it matches, it will *not* do the autorelease and 
>> will set a flag that causes objc_retainAutoreleasedReturnValue() to 
>> eliminate the retain.
> 
> The frameworks (and thus, the implementation of +array) are not built using 
> ARC. The -autorelease method is called manually, and the object is put in the 
> autorelease pool. You can see this for yourself by making a small test app 
> that calls [NSMutableArray array] and running it in Instruments, where the 
> autorelease will be clearly visible.

Autoreleases done by -autorelease can still be reclaimed by 
objc_retainAutoreleasedReturnValue.

The autorelease-reclaim optimization is not reliable, and there are a number of 
caveats that make testing it tricky.  That is why we generally refer to it as 
an optimization, rather than claiming it as a semantic guarantee.  In your test 
app, you are almost certainly running into a well-known problem where the first 
attempt to reclaim an autorelease fails on x86-64 (because of a detail of 
dynamic linking).

John.
___

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?

[Charles Srstka]

> On Aug 10, 2017, at 9:44 AM, Alastair Houghton  
> wrote:
> 
> On 10 Aug 2017, at 15:24, Jeremy Hughes  > wrote:
>> 
>>> On 10 Aug 2017, at 15:15, Alastair Houghton >> > wrote:
>>> 
>>> On 10 Aug 2017, at 15:09, Charles Srstka >> > wrote:
 
 They’re equivalent syntactically, but performance-wise, +array and friends 
 will cause the object to be put into an autorelease pool. Therefore, +new 
 is better for performance.
>>> 
>>> Not with ARC they don’t.  The ARC logic circumvents the autorelease pool in 
>>> that case.
>> 
>> Are you sure?
> 
> Yes, I’m sure.  At the call site, ARC causes the compiler to emit a call to 
> objc_retainAutoreleasedReturnValue() or 
> objc_unsafeClaimAutoreleasedReturnValue(), while in the method itself, ARC 
> will use objc_autoreleaseReturnValue() or 
> objc_retainAutoreleaseReturnValue().  The latter looks at the code for the 
> call site and, assuming it matches, it will *not* do the autorelease and will 
> set a flag that causes objc_retainAutoreleasedReturnValue() to eliminate the 
> retain.

The frameworks (and thus, the implementation of +array) are not built using 
ARC. The -autorelease method is called manually, and the object is put in the 
autorelease pool. You can see this for yourself by making a small test app that 
calls [NSMutableArray array] and running it in Instruments, where the 
autorelease will be clearly visible.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is "-init" really needed?

[Alastair Houghton]

On 10 Aug 2017, at 15:24, Jeremy Hughes  wrote:
> 
>> On 10 Aug 2017, at 15:15, Alastair Houghton  
>> wrote:
>> 
>> On 10 Aug 2017, at 15:09, Charles Srstka  wrote:
>>> 
>>> They’re equivalent syntactically, but performance-wise, +array and friends 
>>> will cause the object to be put into an autorelease pool. Therefore, +new 
>>> is better for performance.
>> 
>> Not with ARC they don’t.  The ARC logic circumvents the autorelease pool in 
>> that case.
> 
> Are you sure?

Yes, I’m sure.  At the call site, ARC causes the compiler to emit a call to 
objc_retainAutoreleasedReturnValue() or 
objc_unsafeClaimAutoreleasedReturnValue(), while in the method itself, ARC will 
use objc_autoreleaseReturnValue() or objc_retainAutoreleaseReturnValue().  The 
latter looks at the code for the call site and, assuming it matches, it will 
*not* do the autorelease and will set a flag that causes 
objc_retainAutoreleasedReturnValue() to eliminate the retain.

> We had a discussion about autorelease pools recently, and it seems that 
> they’re still used by Cocoa APIs (to support ARC and non-ARC code).

Yes, autorelease pools still exist and are still used.  Not all code uses ARC, 
and for the above optimisation to happen, the code needs to use the functions 
mentioned, which will only happen if either (a) it’s compiled with ARC, or (b) 
those calls are used explicitly.  You can see the code for this in the 
Objective-C runtime code, https://opensource.apple.com/source/objc4/objc4-709/runtime/objc-object.h.auto.html>
 (search for SUPPORT_RETURN_AUTORELEASE).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is "-init" really needed?

[Jeremy Hughes]

> On 10 Aug 2017, at 15:15, Alastair Houghton  
> wrote:
> 
> On 10 Aug 2017, at 15:09, Charles Srstka  wrote:
>> 
>> They’re equivalent syntactically, but performance-wise, +array and friends 
>> will cause the object to be put into an autorelease pool. Therefore, +new is 
>> better for performance.
> 
> Not with ARC they don’t.  The ARC logic circumvents the autorelease pool in 
> that case.

Are you sure?

We had a discussion about autorelease pools recently, and it seems that they’re 
still used by Cocoa APIs (to support ARC and non-ARC code).

Jeremy

___

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?

[Alastair Houghton]

On 10 Aug 2017, at 15:09, Charles Srstka  wrote:
> 
> They’re equivalent syntactically, but performance-wise, +array and friends 
> will cause the object to be put into an autorelease pool. Therefore, +new is 
> better for performance.

Not with ARC they don’t.  The ARC logic circumvents the autorelease pool in 
that case.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is "-init" really needed?

[Charles Srstka]

>  On Aug 10, 2017, at 8:59 AM, Alastair Houghton 
>  wrote:
> 
> On 10 Aug 2017, at 14:57, gerti-cocoa...@bitart.com 
>  wrote:
>> 
>> On Aug 10, 2017, at 02:18, Alastair Houghton  
>> wrote:
>>> 
>>> Personally I *would* still discourage +new in favour of class-specific 
>>> convenience constructors because I think it’s less expressive and also less 
>>> consistent (e.g. +array is better, in my opinion, than +new, not least 
>>> because +arrayWithObjects: and others exist).
>> 
>> [NSArray new] := [[NSArray alloc]init]
>> 
>> [NSArray array] := [[[NSArray alloc]init]autorelease]
>> 
>> +array and friends came along with the introduction of autorelease pools, to 
>> replace +new with something that didn't imply ownership (the oft mentioned 
>> special meaning of "new" as prefix). So while with ARC they are essentially 
>> equivalent, previously they were not.
> 
> Yes, I know that, thanks.
> 
> The point is, with ARC, they’re equivalent, and most new code uses ARC, so, 
> again, I’d discourage +new in favour of class-specific convenience 
> constructors.
> 
> Kind regards,
> 
> Alastair.

They’re equivalent syntactically, but performance-wise, +array and friends will 
cause the object to be put into an autorelease pool. Therefore, +new is better 
for performance.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is "-init" really needed?

[Alastair Houghton]

On 10 Aug 2017, at 14:57, gerti-cocoa...@bitart.com wrote:
> 
> On Aug 10, 2017, at 02:18, Alastair Houghton  
> wrote:
>> 
>> Personally I *would* still discourage +new in favour of class-specific 
>> convenience constructors because I think it’s less expressive and also less 
>> consistent (e.g. +array is better, in my opinion, than +new, not least 
>> because +arrayWithObjects: and others exist).
> 
> [NSArray new] := [[NSArray alloc]init]
> 
> [NSArray array] := [[[NSArray alloc]init]autorelease]
> 
> +array and friends came along with the introduction of autorelease pools, to 
> replace +new with something that didn't imply ownership (the oft mentioned 
> special meaning of "new" as prefix). So while with ARC they are essentially 
> equivalent, previously they were not.

Yes, I know that, thanks.

The point is, with ARC, they’re equivalent, and most new code uses ARC, so, 
again, I’d discourage +new in favour of class-specific convenience constructors.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is "-init" really needed?

[gerti-cocoadev]

> On Aug 10, 2017, at 02:18, Alastair Houghton  
> wrote:
> 
> Personally I *would* still discourage +new in favour of class-specific 
> convenience constructors because I think it’s less expressive and also less 
> consistent (e.g. +array is better, in my opinion, than +new, not least 
> because +arrayWithObjects: and others exist).

[NSArray new] := [[NSArray alloc]init]

[NSArray array] := [[[NSArray alloc]init]autorelease]

+array and friends came along with the introduction of autorelease pools, to 
replace +new with something that didn't imply ownership (the oft mentioned 
special meaning of "new" as prefix). So while with ARC they are essentially 
equivalent, previously they were not.

Gerd
___

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?

[Alastair Houghton]

On 10 Aug 2017, at 00:28, Doug Hill  wrote:
> 
>> - Performance - it incurs an extra message send (which would have been an 
>> issue back in the day)
> 
> +new requires no extra message. It's just a shorthand for [[SomeClassname 
> alloc] init]

Er, yes it does.  It sends a +new message to the class object, which, in turn, 
sends -alloc and -init messages.  So that’s three messages rather than two.  
It’s no big deal on current machines, but it would have been back on the old 
68K boxes.  It isn’t just syntax.

>> - Clarity - [[… alloc] init] shows clearly that it’s a two step operation 
>> (some classes support being *re*-initialized, so you can call initialisers 
>> more than once; other classes don’t actually need initialising)
> 
> Some say that it's far more confusing and hard to read the alloc/init syntax.

:-D Some people say all kinds of things.  Anyway, you’ve misunderstood my list 
as *my* arguments.  I don’t necessarily agree with all of them - I was just 
pondering why it might have been discouraged.

>> - If +new was the way to go, you’d need variants of +new for each variant of 
>> -init (or you have to use [[… alloc] init] anyway)
> 
> There has never been an issue with this. +new saves you some typing for one 
> syntax but has no impact on anything else.

Except it isn’t just syntax, and having +new but then e.g. +stringWithFormat 
while not having +newWithFormat: makes little sense.

>> - The fact that convenience constructors were often written naming the 
>> object, e.g. [NSString stringWithFormat:…], [NSArray array].  +new would 
>> duplicate that, but isn’t as nice to read or look at.  OK, +new doesn’t 
>> autorelease, but still.
> 
> With ARC, autorelease behavior is essentially hidden from the developer and 
> doesn't really matter any more.

Agreed.  But I wasn’t talking about a time in which ARC even existed.  I was 
trying to suggest reasons why it might have been discouraged in the past.

Personally I *would* still discourage +new in favour of class-specific 
convenience constructors because I think it’s less expressive and also less 
consistent (e.g. +array is better, in my opinion, than +new, not least because 
+arrayWithObjects: and others exist).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com