Re: How to wire up document exporting?

[Charles Jenkins]

Thanks, Quincey. I really do want an export feature, and I think you've given 
me enough good information to get me started :-)

-- 

Charles

On January 28, 2015 at 20:42:31, Quincey Morris 
(quinceymor...@rivergatesoftware.com) wrote:

On Jan 28, 2015, at 16:16 , Charles Jenkins  wrote:

I need to have a File > Export command to save the document in OpenXML format. 
I’ve done some research in the Developer Library, and the best clues I’ve found 
so far are in the Sketch app. Sketch manages multiple output types by 
overriding NSDocument’s dataOfType:error: and paying attention to the requested 
type name. Somehow that gets called by saveDocumentTo:

My app needs to work more like Pages, by presenting a dialog confirming export 
options before the OpenXML file is generated. I can see where I might have to 
do this by overriding saveDocumentTo: so my options dialog will appear and 
eventually dataOfType:error: will be called. But I’m worried that dataOfType 
and fileWrapperOfType can’t both be used???

(It's not clear whether you really want File -> Export, or whether you want an 
alternative document type for a regular Save/Save As/etc. …)

There’s no set in stone way of handling export, but I think a rational place to 
start is to think of it as writing a file format that’s incompatible with your 
document editing environment. That is, any file formats in which you can save 
your data model without loss of information are a document type, while an 
export type implies you can’t re-open the exported file and have the document 
data you started with.

This can get a little confusing, because your plist might have “document” type 
definitions in your plist for types that your document can’t save as — if you 
can view or import other file formats, for example.

But generally, document types are handled by the NSDocument save mechanism, 
exports aren’t. So, when the user chooses an export function:

— If necessary, put up a sheet asking for the export parameters.

If this information is simple, you can add it as an accessory view of the save 
panel, and skip this step. However, some things are awkward to do from the save 
panel, particularly validation of user choices, so it’s often easier to use a 
separate sheet first.

— Put up a NSSavePanel asking for the destination of the save. (This will 
automatically take care of sandboxing restrictions.)

— If necessary, customize the save panel to allow the user to choose an export 
format. (Often, the export format is determined by the originally chosen export 
function, or is chosen in the export parameters sheet, but sometimes it’s 
clearer to let the specific format be chosen at the same time as the file is 
named.)

Once you’ve collected all this information, you can write the export file 
directly, not using the NSDocument save mechanism. The only thing you have to 
take care with is concurrency issues with the document/model, especially if you 
move the export to a background thread to avoid blocking the main thread.

___

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: Allow tap events outside a custom UIPresentationController on iPad(iOS 8)

[Mazzaroth M.]

I forgot to add the overridden methods:

- (CGRect)frameOfPresentedViewInContainerView
{
CGRect presentedViewFrame = CGRectZero;
CGRect containerBounds = [[self containerView] bounds];

presentedViewFrame.size = [self
sizeForChildContentContainer:(UIViewController *)[self
presentedViewController]

 withParentContainerSize:containerBounds.size];

presentedViewFrame.origin.x = containerBounds.size.width -
presentedViewFrame.size.width;
NSLog(@"presentedViewFrame: %@",
NSStringFromCGRect(presentedViewFrame));
return presentedViewFrame;

}


- (CGSize)sizeForChildContentContainer:(id )container
withParentContainerSize:(CGSize)parentSize
{
return CGSizeMake(floorf(parentSize.width / 3.0),
  parentSize.height);
}


On Wed, Jan 28, 2015 at 7:20 PM, Mazzaroth M.  wrote:

