Re: All buttons lost focus ring on Yosemite

[Corbin Dunn]

> On Feb 12, 2015, at 6:40 AM, Dragan Milić  wrote:
> 
> I’m dealing with a rather strange issue. When running my application on 
> Yosemite, all buttons lose focus ring (when having focus). When I say all, I 
> mean absolutely ALL buttons, even those in standard alert panels and sheets. 
> I can move focus between buttons using keyboard without any problem (provided 
> that pressing tab is set to move focus between “All controls” in the Keyboard 
> System Preferences), it’s just that a button currently having focus doesn’t 
> draw its focus ring. Focus rings of text fields and lists are drawn as 
> expected.
> 
> When running exactly the same application bundle under Mavericks (and 
> earlier), everything seems fine, button focusses are shown as expected. I’d 
> really appreciate any help in solving this mysterious problem. Thanks in 
> advance.

Sounds like you have added a bad category on NSButton, NSButtonCell, NSControl 
or NSView that overrides some default behavior.

corbin

> 
> — Dragan
> ___
> 
> 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/corbind%40apple.com
> 
> This email sent to corb...@apple.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: NSWindowControllers and NSWindow

[Graham Cox]

> On 17 Feb 2015, at 1:17 am, Dave  wrote:
> 
> My initial thought were to have a WindowController:
> 
> LTWMainWindowController that looks after a number of Windows. Initial there 
> is just one window LTWWindowX (but I want to add others in the future, 
> LTWWindowY, LTWWindowZ, etc.), each window looks after a different aspect of 
> the application.
> 
> I was planning on having a separate Class for LTWMainWindowController and 
> LTWWindowX, LTWWindowY and LTWWindowZ.
> 
> Does this sounds like a reasonable approach?
> 


This sounds very, very similar to the standard document architecture, except 
instead of a "master" window controller, you have a NSDocument subclass. That 
manages the data model, and keeps a list of any number of window controllers, 
each of which manages the particular window kind dsiplaying one aspect of the 
data model. Though normally NSDocument only has a single window controller, it 
is designed to have any number, for exactly the sort of scenario you have 
outlined.

Of course NSDocument has become something of a complicated class in recent 
years, and it may be that it's just too much for your needs, but it's still 
well worth looking at, simply because it fits your outline and for all its 
complexity, works, has been debugged already.

--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: NSWindowControllers and NSWindow

[Roland King]

> On 17 Feb 2015, at 5:59 am, Quincey Morris 
>  wrote:
> 
>> On Feb 16, 2015, at 12:30 , Ken Thomases  wrote:
>> 
>> A view controller and its view should be reusable in different contexts, or 
>> at least designed as though it might be.
> 
> To round out the larger discussion for posterity, I’d add that when using an 
> OS X storyboard, the picture is a little bit different.
> ...
> The other thing that’s different: An OS X storyboard that contains a window 
> will actually contain a window controller too, and at least a content view 
> controller. When using XIBs, putting controllers in the XIB — though doable — 
> is typically a code smell. In storyboards, it’s a necessity.
> 
> To be clear, I’m not suggesting that OS X storyboards are compelling yet, but 
> I think they will be eventually. We need to start factoring them into our 
> thinking.

And storyboards did away with the concept of Files Owner as well. Now the view- 
or window-controller is in the XIB that's what you usually connect to. This was 
probably the most common practice anyway so it makes some sense. 

Coming from iOS (jeers from the gallery) I quite like storyboards on OSX too 
and they support all the embedding and other segues which make hooking up the 
scenes of an app quite intuitive. For odd views, especially those which really 
want a non-controller files owner, I still make a NIB and I don't expect that 
to be going away any time soon. 
___

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: NSWindowControllers and NSWindow

[Quincey Morris]

On Feb 16, 2015, at 12:30 , Ken Thomases  wrote:
> 
> A view controller and its view should be reusable in different contexts, or 
> at least designed as though it might be.

To round out the larger discussion for posterity, I’d add that when using an OS 
X storyboard, the picture is a little bit different.

In a storyboard, it’s probably not going to usual to split windows and views 
out into separate files, since the point of the storyboard is the integration 
of various large-scale UI elements (windows, views, controllers), and an 
important part of that integration is segues, which work within a storyboard.

(I say “probably” because I don’t think OS X storyboards are common enough yet 
for best practices to be well agreed on. Possibly, the most-agreed-on practice 
for OS X storyboards so far might be “don’t use them”, since developers who are 
used to old-school code workflows won’t see any particular advantage.)

The other thing that’s different: An OS X storyboard that contains a window 
will actually contain a window controller too, and at least a content view 
controller. When using XIBs, putting controllers in the XIB — though doable — 
is typically a code smell. In storyboards, it’s a necessity.

To be clear, I’m not suggesting that OS X storyboards are compelling yet, but I 
think they will be eventually. We need to start factoring them into our 
thinking.



___

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: NSWindowControllers and NSWindow

[Raglan T. Tiger]

> On Feb 16, 2015, at 2:38 PM, Jens Alfke  wrote:
> 
> I’m surprised by how complicated the discussion is making this seem! 

Me too !

-rags
___

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: BOOL attribute types.

[Jens Alfke]

> On Feb 16, 2015, at 1:27 PM, Akis Kesoglou  wrote:
> 
> objc.h typedefs BOOL as char/bool, as David says, so I don’t think you can 
> infer that a property is BOOL by introspecting the property — you’ll always 
> see char or bool.

I’ll chime in too — there’s no way to tell the difference. If you need to 
detect boolean properties and treat them differently from ‘char’, you’ll have 
to enforce that your classes only use ‘bool’ properties, not ‘BOOL’.

And a bit of advice if you go this route: If you start using ‘bool’ in your 
code, make sure you enable the “Implicit ‘bool’ Conversions” warning in Xcode. 
Otherwise the default semantics of ‘bool’ in C99 allow for some really nasty 
bugs, like
bool x;
…
x = [NSMutableArray array]; // compiles with no warning! :-o
C99 lets you assign a value of almost any type (except for a struct/union) to a 
bool variable. The warning was added later because this turns out to have bad 
side effects. A few years ago I had a serious and very hard to identify bug in 
my code that stemmed from this sort of mistake. After a few hours I stared at 
the assignment statement, then looked up the declaration of the variable, and 
did a double-take when I realized it was a bool and not an object reference…

—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: NSWindowControllers and NSWindow

[Jens Alfke]

> On Feb 16, 2015, at 9:55 AM, Dave  wrote:
> 
> I can see I could do it if I had LTWViewController.xib that included an 
> NSWindow?


