Re: Easier way to make NSView subclasses refresh on a property change?

[Keary Suska]

> On Feb 2, 2016, at 11:05 PM, Graham Cox  wrote:
> 
> Hi all,
> 
> Whenever I make a custom view class, it often has a bunch of properties that 
> affect the content it renders. So, for each setter that does this, I have to 
> override the setter, do whatever it normally does plus call 
> -setNeedsDisplay:YES.
> 
> This gets tedious.
> 
> Is there a good way to automate this for a given set of properties? I 
> considered overriding -didChangeValueForKey: and checking the key against a 
> set of exported property names, and that would work, except all my custom 
> views would then need to subclass this one special kind of view instead of 
> NSView. Can it be done with a standard NSView? (MacOS)
> 
> A similar requirement applies to CALayer too.

I have had an analogous situation, and my solution, however kludgey, was to 
have a single property, say a BOOL “refresh”, observe that property, and then 
use +keyPathForValuesAffectingKey to notify the observer. In your case the 
observer would call setNeedsDisplay: or whatever was needed.

HTH,

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


___

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

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

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

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

Re: Easier way to make NSView subclasses refresh on a property change?

[Lee Ann Rucker]

[self addObserver:self forKeyPaths:[Foo keyPathsThatAffectDisplay] 
...context:SomeUniquePtrValue];

(We have a class addition to NSObject to take an array of keyPaths and lopp 
through addObserver:forKeyPath: etc, because we use multiple key paths 
*everywhere*)

- (void)observeValueForKeyPath: ...
{
  if (context == SomeUniquePtrValue && [ [Foo keyPathsThatAffectDisplay] 
containsObject:keyPath]) 
 [self setNeedsDisplay:YES];
etc
}


> On Feb 2, 2016, at 10:05 PM, Graham Cox  wrote:
> 
> Hi all,
> 
> Whenever I make a custom view class, it often has a bunch of properties that 
> affect the content it renders. So, for each setter that does this, I have to 
> override the setter, do whatever it normally does plus call 
> -setNeedsDisplay:YES.
> 
> This gets tedious.
> 
> Is there a good way to automate this for a given set of properties? I 
> considered overriding -didChangeValueForKey: and checking the key against a 
> set of exported property names, and that would work, except all my custom 
> views would then need to subclass this one special kind of view instead of 
> NSView. Can it be done with a standard NSView? (MacOS)
> 
> A similar requirement applies to CALayer too.
> 
> —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/lrucker%40vmware.com
> 
> This email sent to lruc...@vmware.com


___

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

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

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

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

Re: creating draggable NSView

[Jeff Evans]

OK, cancel that. As so often happens when I finally give up and ask a question, 
the answer hit me the face a few minutes later.
Still hurts, too: trouble was that in an earlier experiment I had overridden 
setFrame: in this derived class and had neglected to remove that - it was not 
configured to do anything yet... now we return to our regular programming.

With deepest apologies, Jeff



On Feb 3, 2016, at 4:28 PM, Jeff Evans wrote:

Colleagues, I have been trying to create a draggable NSView for OSX and am 
stumped by the stubborn refusal of the view frame to change.

Here's the essence: in responding to a mouse drag there is a place where I do 
this;

NSPoint newLocation = event.locationInWindow;
NSRect frame = self.frame;
frame.origin = newLocation;
[self setFrame: frame];
[self setNeedsDisplay: YES];

I can also do [self.superview setNeedsDisplay: YES];

However, nothing moves, and looking at this in the debugger I can see that 
self.frame is not altered  by [self setFrame: frame];
Suppose the original frame is 100,100,200, 200
and the new location is 101,105
The new frame is thus 101,105,200,200
And yet if I then look at self.frame in the debugger by adding to the above
frame = self.frame;


I see it is still what it was before: 100,100,200,200. Apparently the call to 
setFrame had no effect.

I am not using IB. This is all programmatic. Does anyone have a clue as to why 
that frame would not alter after setFrame: with a new value?

Thanks, Jeff



___

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/jevans%40ars-nova.com

This email sent to jev...@ars-nova.com

--
If this email is spam, report it to
https://support.onlymyemail.com/view/report_spam/MTAxOTYyOjE4NDk0ODk5NTM6amV2YW5zQGFycy1ub3ZhLmNvbTpkZWxpdmVyZWQ