> I want to have a custom `modal` appear over the Master portion of a
> UISplitViewController. So far, I've managed to cobble together a
> UIViewControllerTransitioningDelegate, a UIPresentationController subclass.
>
> chartSummaryNavigationController.transitioningDelegate =
> _transitioningDelegate;
> [self presentViewController:chartSummaryNavigationController
> animated:YES completion:NULL];
>
> in the UIPresentationViewController subclass, I override
>
> -frameOfPresentedViewInContainerView
> and
> -sizeForChildContentContainer:withParentContainerSize:
>
> so far. Just hoping to get it `working` and in
> -sizeForChildContentContainer:withParentContainerSize: return a smaller
> width than the landscape iPad. Voila, the modal does a standard
> presentation transition from the bottom of the screen. However, tapping
> anywhere around the presented modal results in no events, which is what I
> actually want. In -frameOfPresentedViewInContainerView I noticed that
> self.containerView.frame returns a frame the size of the entire iPad. Is
> that why I get no events around the presentedViewController? If so, how do
> I reduce the frame of self.containerView to match that of the presented
> controller?
>
> If that's not the problem, is there another way to allow tap events
> outside a presented view controller?
>
> Michael
>
>
___

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: NSString stringByAbbreviatingWithTildeInPath and Sandboxing

[Jon Baumgartner]

I’m happy to do this, but is this really a bug? I was just thinking there might 
be an alternate way to accomplish this.

On 1/27/2015 4:03 PM, Kyle Sluder wrote:

Could you please file a Radar describing your use case and share the
number 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: NSString stringByAbbreviatingWithTildeInPath and Sandboxing

[Kyle Sluder]

Even in a sandbox, you can get the user’s home directory using getpwuid(3) as 
mentioned in the docs: 
https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html

So you could just search through your string and replace occurrences of that 
with a tilde, but then you have to worry about encodings and all that muck. 
Since there’s no security risk here, it’s reasonable to ask that the existing 
API work in a sandbox too.

--Kyle Sluder

> On Jan 29, 2015, at 7:45 AM, Jon Baumgartner  
> wrote:
> 
> I’m happy to do this, but is this really a bug? I was just thinking there 
> might be an alternate way to accomplish this.
> 
>> On 1/27/2015 4:03 PM, Kyle Sluder wrote:
>> Could you please file a Radar describing your use case and share the
>> number 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: drawRect runs twice, bounds are changed in between

[N!K]

Thank you.


On Jan 28, 2015, at 8:30 PM, Graham Cox  wrote:

> 
>> On 29 Jan 2015, at 3:05 pm, N!K  wrote:
>> 
>> NSBezierPath* temp;   is in the list of declarations.
>> This snippet is in drawRect:
>> 
>>   NSAffineTransform* tfm = [[NSAffineTransform alloc] init];
>>   [tfm scaleXBy:scaleX yBy:scaleY];
>>  temp  = [tfm transformBezierPath:_path];
>>  NSLog(@“\n\n temp = %p\n\n",temp);
>> 
>> 
>> I hope ARC keeps cleaning them up. Or do I have a memory leak? If so, I’d 
>> appreciate some guidance on how to fix it.
> 
> 
> You're fine leaks-wise, but your code might be cleaner. The bezier path 
> returned by [tfm transformBezierPath] is autoreleased. ARC cleans up tfm, 
> temp is released at the end of the event cycle. If temp is an ivar, and it's 
> not used anywhere else, just make it a local var (it will be stale after the 
> event cycle completes anyway). If it's an ivar and it is referenced 
> elsewhere, you probably should make it a strong property instead.
> 
> --Graham
> 
> 


___

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

Subclassing NSControl and inheritance of target, action properties

[Graham Cox]

NSControl has properties target, action.

I want to subclass NSControl but my custom control doesn't use a cell 
internally. I want to inherit the target, action properties so that I can hook 
these up for my custom subclass in IB (If I don't inherit NSControl, IB is 
unaware that I have target, action properties that can be connected in the 
usual way). The standard control class actually implements the storage for 
these properties in its cell, so if I don't redeclare the properties, there's 
no storage and so the properties always return nil.

If I redeclare the storage, to use my own storage ivars via @synthesize, the 
properties have to be nonatomic, but the original properties don't define this, 
so the compiler complains that the redeclared properties do not match the 
originals.

What's the right way to do this, so that I can cleanly inherit the properties 
without complaint, but back them with whatever storage implementation I wish?

--Graham



___

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: Subclassing NSControl and inheritance of target, action properties

[Roland King]

> On 30 Jan 2015, at 07:44, Graham Cox  wrote:
> 
> NSControl has properties target, action.
> 
> 
> If I redeclare the storage, to use my own storage ivars via @synthesize, the 
> properties have to be nonatomic, but the original properties don't define 
> this, so the compiler complains that the redeclared properties do not match 
> the originals.
> 

I don't see this in a quick test I just typed into Xcode. I did this in the .h 
file

@interface RKControl : NSControl
@property SEL   action;
@property (weak) id target;
@end


and .m

#import "RKControl.h"
@implementation RKControl
{
SEL myAction;
id  __weak myTarget;
}

@synthesize action=myAction;
@synthesize target=myTarget;
@end

and I get no warnings or errors and the properties I believe match the 
originals. I dropped one on a project as an NSView, set the class, connected up 
a random target/action and debugged viewDidLoad to check the control was there 
and had a correct target/action. 

What are you seeing which is different? If you are having a problem then does 
it work if you don't use synthesize and go back to the good old -(thing)value, 
-(void)setValue:(thing)value? 



___

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: Subclassing NSControl and inheritance of target, action properties

[Graham Cox]

> On 30 Jan 2015, at 11:12 am, Roland King  wrote:
> 
> I don't see this in a quick test I just typed into Xcode. I did this in the 
> .h file
> 
> @interface RKControl : NSControl
> @property SEL action;
> @property (weak) id   target;
> @end
> 
> 
> and .m
> 
> #import "RKControl.h"
> @implementation RKControl
> {
>   SEL myAction;
>   id  __weak myTarget;
> }
> 
> @synthesize action=myAction;
> @synthesize target=myTarget;
> @end
> 
> and I get no warnings or errors and the properties I believe match the 
> originals. I dropped one on a project as an NSView, set the class, connected 
> up a random target/action and debugged viewDidLoad to check the control was 
> there and had a correct target/action. 
> 
> What are you seeing which is different? If you are having a problem then does 
> it work if you don't use synthesize and go back to the good old 
> -(thing)value, -(void)setValue:(thing)value? 


Hmmm, that's odd. My code is nearly identical, but for each property I get this 
warning ("semantic issue"):


'atomic' attribute on property 'action' does not match the property inherited 
from 'NSControl'
'atomic' attribute on property 'target' does not match the property inherited 
from 'NSControl'

The only difference I see is that I'm declaring my ivars as part of the 
@interface, not the @implementation - is that a new thing? I didn't know you 
could do that (though it makes sense).

--Graham


___

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: Subclassing NSControl and inheritance of target, action properties

[Quincey Morris]

On Jan 29, 2015, at 16:26 , Graham Cox  wrote:
> 
> 'atomic' attribute on property 'action' does not match the property inherited 
> from 'NSControl'

The 10.10 SDK uses real @property declarations, but doesn’t specify atomicity, 
which means the property defaults to atomic. You said before that "the 
properties have to be nonatomic”. So you’re declaring them nonatomic? You can’t.

Note that it makes no difference. On all existing Apple architectures, “atomic” 
properties of 8-byte quantities (or smaller) (including pointers) have no 
overhead, so atomic properties synthesize the same code as nonatomic 
properties. (Well, that’s what I recall Greg Parker saying, a few months ago.)



___

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: Subclassing NSControl and inheritance of target, action properties

[Roland King]

> On 30 Jan 2015, at 08:26, Graham Cox  wrote:
> 
> 
>> On 30 Jan 2015, at 11:12 am, Roland King  wrote:
>> 
>> I don't see this in a quick test I just typed into Xcode. I did this in the 
>> .h file
>> 
>> @interface RKControl : NSControl
>> @property SELaction;
>> @property (weak) id  target;
>> @end
>> 
>> 
>> and .m
>> 
>> #import "RKControl.h"
>> @implementation RKControl
>> {
>>  SEL myAction;
>>  id  __weak myTarget;
>> }
>> 
>> @synthesize action=myAction;
>> @synthesize target=myTarget;
>> @end
>> 
>> and I get no warnings or errors and the properties I believe match the 
>> originals. I dropped one on a project as an NSView, set the class, connected 
>> up a random target/action and debugged viewDidLoad to check the control was 
>> there and had a correct target/action. 
>> 
>> What are you seeing which is different? If you are having a problem then 
>> does it work if you don't use synthesize and go back to the good old 
>> -(thing)value, -(void)setValue:(thing)value? 
> 
> 
> Hmmm, that's odd. My code is nearly identical, but for each property I get 
> this warning ("semantic issue"):
> 
> 
> 'atomic' attribute on property 'action' does not match the property inherited 
> from 'NSControl'
> 'atomic' attribute on property 'target' does not match the property inherited 
> from 'NSControl'
> 
> The only difference I see is that I'm declaring my ivars as part of the 
> @interface, not the @implementation - is that a new thing? I didn't know you 
> could do that (though it makes sense).
> 
> --Graham
> 

I can get that warning too, but only if I explicitly declare the property 
'nonatomic', like this

@property (readwrite, nonatomic ) SEL   action; // 'atomic' attribute on 
property 'action' does not match the property inherited from 'NSControl'

if I declare them specifically atomic (which I thought was the default) then it 
stops whining. Error message could be more accurate as in 'nonatomic' attribute 
on ... etc. 

___

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: Subclassing NSControl and inheritance of target, action properties

[Roland King]

> 
> The only difference I see is that I'm declaring my ivars as part of the 
> @interface, not the @implementation - is that a new thing? I didn't know you 
> could do that (though it makes sense).
> 

oh and that was Xcode 4.2 + 64-bit runtime. It was one of the changes I 
appreciated in ObjC 2.0 because it uncluttered the header files and put 
implementation details where they deserved to be, in the implementation. 


___

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: Subclassing NSControl and inheritance of target, action properties

[Graham Cox]

> On 30 Jan 2015, at 11:40 am, Roland King  wrote:
> 
> I can get that warning too, but only if I explicitly declare the property 
> 'nonatomic', like this
> 
> @property (readwrite, nonatomic ) SEL action; // 'atomic' attribute on 
> property 'action' does not match the property inherited from 'NSControl'
> 
> if I declare them specifically atomic (which I thought was the default) then 
> it stops whining. Error message could be more accurate as in 'nonatomic' 
> attribute on ... etc. 


OK, solved. I *was* including 'nonatomic', but I took that out. The warning 
remained - for a while. After several recompiles it suddenly removed itself. 
(Actually I've noticed Xcode is pretty slow to remove complaints and errors at 
times, particularly structural things such as missing or mismatched end braces 
when you edit a block of code and then fix up the end braces as needed - the 
warning comes up mid-edit before you've finished and then doesn't go away until 
several recompiles later. Maybe this is another example of Xcode being too 
quick to warn and too slow to realise its mistake.)


>> On 30 Jan 2015, at 11:38 am, Quincey Morris 
>>  wrote:
>> 
>> The 10.10 SDK uses real @property declarations, but doesn’t specify 
>> atomicity, which means the property defaults to atomic. You said before that 
>> "the properties have to be nonatomic”. So you’re declaring them nonatomic? 
>> You can’t.
>> 
>> Note that it makes no difference. On all existing Apple architectures, 
>> “atomic” properties of 8-byte quantities (or smaller) (including pointers) 
>> have no overhead, so atomic properties synthesize the same code as nonatomic 
>> properties. (Well, that’s what I recall Greg Parker saying, a few months 
>> ago.)
> 


Regarding 'nonatomic', in previous times, I've had a different warning when I 
used @synthesize with an assigned ivar and the property was not 'nonatomic'. 
Maybe that's changed but as a result of it I got conditioned to always 
including nonatomic for my properties when I wanted to back them with an ivar. 
From what you're saying, that's not necessary (any more?) if so, it makes a lot 
of my property declarations wrong, or at least verbose. Why even have 
atomic/nonatomic if there's no difference, and if you're writing your own 
setters (a different but related issue), how can you make them atomic anyway?

--Graham
___

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: Subclassing NSControl and inheritance of target, action properties

[Roland King]

> On 30 Jan 2015, at 08:38, Quincey Morris 
>  wrote:
> 
> On Jan 29, 2015, at 16:26 , Graham Cox  > wrote:
>> 
>> 'atomic' attribute on property 'action' does not match the property 
>> inherited from 'NSControl'
> 
> The 10.10 SDK uses real @property declarations, but doesn’t specify 
> atomicity, which means the property defaults to atomic. You said before that 
> "the properties have to be nonatomic”. So you’re declaring them nonatomic? 
> You can’t.
> 
> Note that it makes no difference. On all existing Apple architectures, 
> “atomic” properties of 8-byte quantities (or smaller) (including pointers) 
> have no overhead, so atomic properties synthesize the same code as nonatomic 
> properties. (Well, that’s what I recall Greg Parker saying, a few months ago.)
> 


I can find this 
http://lists.apple.com/archives/objc-language/2013/Apr/msg00119.html 
, is that 
what you were remembering or is there something stronger my google-fu isn't 
finding, which wouldn't be for the first 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: Subclassing NSControl and inheritance of target, action properties

[Quincey Morris]

On Jan 29, 2015, at 17:03 , Graham Cox  wrote:
> 
> Regarding 'nonatomic', in previous times, I've had a different warning when I 
> used @synthesize with an assigned ivar and the property was not 'nonatomic'. 
> Maybe that's changed but as a result of it I got conditioned to always 
> including nonatomic for my properties when I wanted to back them with an ivar.

There used to be errors when the ivar’s actual declaration didn’t match the 
implicit declaration if it would be synthesized. But this has been fixed for 
quite a while.

> From what you're saying, that's not necessary (any more?) if so, it makes a 
> lot of my property declarations wrong, or at least verbose.

Semantically, “nonatomic” is a better choice, because it emphasizes that thread 
safety usually comes from something other than atomicity. Unfortunately, the 
default is “atomic” for historical reasons — a poor decision, in hindsight.

> Why even have atomic/nonatomic if there's no difference, and if you're 
> writing your own setters (a different but related issue), how can you make 
> them atomic anyway?

a. There’s a difference if the property value is (say) a struct.

b. There’s no API contract that there’s no difference. It just happens to be 
true, which means you don’t have to feel anxious about performance with (most) 
atomic properties. In theory, there could be a new supported hardware 
architecture in the future where it matters. (IIRC, it wasn't true for PPC 
architectures, but the locking mechanism was pretty cheap.)

c. If you write your own setter, there’s no way to hook into the atomicity 
mechanism that @synthesize uses. For an atomic non-synthesized property, you’d 
have to provide both a getter and a setter, to get it to actually be atomic. 
And you’d have to do the synchronization yourself, of course.

d. The compiler can’t tell whether you made your (explicit) accessors atomic, 
and it doesn’t try.

Again in hindsight, the implementation details seem fairly screwed up, all the 
way down the line. 



___

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: Subclassing NSControl and inheritance of target, action properties

[Quincey Morris]

On Jan 29, 2015, at 17:18 , Roland King  wrote:
> 
> I can find this 
> http://lists.apple.com/archives/objc-language/2013/Apr/msg00119.html 
> , is 
> that what you were remembering or is there something stronger my google-fu 
> isn't finding, which wouldn't be for the first time? 

I think that’s it. A few months ago, as I said. ;)