I’m surprised by how complicated the discussion is making this seem! 

All you need to do is create an NSWindowController subclass in Xcode, check the 
“Also create XIB” box, and it’ll make you a .xib that has everything set up 
correctly. Next just start adding views to the .xib, and outlets/actions to the 
class, then wire them up.

—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: BOOL attribute types.

[Akis Kesoglou]

class-dump [1] properly dumps properties as BOOLs where appropriate. Just had a 
quick look over the code but didn’t find anything particular to help you out, 
but you might want to take a look yourself.

[1] https://github.com/nygard/class-dump



> On 16 Φεβ 2015, at 23:27, Akis Kesoglou  wrote:
> 
> 
>> Yeah.  Thanks.
>> 
>> What I'm asking is how can I identify the property as a BOOL when analyzing 
>> property structures so that I can output "BOOL" to a descriptive string and 
>> if I analyze a char, I can output "char" as a descriptive string.
>> 
>> Obviously, I can't use property_getAttributes() since it returns the same 
>> values for BOOL and char.  
>> 
>> What options are available here to detect that a property declared as a BOOL 
>> is a BOOL?
>> 
> 
> objc.h typedefs BOOL as char/bool, as David says, so I don’t think you can 
> infer that a property is BOOL by introspecting the property — you’ll always 
> see char or bool.
> 
> 
> 
>> Thanks.
>> 
>> Sent from my iPad. Please pardon typos.
>> 
>> On Feb 16, 2015, at 4:13 PM, David Duncan  wrote:
>> 
>>> 
 On Feb 16, 2015, at 1:06 PM, Alex Zavatone  wrote:
 
 Xcode 5.1.1
 IOS 7.x
 
 I'm messing with an auto description category for NSObjects with the 
 interest of dumping out a class's properties in the format of property 
 name, property class and string equivalent of property value.
 
 I'm also considering supporting scalar primitive types that are not 
 NSObjects, such as CGRects, BOOLs and so on. 
 
 In doing this, I'm checking the property's attributes with 
 property_getAttributes().
 
 What is confusing here is that for properties that are declared as a non 
 atomic BOOL, the attributes are Tc,N,V, where c codes for a char, 
 according to the docs, according to the Runtime Property Attribute 
 Description Examples.
 
 A char declared as a property returns exactly the same attributes as a 
 BOOL with property_getAttributes().
 
 But for an NSString, property_getAttributes()returns "T@"NSString",&,N
 
 It's easy to detect the NSString properties, but why isn't BOOL included 
 in a BOOL's property attributes?  Is a BOOL just a char (that's what this 
 is telling me)? What is going on under the hood here.  How can I properly 
 identify a BOOL and tell the difference between a BOOL and a char if they 
 are represented the same way?
>>> 
>>> On Mac OS X and 32-bit iOS targets, BOOL is a char, on 64-bit iOS targets 
>>> its a C/C++ style ‘bool’.
>>> 
 Thanks much,
 Alex Zavatone.
 
 Sent from my iPad. Please pardon typos.
 ___
 
 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/david.duncan%40apple.com
 
 This email sent to david.dun...@apple.com
>>> 
>>> --
>>> David Duncan
>>> 
>> 
>> ___
>> 
>> 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/akiskesoglou%40gmail.com
>> 
>> This email sent to akiskesog...@gmail.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: BOOL attribute types.

[Akis Kesoglou]

> Yeah.  Thanks.
> 
> What I'm asking is how can I identify the property as a BOOL when analyzing 
> property structures so that I can output "BOOL" to a descriptive string and 
> if I analyze a char, I can output "char" as a descriptive string.
> 
> Obviously, I can't use property_getAttributes() since it returns the same 
> values for BOOL and char.  
> 
> What options are available here to detect that a property declared as a BOOL 
> is a BOOL?
> 

objc.h typedefs BOOL as char/bool, as David says, so I don’t think you can 
infer that a property is BOOL by introspecting the property — you’ll always see 
char or bool.



> Thanks.
> 
> Sent from my iPad. Please pardon typos.
> 
> On Feb 16, 2015, at 4:13 PM, David Duncan  wrote:
> 
>> 
>>> On Feb 16, 2015, at 1:06 PM, Alex Zavatone  wrote:
>>> 
>>> Xcode 5.1.1
>>> IOS 7.x
>>> 
>>> I'm messing with an auto description category for NSObjects with the 
>>> interest of dumping out a class's properties in the format of property 
>>> name, property class and string equivalent of property value.
>>> 
>>> I'm also considering supporting scalar primitive types that are not 
>>> NSObjects, such as CGRects, BOOLs and so on. 
>>> 
>>> In doing this, I'm checking the property's attributes with 
>>> property_getAttributes().
>>> 
>>> What is confusing here is that for properties that are declared as a non 
>>> atomic BOOL, the attributes are Tc,N,V, where c codes for a char, according 
>>> to the docs, according to the Runtime Property Attribute Description 
>>> Examples.
>>> 
>>> A char declared as a property returns exactly the same attributes as a BOOL 
>>> with property_getAttributes().
>>> 
>>> But for an NSString, property_getAttributes()returns "T@"NSString",&,N
>>> 
>>> It's easy to detect the NSString properties, but why isn't BOOL included in 
>>> a BOOL's property attributes?  Is a BOOL just a char (that's what this is 
>>> telling me)? What is going on under the hood here.  How can I properly 
>>> identify a BOOL and tell the difference between a BOOL and a char if they 
>>> are represented the same way?
>> 
>> On Mac OS X and 32-bit iOS targets, BOOL is a char, on 64-bit iOS targets 
>> its a C/C++ style ‘bool’.
>> 
>>> Thanks much,
>>> Alex Zavatone.
>>> 
>>> Sent from my iPad. Please pardon typos.
>>> ___
>>> 
>>> 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/david.duncan%40apple.com
>>> 
>>> This email sent to david.dun...@apple.com
>> 
>> --
>> David Duncan
>> 
> 
> ___
> 
> 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/akiskesoglou%40gmail.com
> 
> This email sent to akiskesog...@gmail.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: BOOL attribute types.

[Greg Parker]

