RE: NSTextFields will not fully justify in 10.11

[Lee Ann Rucker]

If it's autolayout, double-check it, especially the priorities; it might be 
hugging more than you expect. What does the UI layout debugger show? I've found 
some layout surprises that way.

From: cocoa-dev-bounces+lrucker=vmware@lists.apple.com 
[cocoa-dev-bounces+lrucker=vmware@lists.apple.com] on behalf of Trygve Inda 
[cocoa...@xericdesign.com]
Sent: Saturday, January 23, 2016 11:38 PM
To: Jens Alfke
Cc: Cocoa-Dev List
Subject: Re: NSTextFields will not fully justify in 10.11

>
>> On Jan 23, 2016, at 7:44 PM, Trygve Inda  wrote:
>>
>> When running in 10.11, my fully justified text fields are no longer so...
>> They are left justified only.
>>
>> Is there a fix for this?
>
> Use an NSTextView instead? It’s generally better to use that class when the
> user might enter more than a line or two of text, since it has more features
> (scrollbars, preserving selection when it loses focus, etc.)
>
> —Jens

These are static text fields (for copyright text which is several lines).

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

View-based NSTableView and ending editing with "return"

[Arved von Brasch]

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
___

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: Obj-C - your thoughts on hiding data members?

[Quincey Morris]

On Jan 24, 2016, at 15:55 , Graham Cox  wrote:
> 
> Do you generally think this is worth doing?

I’m not sure its *worth* doing, if you’re looking for a big pay-off, but I 
agree with Jens that I’d probably do it.

Sometimes it can be illuminating to see how small a public interface you need 
to expose. In other cases, it can serve as a kind of code smell to realize that 
the interface remains stubbornly large.

I’d also suggest that “modern” Obj-C code, private @interface () extensions 
tend to disappear completely. You no longer need them for forward-declaring 
file-local methods. You also — perhaps this might seem a bit controversial — no 
longer need them for most default (@synthesize-able) private properties. Since 
ARC and the non-fragile ABI, there’s really no reason to avoid instance 
variables in favor of private synthesized properties, except when there’s 
additional behavior that requires a getter or setter.

In most cases, the only @interface () extensions that remained in my classes 
were for private readwrite overrides of public readonly properties. Almost 
everything else just disappeared. It was a little eerie.

Note that ‘copy’ usually isn’t vital for private properties, because they’re 
mostly NSString values, and even if you set them to a NSMutableString, you 
rarely have any code that’s capable of mutating the string later.

You’d need a property for an 8-byte value that needs to be atomic, but those 
are pretty rare.


___

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: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

In this effort, what visual convention would you add to the private properties' 
names to indicate to the viewer that these are not public properties?

A prefix of _ is already used by the compiler to indicate the internal ivar 
backing properties so, what convention should be used for private properties?

On Jan 24, 2016, at 8:05 PM, Quincey Morris wrote:

> On Jan 24, 2016, at 15:55 , Graham Cox  wrote:
>> 
>> Do you generally think this is worth doing?
> 
> I’m not sure its *worth* doing, if you’re looking for a big pay-off, but I 
> agree with Jens that I’d probably do it.
> 
> Sometimes it can be illuminating to see how small a public interface you need 
> to expose. In other cases, it can serve as a kind of code smell to realize 
> that the interface remains stubbornly large.
> 
> I’d also suggest that “modern” Obj-C code, private @interface () extensions 
> tend to disappear completely. You no longer need them for forward-declaring 
> file-local methods. You also — perhaps this might seem a bit controversial — 
> no longer need them for most default (@synthesize-able) private properties. 
> Since ARC and the non-fragile ABI, there’s really no reason to avoid instance 
> variables in favor of private synthesized properties, except when there’s 
> additional behavior that requires a getter or setter.
> 
> In most cases, the only @interface () extensions that remained in my classes 
> were for private readwrite overrides of public readonly properties. Almost 
> everything else just disappeared. It was a little eerie.
> 
> Note that ‘copy’ usually isn’t vital for private properties, because they’re 
> mostly NSString values, and even if you set them to a NSMutableString, you 
> rarely have any code that’s capable of mutating the string later.
> 
> You’d need a property for an 8-byte value that needs to be atomic, but those 
> are pretty rare.
> 
> 
> ___
> 
> 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: Obj-C - your thoughts on hiding data members?

[Jens Alfke]

I do; it makes the @interface shorter and easier to read, and afterwards if you 
change/add/remove an instance variable, it only touches the .m file, so it 
doesn’t force a bunch of other files to recompile.

—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: Obj-C - your thoughts on hiding data members?

[Quincey Morris]

On Jan 24, 2016, at 17:34 , Alex Zavatone  wrote:
> 
> A prefix of _ is already used by the compiler to indicate the internal ivar 
> backing properties so, what convention should be used for private properties?

That's kinda a whole different discussion. In Graham’s case, the properties 
were already private, but they just happened to have been exposed in the public 
header file. Presumably, they would keep the same names when moved to the 
implementation file.