The only odd thing is “non-object”. Based on the rest of Greg’s statement, I 
think it’s a typo for “non-struct”. I can’t think of a reason why an 8-byte 
pointer would produce different results from an 8-byte int. But I don’t really 
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: Subclassing NSControl and inheritance of target, action properties

[Greg Parker]

> On Jan 29, 2015, at 5:29 PM, Quincey Morris 
>  wrote:
> 
> On Jan 29, 2015, at 17:18 , Roland King  wrote:
>> 
>> I can find this 
>> http://lists.apple.com/archives/objc-language/2013/Apr/msg00119.html 
>> , is 
>> that what you were remembering or is there something stronger my google-fu 
>> isn't finding, which wouldn't be for the first time? 
> 
> I think that’s it. A few months ago, as I said. ;)
> 
> The only odd thing is “non-object”. Based on the rest of Greg’s statement, I 
> think it’s a typo for “non-struct”. I can’t think of a reason why an 8-byte 
> pointer would produce different results from an 8-byte int. But I don’t 
> really know.

"Non-object" is correct. `atomic` makes a big difference for a strong or weak 
property of object type because objects have retain counts.

There is one exception to the "non-object scalar" claim. On 32-bit ARM 
non-object scalar properties that are larger than 4 bytes are slower when 
atomic. This includes types `double` and `long long`. The problem is that the 
32-bit ARM ABI only aligns storage for those types at 4-byte boundaries, and 
the CPU does not guarantee atomicity for ordinary unaligned 8-byte memory 
access. Atomic accessors for those types need to do extra work.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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