> On Feb 16, 2015, at 1:06 PM, Alex Zavatone  wrote:
> 
> Xcode 5.1.1
> IOS 7.x
> 
> I'm messing with an auto description category for NSObjects with the interest 
> of dumping out a class's properties in the format of property name, property 
> class and string equivalent of property value.
> 
> I'm also considering supporting scalar primitive types that are not 
> NSObjects, such as CGRects, BOOLs and so on. 
> 
> In doing this, I'm checking the property's attributes with 
> property_getAttributes().
> 
> What is confusing here is that for properties that are declared as a non 
> atomic BOOL, the attributes are Tc,N,V, where c codes for a char, according 
> to the docs, according to the Runtime Property Attribute Description Examples.
> 
> A char declared as a property returns exactly the same attributes as a BOOL 
> with property_getAttributes().
> 
> But for an NSString, property_getAttributes()returns "T@"NSString",&,N
> 
> It's easy to detect the NSString properties, but why isn't BOOL included in a 
> BOOL's property attributes?  Is a BOOL just a char (that's what this is 
> telling me)? What is going on under the hood here.  How can I properly 
> identify a BOOL and tell the difference between a BOOL and a char if they are 
> represented the same way?

You can't.

64-bit iOS:
typedef bool BOOL;

Everything else:
typedef signed char BOOL;

If you have sufficient control over the property names, you might be able to 
assume that a property typed "c" named "foo" with a getter named "isFoo" is a 
BOOL property.


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

Re: BOOL attribute types.

[Alex Zavatone]

Yeah.  Thanks.

What I'm asking is how can I identify the property as a BOOL when analyzing 
property structures so that I can output "BOOL" to a descriptive string and if 
I analyze a char, I can output "char" as a descriptive string.

Obviously, I can't use property_getAttributes() since it returns the same 
values for BOOL and char.  

What options are available here to detect that a property declared as a BOOL is 
a BOOL?

Thanks.

Sent from my iPad. Please pardon typos.

On Feb 16, 2015, at 4:13 PM, David Duncan  wrote:

> 
>> On Feb 16, 2015, at 1:06 PM, Alex Zavatone  wrote:
>> 
>> Xcode 5.1.1
>> IOS 7.x
>> 
>> I'm messing with an auto description category for NSObjects with the 
>> interest of dumping out a class's properties in the format of property name, 
>> property class and string equivalent of property value.
>> 
>> I'm also considering supporting scalar primitive types that are not 
>> NSObjects, such as CGRects, BOOLs and so on. 
>> 
>> In doing this, I'm checking the property's attributes with 
>> property_getAttributes().
>> 
>> What is confusing here is that for properties that are declared as a non 
>> atomic BOOL, the attributes are Tc,N,V, where c codes for a char, according 
>> to the docs, according to the Runtime Property Attribute Description 
>> Examples.
>> 
>> A char declared as a property returns exactly the same attributes as a BOOL 
>> with property_getAttributes().
>> 
>> But for an NSString, property_getAttributes()returns "T@"NSString",&,N
>> 
>> It's easy to detect the NSString properties, but why isn't BOOL included in 
>> a BOOL's property attributes?  Is a BOOL just a char (that's what this is 
>> telling me)? What is going on under the hood here.  How can I properly 
>> identify a BOOL and tell the difference between a BOOL and a char if they 
>> are represented the same way?
> 
> On Mac OS X and 32-bit iOS targets, BOOL is a char, on 64-bit iOS targets its 
> a C/C++ style ‘bool’.
> 
>> Thanks much,
>> Alex Zavatone.
>> 
>> Sent from my iPad. Please pardon typos.
>> ___
>> 
>> 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/david.duncan%40apple.com
>> 
>> This email sent to david.dun...@apple.com
> 
> --
> David Duncan
> 

___

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: BOOL attribute types.

[David Duncan]

> On Feb 16, 2015, at 1:06 PM, Alex Zavatone  wrote:
> 
> Xcode 5.1.1
> IOS 7.x
> 
> I'm messing with an auto description category for NSObjects with the interest 
> of dumping out a class's properties in the format of property name, property 
> class and string equivalent of property value.
> 
> I'm also considering supporting scalar primitive types that are not 
> NSObjects, such as CGRects, BOOLs and so on. 
> 
> In doing this, I'm checking the property's attributes with 
> property_getAttributes().
> 
> What is confusing here is that for properties that are declared as a non 
> atomic BOOL, the attributes are Tc,N,V, where c codes for a char, according 
> to the docs, according to the Runtime Property Attribute Description Examples.
> 
> A char declared as a property returns exactly the same attributes as a BOOL 
> with property_getAttributes().
> 
> But for an NSString, property_getAttributes()returns "T@"NSString",&,N
> 
> It's easy to detect the NSString properties, but why isn't BOOL included in a 
> BOOL's property attributes?  Is a BOOL just a char (that's what this is 
> telling me)? What is going on under the hood here.  How can I properly 
> identify a BOOL and tell the difference between a BOOL and a char if they are 
> represented the same way?

On Mac OS X and 32-bit iOS targets, BOOL is a char, on 64-bit iOS targets its a 
C/C++ style ‘bool’.

> Thanks much,
> Alex Zavatone.
> 
> Sent from my iPad. Please pardon typos.
> ___
> 
> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

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

BOOL attribute types.

[Alex Zavatone]

Xcode 5.1.1
IOS 7.x

I'm messing with an auto description category for NSObjects with the interest 
of dumping out a class's properties in the format of property name, property 
class and string equivalent of property value.

I'm also considering supporting scalar primitive types that are not NSObjects, 
such as CGRects, BOOLs and so on. 

In doing this, I'm checking the property's attributes with 
property_getAttributes().

What is confusing here is that for properties that are declared as a non atomic 
BOOL, the attributes are Tc,N,V, where c codes for a char, according to the 
docs, according to the Runtime Property Attribute Description Examples.

A char declared as a property returns exactly the same attributes as a BOOL 
with property_getAttributes().

But for an NSString, property_getAttributes()returns "T@"NSString",&,N

It's easy to detect the NSString properties, but why isn't BOOL included in a 
BOOL's property attributes?  Is a BOOL just a char (that's what this is telling 
me)? What is going on under the hood here.  How can I properly identify a BOOL 
and tell the difference between a BOOL and a char if they are represented the 
same way?

Thanks much,
Alex Zavatone.

Sent from my iPad. Please pardon typos.
___

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: NSWindowControllers and NSWindow

[Bill Cheeseman]

Excellent suggestions, as usual. Thanks, Ken!

> On Feb 16, 2015, at 3:30 PM, Ken Thomases  wrote:
> 
> He clearly says that the MainMenu NIB should _not_ include a window:


I thought I remembered that, but when I went back for a quick check I missed 
the passage you quoted. That must be where I got the idea in the first place, 
although 15 years of writing Objective-C code has convinced me that just about 
every project should be comparmentalized as much as it reasonably can be.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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: NSWindowControllers and NSWindow

[Ken Thomases]

On Feb 16, 2015, at 12:39 PM, Bill Cheeseman  wrote:

> Although I follow Mike Ash's advice, I have separate MainMenu.xib and 
> MainWindow.xib files instead of a single window.xib file. My MainMenu.xib 
> contains the application's menu bar but no window.

The construction of this sentence suggests that this arrangement is contrary to 
Mike's advice.  Rather, it is in concordance with Mike's advice.  He clearly 
says that the MainMenu NIB should _not_ include a window:

"MainMenu.xib is a special case: it should contain File's Owner, which is the 
NSApplication instance, the menu bar, the application delegate, any other 
objects related to these, but _no NSWindow_ instances."  (Emphasis in the 
original.)


> In AppDelegate's applicationDidFinishLaunching delegate method, I set the 
> AppDelegate's mainWindowController and window instance variables to the new 
> window controller and to its new window, so that the AppDelegate can refer to 
> them as needed.

I recommend that you declare a read-only property (possibly private) for the 
mainWindowController.  Implement the getter yourself to create the controller 
if it hasn't already been created and return it.  Use that property (i.e. 
self.mainWindowController) to access the controller and use the window property 
of the controller (i.e. self.mainWindowController.window) to access the window. 
 This eliminates redundancy, which is an opportunity for things to get out of 
sync, and makes sure that the controller and its window always exist where they 
are needed.  For example, if an application delegate method is called before 
-applicationDidFinishLaunching: and tries to manipulate the controller or its 
window, it will work rather than failing silently.


> In order to further compartmentalize my code, each of the more complex views 
> in the window, such as the tab view items, has its own view controller and 
> .xib file. Each view controller is instantiated, the view in the .xib file it 
> owns is loaded, and the view is positioned in the window, all by suitable 
> methods called in the main window controller, typically in the case of tab 
> view items in response to the user clicking a tab or button or choosing a 
> menu item. The main window controller saves instance variables referring to 
> each view when the view is instantiated so that it can communicate with them. 
> In addition, each view gets a reference back to the window controller when 
> the window controller sets the associated property of the view right after 
> instantiating it (or in a custom init method).

Again, I recommend that you create these view controllers on demand in the 
getters of read-only properties.  And don't keep separate track of the views, 
just use the view property of the controllers.

If your view controllers need a reference back to the window controller, that 
suggests that they haven't been properly encapsulated.  They are too closely 
coupled.  Or, at least, that's the case if the view controller knows the class 
of the window controller.  It's reasonable if the view controller declares a 
general delegate protocol and the window controller adopts that protocol and is 
acting as the delegate for the view controller.

A view controller and its view should be reusable in different contexts, or at 
least designed as though it might be.

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: NSWindowControllers and NSWindow

[Dave]

> On 16 Feb 2015, at 18:39, Bill Cheeseman  wrote:

> 
> Although I follow Mike Ash's advice, I have separate MainMenu.xib and 
> MainWindow.xib files instead of a single window.xib file. My MainMenu.xib 
> contains the application's menu bar but no window. MainMenu.xib is owned by 
> NSApplication, and NSApplication's delegate outlet is connected to my 
> AppDelegate object, which is included in MainMenu.xib. MainMenu.xib is 
> loaded, its included AppDelegate object is instantiated, and its 
> applicationDidFinishLaunching delegate method is called, all automatically at 
> launch due to the way the standard Main file works. My AppDelegate class 
> implements NSApplicationDelegate protocol methods as needed, and it handles a 
> few other things that are of application-wide relevance. It tends to be 
> fairly small and simple.

Same as I have.

> Because MainMenu.xib contains no window, the application has a menu bar but 
> nothing else up to the point where AppDelegate's 
> applicationDidFinishLaunching delegate method is called. The window is 
> contained in MainWindow.xib, which is owned by my MainWindowController class. 
> The applicationDidFinishLaunching delegate method in AppDelegate loads 
> MainWindow.xib by calling initWithWindowNibName (I don't buy Mike's advice to 
> declare a simple init method), and at this point the application has both a 
> menu bar and a window. The window's Visible At Launch behavior is set in 
> MainWindow.xib, so the window appears when the application is launched and 
> MainWindow.xib is loaded, without having to call showWindow (or you can just 
> call showWindow). In AppDelegate's applicationDidFinishLaunching delegate 
> method, I set the AppDelegate's mainWindowController and window instance 
> variables to the new window controller and to its new window, so that the 
> AppDelegate can refer to them as needed.

This is slightly different that I have an Outlet defined in the MainMenu.xib 
file which is set to LTWMainWindowController and I do use a simple init method 
inside of  LTWMainWindowController that calls initWithWindowNibName with 
@“LTWMainWindow”.

> 
> The MainWindowController implements the outlets and action methods and any 
> delegate methods for the window and all or most of its buttons and other UI 
> elements. It can refer to the menu bar and other things in the AppDelegate as 
> needed by calling NSApp.delegate. In turn, AppDelegate can refer to the 
> window, its UI elements, and the window controller as needed by using 
> AppDelegte's instance variables for them.
> 

Thanks again, I think I’ve got it now!

Cheers
Dave



___

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: NSWindowControllers and NSWindow

[Dave]

> Well, you've switched from talking about a window controller to a view 
> controller for some reason.  

Sorry, was a typo I meant LTWWindowController, I’m so used to typing 
ViewController that I guess my fingering did the thinking in this case!

Fixed the warnings too, thanks again for your help everyone.

Dave


> On 16 Feb 2015, at 19:28, Ken Thomases  wrote:
> 
> On Feb 16, 2015, at 11:55 AM, Dave  wrote:
> 
>>> You never want a NIB for the window controller that's separate from the NIB 
>>> containing the window.  You want a single NIB for the window which the 
>>> window controller will load and be the owner of.  The NIB will *not* 
>>> "contain" the window controller.  The File's Owner placeholder in the NIB 
>>> represents the window controller, but the window controller will be created 
>>> before the NIB is loaded and will, in fact, be the thing which loads the 
>>> NIB.
>> 
>> This is what I don’t get! If I have:
>> 
>> LTWViewController.h and LTWViewController.m, and LTWWindow.xib, then set the 
>> file owner in the NIB to “LTWViewController”, how do I then wire up outlets, 
>> bindings and actions so that I get properties set in LTWViewController?
> 
> Well, you've switched from talking about a window controller to a view 
> controller for some reason.  That aside, when you set the class of File's 
> Owner that lets IB know what outlets and action methods the File's Owner 
> supports.  So, if you have set the class of File's Owner to LTWViewController 
> (to follow your example), then the File's Owner placeholder now has whatever 
> outlets you have defined on the LTWViewController class.  You connect the 
> outlets from the File's Owner placeholder to whatever object they are 
> supposed to reference.
> 
> When a window controller loads a NIB, it typically provides itself as the 
> owner of the NIB.  That means that the NIB loading machinery will use that 
> window controller as the real object that the File's Owner placeholder was 
> holding the place for.  So, any outlet connections established in the NIB 
> from the File's Owner placeholder will actually set the properties of the 
> window controller (assuming they exist).  Any controls whose actions were 
> connected to the File's Owner placeholder as the target will actually have 
> their target set to the window controller.  Etc.
> 
> Likewise for a view controller, but the NIB should only contain a view in 
> that case, not a window.
> 
> 
>> I can see I could do it if I had LTWViewController.xib that included an 
>> NSWindow?
> 
> Huh?  Why does the name of the NIB file make a difference?
> 
> 
>> Thanks a lot.
> 
> You're welcome.
> 
> 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: Idea for Improving Vibrancy