In general, use of naming conventions is a personal opinion that we’re never 
going to reach consensus on. I happen to be at the unpopular end of this — I’ve 
never used a syntactic naming convention for variables, other than the forced 
“_” for backing variables that correspond to synthesized properties — and it’s 
pretty lonely down here on the bendy end of the tree branch.

___

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

delete stock apps

[Rick C.]

Does anyone know if there’s a way to delete stock apps on 10.11 without 
disabling SIP and rebooting the machine?  Or, is there a way to disable SIP 
without rebooting?  Thanks!
___

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: delete stock apps

[Jens Alfke]

> On Jan 24, 2016, at 10:16 PM, Rick C.  wrote:
> 
> Does anyone know if there’s a way to delete stock apps on 10.11 without 
> disabling SIP and rebooting the machine?

This doesn’t sound like a coding question. Try Apple’s support forums or 
apple.stackexchange.com .

>  Or, is there a way to disable SIP without rebooting?

No. That’s part of what makes it secure.

—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: NSTextFields will not fully justify in 10.11

[Trygve Inda]

> If it's autolayout, double-check it, especially the priorities; it might be
> hugging more than you expect. What does the UI layout debugger show? I've
> found some layout surprises that way.
> 

It is not using Auto-Layout. I tried creating one with Auto-Layout and it
doesn't work either.

I created rdar://24316348

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

DeepCopy Arrays and Dictionaries

[Dave]

Which brings me to another questions, how to deep copy a network without saving 
it to disk?

One thing about making it NSCoding Compliant is that all my objects now support 
NSCopying too, e.g. define a copyWithZone method, so in order to deep copy one 
of my root arrays/dictionaries. can I just do this?

myDestNetwork.pArray1 = [mySourceNetwork copy];

Or do I need to use the initWithArray: copyItems:YES and 
initWithDictionary: copyItems:YES methods?

If I need to use the init methods, then how can I tell which method (deep or 
shallow) to use?

When I’m saving/restoring I want a shallow copy, but I then want to clone this 
network into a working copy. The working copy gets updated which the App is 
running and at certain points dumped to file. This file will then be used to 
update the database and a new prototype file generated for use by the App.

I’ve done a couple of searching and there are a lot of conflicting answers……..

Basically I need to clone off sub-networks from the main network, update them 
and at some point save them to disk.

Thanks for the help.
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: How to save a Dictionary Network to a plist file?

[Dave]

Hi,

I did a bit of studying about save/restoring networks in general and it’s not 
that straight forward if you want a self-referential put back in place after it 
is restored. From looking at what the standard archiver/unarchiver does it is 
exactly what I want for now and is really fast and easy to use (although having 
to ensure everything conforms to NSCoding is a bit of a pain - see below).

We do need a more flexible way of doing it though but I think we will use this 
for now and develop an SQLite database, this has the advantage of being totally 
portable. We can use the archive file format to store networks until we are 
ready to commit them to the database. 

I’m really impressed with the speed of the archiver though and I’m pleased you 
suggest I use it. 

One thing that would be super cool is if there was a property attribute for 
this, e.g.

@property (nonatomic,copy,archive)  NSString*   pString;

And it would synthesize the initWithCoder, encodeWithCoder and copyWithZone 
methods.

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

DeepCopy Arrays and Dictionaries

[Dave]

Sorry that should have read:

When I’m saving/restoring I want a shallow copy, but I then want to clone this 
network into a working copy I need a deep copy. The working copy gets updated 
which the App is running and at certain points dumped to file. This file will 
then be used to update the database and a new prototype file generated for use 
by the App.

I’ve just looked up the initWithArray/Dictionary methods and there doesn’t seem 
to a Mutable versions of these methods?

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: Problem Archiving/Un-archiving Custom Objects

[Dave]

Thanks a lot for the clarification…..
___

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: DeepCopy Arrays and Dictionaries

[Quincey Morris]

On Jan 24, 2016, at 08:16 , Dave  wrote:
> 
> can I just do this?
> 
> myDestNetwork.pArray1 = [mySourceNetwork copy];

No. The ‘copy’ method has no intrinsic depth or shallowness. For your custom 
classes, it does what you’ve implemented it to do. For Cocoa classes, they do 
what they’re documented to do.

> Or do I need to use the initWithArray: copyItems:YES and 
> initWithDictionary: copyItems:YES methods?

No, not that either. According to the NSArray documentation, for example:

> “flag: If YES, each object in array receives a copyWithZone: message to 
> create a copy of the object”
> …
> "The copyWithZone: method performs a shallow copy. If you have a collection 
> of arbitrary depth, passing YES for the flag parameter will perform an 
> immutable copy of the first level below the surface.”

(Note that this last bit means that ‘copyWithZone:’ *sent to collection 
classes* performs a shallow copy. As I said before, in general there’s no 
absolute API contract. In other cases, it does whatever it does.)

The *easy* way to do a deep copy is in fact to archive the root object and 
unarchive the result.