Modifying row rect indent in NSOutlineView

[Andrew White]

I have an NSOutlineView on OS X 10.10.  For non-group row, the indent 
appears to change where each row starts but the rounded rect surrounding 
each row always starts on the left margin.  I want to modify it so that the 
left edge of the rectangle is indented (at least for certain children).


Existing: (pardon the ASCII-art)

( Text)
(Text )
(   Text  )

Desired:

( Text)
   ( Text )
  ( Text  )

I tried subclassing NSOutlineView and catching frameOutlineOfCellAtRow, 
adding to theRect.origin.x and subtracting from theRect.size.width.  This 
didn't seem to make a difference.  I have verified that the overridden 
function is being called and theRect modified, but the rendered output 
doesn't vary.


Is there another way to do this?

(Also, is there a way to customise the rendered indent level on a per-row 
basis, rather than always indentationPerLevel ? )


Thanks

--
Andrew
___

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: Subclassing NSControl and inheritance of target, action properties

[Quincey Morris]

On Jan 29, 2015, at 19:47 , Greg Parker  wrote:
> 
> `atomic` makes a big difference for a strong or weak property of object type 
> because objects have retain counts.

Er, I feel stupid but I don’t understand. How do the retain counts affect this? 
On the one hand, properties are not the only place where retain counts are 
manipulated, and on the other hand, don’t retain count changes have to be 
atomic anyway?