[Carl Hoefs]

On Feb 16, 2015, at 5:34 AM, Roland King  wrote:

> And for anyone, like me, who doesn't like the vibrancy effect, you can turn 
> it off in preferences.

Is this the right setting:  “◽ Disable Windows® look and feel”
-Carl


___

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: NSWindowControllers and NSWindow

[Ken Thomases]

On Feb 16, 2015, at 11:55 AM, Dave  wrote:

>> You never want a NIB for the window controller that's separate from the NIB 
>> containing the window.  You want a single NIB for the window which the 
>> window controller will load and be the owner of.  The NIB will *not* 
>> "contain" the window controller.  The File's Owner placeholder in the NIB 
>> represents the window controller, but the window controller will be created 
>> before the NIB is loaded and will, in fact, be the thing which loads the NIB.
> 
> This is what I don’t get! If I have:
> 
> LTWViewController.h and LTWViewController.m, and LTWWindow.xib, then set the 
> file owner in the NIB to “LTWViewController”, how do I then wire up outlets, 
> bindings and actions so that I get properties set in LTWViewController?

Well, you've switched from talking about a window controller to a view 
controller for some reason.  That aside, when you set the class of File's Owner 
that lets IB know what outlets and action methods the File's Owner supports.  
So, if you have set the class of File's Owner to LTWViewController (to follow 
your example), then the File's Owner placeholder now has whatever outlets you 
have defined on the LTWViewController class.  You connect the outlets from the 
File's Owner placeholder to whatever object they are supposed to reference.

When a window controller loads a NIB, it typically provides itself as the owner 
of the NIB.  That means that the NIB loading machinery will use that window 
controller as the real object that the File's Owner placeholder was holding the 
place for.  So, any outlet connections established in the NIB from the File's 
Owner placeholder will actually set the properties of the window controller 
(assuming they exist).  Any controls whose actions were connected to the File's 
Owner placeholder as the target will actually have their target set to the 
window controller.  Etc.

Likewise for a view controller, but the NIB should only contain a view in that 
case, not a window.


> I can see I could do it if I had LTWViewController.xib that included an 
> NSWindow?

Huh?  Why does the name of the NIB file make a difference?


> Thanks a lot.

You're welcome.

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: NSWindowControllers and NSWindow

[Steve Mills]

On Feb 16, 2015, at 13:20:24, Dave  wrote:
> 
> Thanks, I solved it, the File’s Owner didn’t take for some reason, I did it 
> again and it seems to work ok now.
> 
> However, I’m guessing that something isn’t right, since I now get two 
> warnings - 
> 
> /path/LTWMainWindow.xib:  The initial position of this window is outside of 
> this machine's screen.

Check the Initial Position in the window's Size inspector. It will also 
probably never end up where you want it on various screens, because of their 
stupid decision to go with a bottom-up coordinate system instead of the logical 
old top-down system.

> /path/LTWMainWindow.xib:  Frame for "Clip View" will be different at run time.
> 
> Not sure what it’s trying to tell me, but I’m guessing that something isn’t 
> wired correctly, although it seems to work fine.

I get that too for every scroll view. It's a bug that I wish they'd fix.

--
Steve Mills
Drummer, Mac geek


___

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: Idea for Improving Vibrancy

[Seth Willits]

Ugh. Mail used the wrong address again and bounced this...


--
Seth Willits



> On Feb 15, 2015, at 9:54 PM, Seth Willits  wrote:
> 
> On Feb 15, 2015, at 6:13 AM, Charles Jenkins  wrote:
> 
>> Is this possible, do you think, to open a window that always hides directly 
>> behind the working window?   
> 
> Easily. Add a borderless child window ordered using NSWindowBelow.
> 
> However, properly replicating the contents of the desktop within that window 
> (especially given the desktop image can change — with animation —— and 
> there's "no way" you can know when etc) makes it impractical. Then there's 
> the performance and resource considerations. It is technically possible 
> though.
> 
> Beyond the technical side, there's the obligatory "you shouldn't do this" 
> because of HIG and consistency statement to be made. 
> 
> 
> (Hopefully this won't spiral into another ridiculous "eww it's so uuugly" 
> thread...)
> 
> 
> --
> Seth Willits
> 
> 
> 


___

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: NSWindowControllers and NSWindow

[Dave]

Thanks, I solved it, the File’s Owner didn’t take for some reason, I did it 
again and it seems to work ok now.

However, I’m guessing that something isn’t right, since I now get two warnings 
- 

/path/LTWMainWindow.xib:  The initial position of this window is outside of 
this machine's screen.

and

/path/LTWMainWindow.xib:  Frame for "Clip View" will be different at run time.

Not sure what it’s trying to tell me, but I’m guessing that something isn’t 
wired correctly, although it seems to work fine.

Thanks a lot
Dave

> On 16 Feb 2015, at 18:32, Bill Cheeseman  wrote:
> 
> 
>> On Feb 16, 2015, at 12:55 PM, Dave  wrote:
>> 
>> LTWViewController.h and LTWViewController.m, and LTWWindow.xib, then set the 
>> file owner in the NIB to “LTWViewController”, how do I then wire up outlets, 
>> bindings and actions so that I get properties set in LTWViewController?
> 
> 
> Connect the UI element (button, etc.) to its IBOutlet in File's Owner (which 
> should be a window controller, not a view controller), and connect the 
> IBAction in File's Owner to its UI element. Do all of this in your window.xib 
> using any of several techniques outlined in the Xcode/Interface Builder 
> documentation. For example, right-click File's Owner in the left column of 
> the Interface Builder editing pane to open a HUD listing all of its 
> IBOutlets, and drag FROM the little dot to the right of one of the listed 
> IBOutlets TO the UI element's graphical representation in the window. To 
> connect an action, drag FROM the UI element TO File's Owner.
> 
> -- 
> 
> Bill Cheeseman - b...@cheeseman.name
> 
> ___
> 
> 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/dave%40looktowindward.com
> 
> This email sent to d...@looktowindward.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: NSWindowControllers and NSWindow