Or, you can write your own deep copy mechanism. In it, you’ll have to re-invent 
parts of the archiving mechanism. In particular, you’ll probably create a 
mapping table that maps source object pointers into their copied equivalents. 
The presence of a source object in the mapping both tells you whether it’s been 
copied (allowing you to walk the object network graph without going in 
circles), and what it was copied to. You’ll likely also want some kind of 
‘copyWithMapping:’ method in each of your custom classes, paralleling the 
semantics of ‘encodeWithCoder:’.

Personally, if I had an archive+unarchive mechanism that gave the correct 
result, I’d use that in preference to writing the copying code, memory and 
performance considerations allowing.

___

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: NSTextFields will not fully justify in 10.11

[Quincey Morris]

On Jan 24, 2016, at 07:24 , Trygve Inda  wrote:
> 
> It is not using Auto-Layout. I tried creating one with Auto-Layout and it
> doesn't work either.

For interest’s sake:

a. If you specify the text field as being left justified instead of fully 
justified, does it wrap at the same or different places in the text? Do you get 
the same problem with a different font, or a larger point size?

(I’m wondering if it’s a problem with a custom font.)

b. Are you displaying plain text or attributed text? If attributed, what 
happens to plain text?

(I’m wondering if it’s NSAttributedText or NSParagraphStyle that’s behaving 
differently, not NSTextField.)

___

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: How to save a Dictionary Network to a plist file?

[Jens Alfke]

> On Jan 24, 2016, at 7:12 AM, Dave  wrote:
> 
> And it would synthesize the initWithCoder, encodeWithCoder and copyWithZone 
> methods.

It would be nice, but the compiler doesn’t always have enough information to do 
this:

* Some instance variables are transient and shouldn’t be archived.
* Some aren’t an archivable type (e.g. a C struct, C++ class, or a pointer to 
such) and need to be transformed before being archived (and after being 
unarchived.)
* Sometimes the object needs to do extra initialization after loading the 
instance variables.

That said, it’d be neat to have a little tool that would read your class’s 
source code and spit out some basic source code for those methods, which you 
could then paste in and fix up.

—Jens (who’s written at least three object persistence systems in his career… :)
___

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: How to save a Dictionary Network to a plist file?

[Alex Zavatone]

On Jan 24, 2016, at 1:51 PM, Jens Alfke  wrote:

> 
>> On Jan 24, 2016, at 7:12 AM, Dave  wrote:
>> 
>> And it would synthesize the initWithCoder, encodeWithCoder and copyWithZone 
>> methods.
> 
> It would be nice, but the compiler doesn’t always have enough information to 
> do this:
> 
> * Some instance variables are transient and shouldn’t be archived.
> * Some aren’t an archivable type (e.g. a C struct, C++ class, or a pointer to 
> such) and need to be transformed before being archived (and after being 
> unarchived.)
> * Sometimes the object needs to do extra initialization after loading the 
> instance variables.
> 
> That said, it’d be neat to have a little tool that would read your class’s 
> source code and spit out some basic source code for those methods, which you 
> could then paste in and fix up.

Yeah, as long as it’s an NSObject type and it’s in the class, we should be able 
to automatically get the property type of class and automatically create the 
archiver and dearchiver.

Writing this stuff manually every time seems stupid for the base cases.


> —Jens (who’s written at least three object persistence systems in his career… 
> :)
> ___
> 
> 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: NSTextFields will not fully justify in 10.11

[Trygve Inda]

> On Jan 24, 2016, at 07:24 , Trygve Inda  wrote:
>> 
>> It is not using Auto-Layout. I tried creating one with Auto-Layout and it
>> doesn't work either.
> 
> For interest’s sake:
> 
> a. If you specify the text field as being left justified instead of fully
> justified, does it wrap at the same or different places in the text? Do you
> get the same problem with a different font, or a larger point size?

Justified wraps exactly the same as Left - regardless of font or size.

> (I’m wondering if it’s a problem with a custom font.)
> 
> b. Are you displaying plain text or attributed text? If attributed, what
> happens to plain text?

Plain text in an NSTextField with static text built in IB/Xcode 7.2.




___

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: How to save a Dictionary Network to a plist file?

[dangerwillrobinsondanger]

> On Jan 25, 2016, at 4:01 AM, Alex Zavatone  wrote:
> 
> Yeah, as long as it’s an NSObject type and it’s in the class, we should be 
> able to automatically get the property type of class and automatically create 
> the archiver and dearchiver.
> 
> Writing this stuff manually every time seems stupid for the base cases.

Hence the long ago create property list format. 
There's a reason it's pervasively used by Cocoa. 

Swift kind of throws a monkey wrench into that . . . 


___

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

Obj-C - your thoughts on hiding data members?

[Graham Cox]

In Objective-C 2, data members can be moved into a @interface MyClass () 
section which lives in the .m file, rather than in the header file as in the 
classic case. This makes sense - those data members are typically part of the 
private implementation details of a class and not part of the public interface. 

But is it worth updating older code to follow this convention? I’ve updated a 
lot of older code to declare @properties instead of classic getters and 
setters, and that definitely improves readability. This is a further step I’m 
contemplating but the benefits are less clear. Do you generally think this is 
worth doing?


—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