___

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: Modifying row rect indent in NSOutlineView

[Quincey Morris]

On Jan 29, 2015, at 20:45 , Andrew White  wrote:
> 
> I tried subclassing NSOutlineView and catching frameOutlineOfCellAtRow, 
> adding to theRect.origin.x and subtracting from theRect.size.width.  This 
> didn't seem to make a difference.  I have verified that the overridden 
> function is being called and theRect modified, but the rendered output 
> doesn't vary.

Do you mean ‘frameOfOutlineCellAtRow’? That’s the function for the other thing 
you’re asking for — it moves the disclosure triangle.

I’m not sure what "the rounded rect surrounding each row” refers to? I don’t 
see any rounded rects in 10.10 except while dragging “onto”. Is that what you 
mean?

> (Also, is there a way to customise the rendered indent level on a per-row 
> basis, rather than always indentationPerLevel ? )

‘frameOfOutlineCellAtRow’ :)



___

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: Subclassing NSControl and inheritance of target, action properties

[Ken Thomases]

On Jan 29, 2015, at 10:54 PM, Quincey Morris 
 wrote:

> On Jan 29, 2015, at 19:47 , Greg Parker  wrote:
>> 
>> `atomic` makes a big difference for a strong or weak property of object type 
>> because objects have retain counts.
> 
> Er, I feel stupid but I don’t understand. How do the retain counts affect 
> this? On the one hand, properties are not the only place where retain counts 
> are manipulated, and on the other hand, don’t retain count changes have to be 
> atomic anyway?

The getter for a strong property needs to return either nil or a pointer that's 
valid.  It can't return a pointer to an object that's been deallocated.  If the 
thread on which the getter has been called is racing a thread which is setting 
the property to a different pointer (and thus releasing a reference), the 
getter has to do the equivalent of retain+autorelease atomically with respect 
to the setter doing a (retain new value)+(replace pointer)+(release old value).