[Bill Cheeseman]

> On Feb 16, 2015, at 10:24 AM, Dave  wrote:
> 
> Thanks for this, it seems to be saying there is no need for a separate Window 
> Subclass and that the Window Controller Subclass contains all the code needed 
> to drive the window. I’m a bit confused of when to use an NSWindow and when 
> to use and NSWindowController? 
> 
> The way I had thought to do this was to have:
> 
> LTWMainWindowController.h, .m and .xib files and LTWMainWindow.h, .m and .xib 
> files.
> 
> Is this the best approach? Or it is better to put the code in the 
> LTWMainWindow.h, .m and .xib files directly into LTWMainWindowController? 
> 
> Or instead of using NSWindowController  and NSWindow should I be using 
> NSWindowController and NSViewController?
> 
> I’m really confused how to lay this out and want to start off on the right 
> foot.


I am currently in the early stages of rewriting one of my applications 
following the advice in the same Mike Ash Q&A article. I'll summarize my 
approach here for whatever help it may give you, and also in the hope of 
obtaining reactions from Ken and others. My application is a single-window 
utility application with some complexity in its user interface (a split view 
containing a number of UI elements, including two tab views with multiple tab 
view items, one of which has a nested tabless tab view with multiple tab view 
items).

Although I follow Mike Ash's advice, I have separate MainMenu.xib and 
MainWindow.xib files instead of a single window.xib file. My MainMenu.xib 
contains the application's menu bar but no window. MainMenu.xib is owned by 
NSApplication, and NSApplication's delegate outlet is connected to my 
AppDelegate object, which is included in MainMenu.xib. MainMenu.xib is loaded, 
its included AppDelegate object is instantiated, and its 
applicationDidFinishLaunching delegate method is called, all automatically at 
launch due to the way the standard Main file works. My AppDelegate class 
implements NSApplicationDelegate protocol methods as needed, and it handles a 
few other things that are of application-wide relevance. It tends to be fairly 
small and simple.

Because MainMenu.xib contains no window, the application has a menu bar but 
nothing else up to the point where AppDelegate's applicationDidFinishLaunching 
delegate method is called. The window is contained in MainWindow.xib, which is 
owned by my MainWindowController class. The applicationDidFinishLaunching 
delegate method in AppDelegate loads MainWindow.xib by calling 
initWithWindowNibName (I don't buy Mike's advice to declare a simple init 
method), and at this point the application has both a menu bar and a window. 
The window's Visible At Launch behavior is set in MainWindow.xib, so the window 
appears when the application is launched and MainWindow.xib is loaded, without 
having to call showWindow (or you can just call showWindow). In AppDelegate's 
applicationDidFinishLaunching delegate method, I set the AppDelegate's 
mainWindowController and window instance variables to the new window controller 
and to its new window, so that the AppDelegate can refer to them as needed.

The MainWindowController implements the outlets and action methods and any 
delegate methods for the window and all or most of its buttons and other UI 
elements. It can refer to the menu bar and other things in the AppDelegate as 
needed by calling NSApp.delegate. In turn, AppDelegate can refer to the window, 
its UI elements, and the window controller as needed by using AppDelegte's 
instance variables for them.

In order to further compartmentalize my code, each of the more complex views in 
the window, such as the tab view items, has its own view controller and .xib 
file. Each view controller is instantiated, the view in the .xib file it owns 
is loaded, and the view is positioned in the window, all by suitable methods 
called in the main window controller, typically in the case of tab view items 
in response to the user clicking a tab or button or choosing a menu item. The 
main window controller saves instance variables referring to each view when the 
view is instantiated so that it can communicate with them. In addition, each 
view gets a reference back to the window controller when the window controller 
sets the associated property of the view right after instantiating it (or in a 
custom init method).

In answer to one of your questions, you see from the above that you don't need 
separate window controller .xib and window .xib files. Your window .xib file, 
which contains your window, will be owned by your window controller, which has 
the job of controlling the window it owns. You only need separate window.h and 
.m files if you are subclassing NSWindow, which often is not necessary but is 
easy to do. If you do subclass it, you still use the same window.xib file but 
simply change the window's Class setting from NSWindow to your window 
subclass's name. Your window controller will still control it. In short, there 
is no 

Re: NSWindowControllers and NSWindow

[Bill Cheeseman]

> On Feb 16, 2015, at 12:55 PM, Dave  wrote:
> 
> LTWViewController.h and LTWViewController.m, and LTWWindow.xib, then set the 
> file owner in the NIB to “LTWViewController”, how do I then wire up outlets, 
> bindings and actions so that I get properties set in LTWViewController?


Connect the UI element (button, etc.) to its IBOutlet in File's Owner (which 
should be a window controller, not a view controller), and connect the IBAction 
in File's Owner to its UI element. Do all of this in your window.xib using any 
of several techniques outlined in the Xcode/Interface Builder documentation. 
For example, right-click File's Owner in the left column of the Interface 
Builder editing pane to open a HUD listing all of its IBOutlets, and drag FROM 
the little dot to the right of one of the listed IBOutlets TO the UI element's 
graphical representation in the window. To connect an action, drag FROM the UI 
element TO File's Owner.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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: NSWindowControllers and NSWindow

[Dave]

> You never want a NIB for the window controller that's separate from the NIB 
> containing the window.  You want a single NIB for the window which the window 
> controller will load and be the owner of.  The NIB will *not* "contain" the 
> window controller.  The File's Owner placeholder in the NIB represents the 
> window controller, but the window controller will be created before the NIB 
> is loaded and will, in fact, be the thing which loads the NIB.

This is what I don’t get! If I have:

LTWViewController.h and LTWViewController.m, and LTWWindow.xib, then set the 
file owner in the NIB to “LTWViewController”, how do I then wire up outlets, 
bindings and actions so that I get properties set in LTWViewController?

I can see I could do it if I had LTWViewController.xib that included an 
NSWindow?

Thanks a lot.

Cheers
Dave