___

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-evolution] #available has a huge anti-pattern.

[Charles Srstka]

On Feb 3, 2016, at 3:29 PM, James Campbell  wrote:
> 
> We could only allow objective c methods to be queried by responds to 

But then the check is faulty, because it can find private methods.

> But how do we handle Linux or any of the other platforms are you saying we 
> need to annotate with a million OS version specifies 

If you’re checking to see whether a library contains an API or not, you 
probably only care about the library version rather than the OS itself.

Charles

> Sent from Outlook Mobile 
> 
> 
> 
> On Wed, Feb 3, 2016 at 1:18 PM -0800, "Charles Srstka" 
> > wrote:
> 
>> On Feb 3, 2016, at 3:07 PM, James Campbell via swift-evolution 
>> > wrote:
>> 
>> I think if we did feature detection it should ignore private methods not 
>> accessible by the code querying its accesbility. Additionally we really do 
>> need proper support across platforms.
> 
> How is that going to work, though? Most of the system APIs are in 
> Objective-C, which has no distinction between private and public methods at 
> runtime.
> 
> I think #available is fine as-is, especially since the compiler is able to 
> detect if you’re using an API that’s not appropriate for the OS X version 
> you’re specifying.
> 
> 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

creating draggable NSView

[Jeff Evans]

Colleagues, I have been trying to create a draggable NSView for OSX and am 
stumped by the stubborn refusal of the view frame to change.

Here's the essence: in responding to a mouse drag there is a place where I do 
this;

NSPoint newLocation = event.locationInWindow;
NSRect frame = self.frame;
frame.origin = newLocation;
[self setFrame: frame];
[self setNeedsDisplay: YES];

I can also do [self.superview setNeedsDisplay: YES];

However, nothing moves, and looking at this in the debugger I can see that 
self.frame is not altered  by [self setFrame: frame];
Suppose the original frame is 100,100,200, 200
and the new location is 101,105
The new frame is thus 101,105,200,200
And yet if I then look at self.frame in the debugger by adding to the above
frame = self.frame;


I see it is still what it was before: 100,100,200,200. Apparently the call to 
setFrame had no effect.

I am not using IB. This is all programmatic. Does anyone have a clue as to why 
that frame would not alter after setFrame: with a new value?

Thanks, Jeff



___

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

[NSThread callStackSymbols] weirdness

[Trygve Inda]

I am trying to track down a difficult bug on a customer's machine.

I have inserted [NSThread callStackSymbols] at a critical place in the app
where I want to see how it got there.

When running a debug version, either in the debugger or not, I see:

2/3/16 10:53:51.070 PM MyApp Core[22398]: (
0   MyApp Core -[MyClass dealloc] + 115
1   MyApp Core -[MyClass doSomething:] + 234
2   MyApp Core -[MyClass doStuff:] + 292
3   CoreFoundation __CFNOTIFICATIONCENTER_IS_CALLING_OUT + 12
4   CoreFoundation ___CFXRegistrationPost_block_invoke + 63


When running a release version, even with stripping turned off, I see:

2/3/16 10:57:33.978 PM MyApp Core[23142]: (
0   MyApp CoreMyApp Core + 81817
1   CoreFoundation__CFNOTIFICATIONCENTER_IS_CALLING_OUT + 12
2   CoreFoundation___CFXRegistrationPost_block_invoke + 63


My guess is that it is still being stripped somewhere, but why do I get to
see 3 method calls in my own app in the first example, but only the last
call in the second example?

Thanks,

Trygve



___

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

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

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

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

Re: creating draggable NSView

[Jens Alfke]

> On Feb 3, 2016, at 4:28 PM, Jeff Evans  wrote:
> 
> Does anyone have a clue as to why that frame would not alter after setFrame: 
> with a new value?

Constraints, probably.

—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: UIViews in SpriteKit Apps

[Charles Jenkins]

The difference in visual style is something I’m considering. I’m hoping to use 
the standard system pickers, but adjust the colors to fit my game’s aesthetic. 
I’m still a real iOS noob, so even though I think it can be done, maybe I’m 
wrong.

Thanks for the modal view controller idea: I’ll start researching that right 
away.

-- 

Charles

On February 3, 2016 at 01:31:54, Quincey Morris 
(quinceymor...@rivergatesoftware.com) wrote:

On Feb 2, 2016, at 19:00 , Charles Jenkins  wrote:

I’m thinking of presenting a “menu” SpriteKit SKScene with an SKSpriteNode 
button on it that says “Set Background Music,” and when the user touches that 
node, I then switch to an entirely new screen for picking media.

Can I do that, then transition back to my SKScene after the user selects a 
song? How do I do that?

If I wanted to “switch to an entirely new screen”, I would present a new view 
controller modally so that it covers everything. Depending on the nature of the 
game, you might choose to pause the SKScene while it’s overlaid by the modal 
view. Then dismiss the modal controller to get back to the game. There’s no 
need to transition anything within Sprite Kit, as far as I can see.

However, the controlling criterion is likely to be style and esthetics. For 
some games, it might be perceived as jarring if the visual style of the game is 
suddenly changed to the regular iOS UI style. It might be preferable to 
implement it all within Sprite Kit, to keep the style consistent. That means, 
of course, reinventing the controls you need, which can be a huge pain, but the 
design priorities are different for a game.

___

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: View-based NSTableView and ending editing with "return"

[Jean-Daniel Dupas]

> Le 24 janv. 2016 à 09:51, Arved von Brasch  a écrit :
> 
> Hello list,
> 
> After putting it off for too long, I’m migrating to view-based NSTableViews.  
> I’ve worked through most of the conversion problems I’ve had, and am 
> generally pretty happy.  There is, however, one problem I haven’t been able 
> to solve.
> 
> I have a NSButton in the same window as my table.  The button has “return” as 
> a key-equavlent.  This worked fine with a cell-based NSTableView, but with a 
> view-based table, ending editing in the table with a “return” key press 
> always triggers the NSButton as well.  This is obviously undesirable 
> behaviour, but I can’t work out an obvious place to intercept the “return” 
> key press and discard it.
> 
> My attempts thus far have been messing around with a subclass of the 
> NSTableView. I’m thinking this is probably wrong, and I should be subclassing 
> the NSTextField instead, but my experience with such things is minimal, and 
> my Google-Fu has failed me in finding someone else with a similar problem.  
> So, my question is if anyone can give me a pointer to how to go about this.
> 
> Thanks in advance,
> Arved

You may try too use the TextField delegate methods, especially:

- (BOOL)control:(NSControl 

 *)control textView:(NSTextView 

 *)textView doCommandBySelector:(SEL)command

You can detect that this is a return if the selector match 
@selector(insertNewline:), and in such case, return true to inhibit the event.

Return false in all other cases.


___

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: Easier way to make NSView subclasses refresh on a property change?

[Alex Zavatone]

Set a key value observer for each that would call the refresh method.

If there's a way to cluster them all into a collective set of things that would 
change (I think there may) I'm interested in hearing about it too.

Would it be possible (or wise) to add them to an array or set and put the 
observer on that object?


On Feb 3, 2016, at 10:31 AM, Keary Suska wrote:

> 
>> On Feb 2, 2016, at 11:05 PM, Graham Cox  wrote:
>> 
>> Hi all,
>> 
>> Whenever I make a custom view class, it often has a bunch of properties that 
>> affect the content it renders. So, for each setter that does this, I have to 
>> override the setter, do whatever it normally does plus call 
>> -setNeedsDisplay:YES.
>> 
>> This gets tedious.
>> 
>> Is there a good way to automate this for a given set of properties? I 
>> considered overriding -didChangeValueForKey: and checking the key against a 
>> set of exported property names, and that would work, except all my custom 
>> views would then need to subclass this one special kind of view instead of 
>> NSView. Can it be done with a standard NSView? (MacOS)
>> 
>> A similar requirement applies to CALayer too.
> 
> I have had an analogous situation, and my solution, however kludgey, was to 
> have a single property, say a BOOL “refresh”, observe that property, and then 
> use +keyPathForValuesAffectingKey to notify the observer. In your case the 
> observer would call setNeedsDisplay: or whatever was needed.
> 
> HTH,
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com


___

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

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

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

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