For a weak property, the property has to be registered with the runtime as the 
location for a particular weak object and, when set to a new value, 
unregistered.  The runtime needs to know the location of all weak pointers to 
each object so that when the object is (about to be) deallocated, it can nil 
out those pointers. Basically, the racing threads are calling objc_loadWeak() 
vs. objc_storeWeak().  The former has, again, the semantics of a 
retain+autorelease so that the reference is valid for the caller's context (if 
it's not nil).

Regards,
Ken


___

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

copyWithZone archive/unarchive

[Trygve Inda]

I have a custom class (MyCustomClass) and within another class I need to
have MyCustomClass be a property whereby I make a copy (vs retaining).
MyCustomClass is quite complex and so I was considering using:


-(id)copyWithZone:(NSZone *)zone
{
   MyCustomClass* copy = [NSKeyedUnarchiver
unarchiveObjectWithData:[NSKeyedArchiver archivedDataWithRootObject:self]];

 return (copy);
}

This will of course incur a performance hit for the archiving but in my case
it is not very significant. However, naming conventions expect copy to not
be autoreleased so should the above really be:

 return ([copy retain]);


?




___

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: Subclassing NSControl and inheritance of target, action properties

[Quincey Morris]

On Jan 29, 2015, at 21:16 , Ken Thomases  wrote:
> 
> the getter has to do the equivalent of retain+autorelease atomically

I was thinking that the same would have to be true of local variable accesses, 
too, but I see (if I see) the difference is that references from local 
variables are already retained per-thread, not just per-object.

But now I don’t see how the autorelease got in there. If the getter does the 
retain atomically, then surely it can do the release at its leisure?

The other thing that’s getting in the way is that it seems to me that the 
retain-count *increment* needs to be done atomically, independently of whether 
the retain as a whole is atomic. Otherwise, multi-thread read-only access to a 
variable wouldn’t be safe outside of atomic properties.

___

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: Subclassing NSControl and inheritance of target, action properties

[Ken Thomases]

On Jan 29, 2015, at 11:53 PM, Quincey Morris 
 wrote:

> On Jan 29, 2015, at 21:16 , Ken Thomases  wrote:
>> 
>> the getter has to do the equivalent of retain+autorelease atomically
> 
> I was thinking that the same would have to be true of local variable 
> accesses, too, but I see (if I see) the difference is that references from 
> local variables are already retained per-thread, not just per-object.

The difference is that a getter for an atomic property has an atomicity 
requirement that local variable accesses don't.


> But now I don’t see how the autorelease got in there. If the getter does the 
> retain atomically, then surely it can do the release at its leisure?

Huh?  It has to be an autorelease and not a release because the object needs to 
survive to the caller's scope.

You're right, though, that I was slightly wrong.  The getter has to atomically 
do fetch+retain vs. the other thread doing a store+release.  The getter does an 
additional autorelease to balance its retain, but, as you suggest, that part 
doesn't have to be atomic with respect to the other thread.  The other thread 
has to retain the new pointer but that also doesn't have to be atomic with 
respect to the getter thread.

For example, a broken scenario:

Thread 1: fetch old pointer from memory to register
Thread 2: store new pointer from register to memory
Thread 2: release old pointer; deallocates object
Thread 1: retain old pointer; attempting to resurrect a dead object, possibly 
operating on a new object that's replace it


> The other thing that’s getting in the way is that it seems to me that the 
> retain-count *increment* needs to be done atomically, independently of 
> whether the retain as a whole is atomic. Otherwise, multi-thread read-only 
> access to a variable wouldn’t be safe outside of atomic properties.

Yes, retaining is atomic.  But here you have two threads each doing two 
operations, accessing a shared memory location and a retain or release.  On the 
relevant architectures, the memory accesses are atomic with respect to each 
other.  The retains and releases are atomic with respect to each other.  But a 
sequence of a memory access plus a retain/release is not atomic with respect to 
another such sequence.

Regards,
Ken

___

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: Modifying row rect indent in NSOutlineView

[Andrew White]

On 30/01/2015 16:04, Quincey Morris wrote:

On Jan 29, 2015, at 20:45 , Andrew White mailto:andrew.wh...@audinate.com>> wrote:


I tried subclassing NSOutlineView and catching frameOutlineOfCellAtRow,
adding to theRect.origin.x and subtracting from theRect.size.width.  This
didn't seem to make a difference.  I have verified that the overridden
function is being called and theRect modified, but the rendered output
doesn't vary.


Do you mean ‘frameOfOutlineCellAtRow’? That’s the function for the other
thing you’re asking for — it moves the disclosure triangle.

I’m not sure what "the rounded rect surrounding each row” refers to? I
don’t see any rounded rects in 10.10 except while dragging “onto”. Is that
what you mean?


(Also, is there a way to customise the rendered indent level on a per-row
basis, rather than always indentationPerLevel ? )


‘frameOfOutlineCellAtRow’ :)



OK, I think I've figured out what's happening here.  I can use 
outlineView:rowViewForItem: to draw a box around the row which acts as a 
border into which outlineView:viewForTableColumnItem will be rendered.  Is 
this correct?


The code I've inherited uses this to draw rounded rects on the background 
of each row.  So if I want to modify the width and position of those rects, 
I need to feed information about the item in outlineView:rowViewForItem 
into the row view and update the drawing accordingly?


Thanks

--
Andrew White



___

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: copyWithZone archive/unarchive

[Jens Alfke]

> On Jan 29, 2015, at 9:44 PM, Trygve Inda  wrote:
> 
> However, naming conventions expect copy to not
> be autoreleased so should the above really be:
> 
> return ([copy retain]);

Yes, if you're really still not using ARC ;-)

—Jens
___

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

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

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

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

Re: Modifying row rect indent in NSOutlineView

[Quincey Morris]

On Jan 29, 2015, at 22:24 , Andrew White  wrote:
> 
> The code I've inherited uses this to draw rounded rects on the background of 
> each row.  So if I want to modify the width and position of those rects, I 
> need to feed information about the item in outlineView:rowViewForItem into 
> the row view and update the drawing accordingly?

You won’t be able to set the frame of the the row view — it’ll be changed to 
match the dimensions of the outline view after you return it. So, you’ll need 
to put a subview inside it, and then use auto layout, or springs & struts, or 
custom drawing, to get the rounded rect frame indented how you want.

___

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: Subclassing NSControl and inheritance of target, action properties

[Quincey Morris]

On Jan 29, 2015, at 22:21 , Ken Thomases  wrote:
> 
> Huh?  It has to be an autorelease and not a release because the object needs 
> to survive to the caller's scope.

"Release" meant “eventual relinquishment of ownership”. Since we’re talking 
about ARC, I wasn’t assuming that it would be an actual auto-release. In the 
current implementation, it might be returned retained for eventual release in 
the caller’s scope, I think.

Anyway, thanks for clarifying the main point.



___

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: Subclassing NSControl and inheritance of target, action properties

[Ken Thomases]

On Jan 30, 2015, at 12:49 AM, Quincey Morris 
 wrote:

> On Jan 29, 2015, at 22:21 , Ken Thomases  wrote:
>> 
>> Huh?  It has to be an autorelease and not a release because the object needs 
>> to survive to the caller's scope.
> 
> "Release" meant “eventual relinquishment of ownership”.

Sorry if I was overly literal.

> Since we’re talking about ARC, I wasn’t assuming that it would be an actual 
> auto-release. In the current implementation, it might be returned retained 
> for eventual release in the caller’s scope, I think.

Code compiled with ARC has to be compatible with code that's compiled without 
ARC and vice versa.  A getter compiled with ARC can't assume the caller was 
also compiled with ARC and so it can't return it retained unconditionally.  
There's the funky optimization between objc_autoreleaseReturnValue() and 
objc_retainAutoreleasedReturnValue() which has that effect conditionally if 
both were compiled with ARC as detected at run time, but the general form of 
the generated getter code is to autorelease the value.

> Anyway, thanks for clarifying the main point.

You're welcome.

Cheers,
Ken

___

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