> On 16 Feb 2015, at 16:46, Ken Thomases  wrote:
> 
> On Feb 16, 2015, at 9:24 AM, Dave  wrote:
> 
>>> I recommend that you follow the advice in this article: 
>>> .
>> 
>> Thanks for this, it seems to be saying there is no need for a separate 
>> Window Subclass and that the Window Controller Subclass contains all the 
>> code needed to drive the window.
> 
> It's relatively rare to need to subclass NSWindow.  Usually, you can achieve 
> whatever behavior you need with a standard NSWindow or NSPanel and the 
> window's delegate.
> 
> You typically want a custom subclass of NSWindowController to be responsible 
> for the window (and the memory management of the top-level objects in the 
> window NIB).
> 
> It's convenient and common for the window controller to also be the window's 
> delegate.
> 
> 
>> I’m a bit confused of when to use an NSWindow and when to use and 
>> NSWindowController? 
> 
> Well, NSWindow is an actual GUI object.  If you don't have a window, then 
> there's nothing for the user to see or interact with.  NSWindowController is, 
> as its name implies, a controller.  You typically use both.  The window 
> controller creates and controls the window.
> 
> 
>> The way I had thought to do this was to have:
>> 
>> LTWMainWindowController.h, .m and .xib files and LTWMainWindow.h, .m and 
>> .xib files.
> 
> You never want a NIB for the window controller that's separate from the NIB 
> containing the window.  You want a single NIB for the window which the window 
> controller will load and be the owner of.  The NIB will *not* "contain" the 
> window controller.  The File's Owner placeholder in the NIB represents the 
> window controller, but the window controller will be created before the NIB 
> is loaded and will, in fact, be the thing which loads the NIB.
> 
>> Is this the best approach? Or it is better to put the code in the 
>> LTWMainWindow.h, .m and .xib files directly into LTWMainWindowController? 
> 
> It makes no sense to discuss where some unspecified code goes until you know 
> what the code is for.  As I say, usually there's no need to subclass 
> NSWindow.  You would have a custom window controller class and a NIB that 
> encodes the state of the window and at least some of its views.  The NIB 
> might also encode some auxiliary controller objects, like an array controller.
> 
> You would only create a custom subclass of NSWindow if the normal mechanisms 
> (window controller, window delegate) don't meet your needs.  Don't do it 
> preemptively.
> 
> 
>> Or instead of using NSWindowController  and NSWindow should I be using 
>> NSWindowController and NSViewController?
> 
> Well, there will always be a window or otherwise there's nothing for the 
> window controller to control and nothing to contain any views that might be 
> controlled by any view controllers.
> 
> You may find it convenient to organize your project with view controllers for 
> some important views within your window, but that sort of depends on how 
> complex your window and its view hierarchy are, and whether you'll be 
> swapping views in and out or reusing views in multiple contexts.  Again, it 
> doesn't make sense to pick a design architecture in the abstract.  You design 
> the architecture based on the specifics of your app.
> 
> 
>> I’m really confused how to lay this out and want to start off on the right 
>> foot.
> 
> For starters, just follow the advice in that article.  Create a custom 
> subclass of NSWindowController.  Create the NIB to encode the window's 
> configuration and view hierarchy.  Don't go more complicated than that — 
> custom window classes, separate view NIB with view controllers — until you 
> need to.
> 
> 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-archiv

Re: NSWindowControllers and NSWindow

[Jens Alfke]

> On Feb 16, 2015, at 6:17 AM, Dave  wrote:
> 
> My initial thought were to have a WindowController:
> LTWMainWindowController that looks after a number of Windows.

Usually you have a separate NSWindowController subclass for each distinct type 
of window. If the windows share some functionality, put it in a base class and 
subclass it. Otherwise if you try to do everything with one controller class, 
you end up with a lot of “switch(_windowType) {…}” stuff, which is a code smell 
meaning “subclass me!”

As others have pointed out, you almost never subclass NSWindow. The only reason 
to do that is if you want to do something special to the appearance or behavior 
of the window frame itself. For example, Chrome has a custom NSWindow class to 
handle drawing the tabs in the window frame.

One thing no one’s mentioned yet is NSDocument. If your app supports the 
typical behavior of opening a file into a window, you probably want to use 
NSDocument, which provides a framework for opening/saving documents, tracking 
the ‘dirty’ state, working with iCloud storage, etc.

—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: NSWindowControllers and NSWindow

[Steve Mills]

On Feb 16, 2015, at 09:24:36, Dave  wrote:
> 
> Thanks for this, it seems to be saying there is no need for a separate Window 
> Subclass and that the Window Controller Subclass contains all the code needed 
> to drive the window. I’m a bit confused of when to use an NSWindow and when 
> to use and NSWindowController? 
> 
> The way I had thought to do this was to have:
> 
> LTWMainWindowController.h, .m and .xib files and LTWMainWindow.h, .m and .xib 
> files.
> 
> Is this the best approach? Or it is better to put the code in the 
> LTWMainWindow.h, .m and .xib files directly into LTWMainWindowController? 
> 
> Or instead of using NSWindowController  and NSWindow should I be using 
> NSWindowController and NSViewController?
> 
> I’m really confused how to lay this out and want to start off on the right 
> foot.

NSWindow rarely needs to be subclassed. The controller is where all the custom 
action usually happens. Think of the window as the graphical representation of 
the pair, but the controller is what controls how the window works, and it's 
where you would put IBAction methods that the various controls in the window 
will call when they're acted upon. E.g. a button named "Karate Chop" would be 
connected to "-(IBAction) karateChop:(id)sender" in the controller, and that's 
where you would put the code to commence a karate chop.

Now think of your different windows. Assumedly, they all have different 
controls and views, and take care of different aspects of the app, like you 
said. Therefore, good program design would call for a different specialized 
controller subclass for each window. *if* needed. I say "if needed" because, 
depending on the simplicity of a window, it could be done entirely through 
Cocoa Bindings or other methods, but usually not.

Look at some sample apps on Apple's developer site. Like Sketch maybe.

--
Steve Mills
Drummer, Mac geek


___

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: NSWindowControllers and NSWindow

[Ken Thomases]

On Feb 16, 2015, at 9:24 AM, Dave  wrote:

>> I recommend that you follow the advice in this article: 
>> .
> 
> Thanks for this, it seems to be saying there is no need for a separate Window 
> Subclass and that the Window Controller Subclass contains all the code needed 
> to drive the window.

It's relatively rare to need to subclass NSWindow.  Usually, you can achieve 
whatever behavior you need with a standard NSWindow or NSPanel and the window's 
delegate.

You typically want a custom subclass of NSWindowController to be responsible 
for the window (and the memory management of the top-level objects in the 
window NIB).

It's convenient and common for the window controller to also be the window's 
delegate.


> I’m a bit confused of when to use an NSWindow and when to use and 
> NSWindowController? 

Well, NSWindow is an actual GUI object.  If you don't have a window, then 
there's nothing for the user to see or interact with.  NSWindowController is, 
as its name implies, a controller.  You typically use both.  The window 
controller creates and controls the window.


> The way I had thought to do this was to have:
> 
> LTWMainWindowController.h, .m and .xib files and LTWMainWindow.h, .m and .xib 
> files.

You never want a NIB for the window controller that's separate from the NIB 
containing the window.  You want a single NIB for the window which the window 
controller will load and be the owner of.  The NIB will *not* "contain" the 
window controller.  The File's Owner placeholder in the NIB represents the 
window controller, but the window controller will be created before the NIB is 
loaded and will, in fact, be the thing which loads the NIB.

> Is this the best approach? Or it is better to put the code in the 
> LTWMainWindow.h, .m and .xib files directly into LTWMainWindowController? 

It makes no sense to discuss where some unspecified code goes until you know 
what the code is for.  As I say, usually there's no need to subclass NSWindow.  
You would have a custom window controller class and a NIB that encodes the 
state of the window and at least some of its views.  The NIB might also encode 
some auxiliary controller objects, like an array controller.

You would only create a custom subclass of NSWindow if the normal mechanisms 
(window controller, window delegate) don't meet your needs.  Don't do it 
preemptively.


> Or instead of using NSWindowController  and NSWindow should I be using 
> NSWindowController and NSViewController?

Well, there will always be a window or otherwise there's nothing for the window 
controller to control and nothing to contain any views that might be controlled 
by any view controllers.

You may find it convenient to organize your project with view controllers for 
some important views within your window, but that sort of depends on how 
complex your window and its view hierarchy are, and whether you'll be swapping 
views in and out or reusing views in multiple contexts.  Again, it doesn't make 
sense to pick a design architecture in the abstract.  You design the 
architecture based on the specifics of your app.


> I’m really confused how to lay this out and want to start off on the right 
> foot.

For starters, just follow the advice in that article.  Create a custom subclass 
of NSWindowController.  Create the NIB to encode the window's configuration and 
view hierarchy.  Don't go more complicated than that — custom window classes, 
separate view NIB with view controllers — until you need to.

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: NSWindowControllers and NSWindow

[Dave]

Hi Ken,

Thanks for this, it seems to be saying there is no need for a separate Window 
Subclass and that the Window Controller Subclass contains all the code needed 
to drive the window. I’m a bit confused of when to use an NSWindow and when to 
use and NSWindowController? 

The way I had thought to do this was to have:

LTWMainWindowController.h, .m and .xib files and LTWMainWindow.h, .m and .xib 
files.

Is this the best approach? Or it is better to put the code in the 
LTWMainWindow.h, .m and .xib files directly into LTWMainWindowController? 

Or instead of using NSWindowController  and NSWindow should I be using 
NSWindowController and NSViewController?

I’m really confused how to lay this out and want to start off on the right foot.

Cheers
Dave

> On 16 Feb 2015, at 14:27, Ken Thomases  wrote:
> 
> On Feb 16, 2015, at 8:17 AM, Dave  wrote:
> 
>> I’ve just started a new Application and I”m wondering what the best/standard 
>> way of setting it up.
> 
> I recommend that you follow the advice in this article: 
> .
> 
> 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

Re: NSWindowControllers and NSWindow

[Ken Thomases]

On Feb 16, 2015, at 8:17 AM, Dave  wrote:

> I’ve just started a new Application and I”m wondering what the best/standard 
> way of setting it up.

I recommend that you follow the advice in this article: 
.

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

NSWindowControllers and NSWindow

[Dave]

Hi All,

It’ s been a while since I worked on the Mac as I’ve been mostly in the iOS 
world lately. 

I’ve just started a new Application and I”m wondering what the best/standard 
way of setting it up.

My initial thought were to have a WindowController:

LTWMainWindowController that looks after a number of Windows. Initial there is 
just one window LTWWindowX (but I want to add others in the future, LTWWindowY, 
LTWWindowZ, etc.), each window looks after a different aspect of the 
application.

I was planning on having a separate Class for LTWMainWindowController and 
LTWWindowX, LTWWindowY and LTWWindowZ.

Does this sounds like a reasonable approach?

I’m using XCode 6 under Yosemite.

Thanks for any advice and suggestions.
All the Best
Dave


___

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: Idea for Improving Vibrancy

[Roland King]

Hmm this thread is rapidly heading towards moderation - like the last one we 
had on vibrancy. 

To the original poster - nice that you made the suggestion/bug report to Apple, 
I don't think you're going to get far with that but who knows. I think the 
effort involved in rolling your own moving window which copies the screen 
background isn't going to be worthwhile, is going to be hard and probably 
rather flaky and anyone who even notices will probably just notice it works 
differently than everything else on the system and not like it. So I personally 
think you're a bit wasting your time if you try to fake that effect. Just my 
opinion. 

And for anyone, like me, who doesn't like the vibrancy effect, you can turn it 
off in preferences. I have (and my air battery lasts about 10% longer since I 
did as well).

> On 16 Feb 2015, at 20:21, Alex Zavatone  wrote:
> 
> I'm so happy I'm not the first guy to think "kill it".
> 
> Kill it.
> 
> On Feb 16, 2015, at 7:17 AM, Greg Weston wrote:
> 
 I have an idea for improving vibrancy
>>> 
>>> Me too. Kill it.
>> 
>> Ditto. I look at vibrancy as Apple showing Microsoft how to do Glass right 
>> without questioning whether it should be done at all. To me, "consume extra 
>> resources in order to reduce the usability of the system" is a fundamentally 
>> flawed pursuit.
>> ___
>> 
>> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: Idea for Improving Vibrancy

[Alex Zavatone]

I'm so happy I'm not the first guy to think "kill it".

Kill it.

On Feb 16, 2015, at 7:17 AM, Greg Weston wrote:

>>> I have an idea for improving vibrancy
>> 
>> Me too. Kill it.
> 
> Ditto. I look at vibrancy as Apple showing Microsoft how to do Glass right 
> without questioning whether it should be done at all. To me, "consume extra 
> resources in order to reduce the usability of the system" is a fundamentally 
> flawed pursuit.
> ___
> 
> 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

Re: Idea for Improving Vibrancy

[Greg Weston]

>> I have an idea for improving vibrancy
> 
> Me too. Kill it.

Ditto. I look at vibrancy as Apple showing Microsoft how to do Glass right 
without questioning whether it should be done at all. To me, "consume extra 
resources in order to reduce the usability of the system" is a fundamentally 
flawed pursuit.
___

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