Re: Attributed strings - and bounding rects

2017-03-03 Thread Alex Zavatone
Isn't this where we set the mask so that the image is not bound by the rect?



On Mar 3, 2017, at 7:18 AM, Peter Hudson wrote:

> Hi All
> 
> I have done the following to try to determine the rect required to draw an 
> attributed string( and thus the height of a row in a table view  - on MacOS ) 
> 
> I am trying to constrain my column width to 60 - and let the possible height 
> of the row be a max of 1000.
> 
> 
> let aString = anAttributedString
> let constrainedSize = NSMakeSize(60.0, 1000.0)
> let optns = NSStringDrawingOptions.usesFontLeading
> let cntxt = NSStringDrawingContext()
> cntxt.minimumScaleFactor = 1.0
> 
> let aRect = aString?.boundingRect(with: constrainedSize, options: optns, 
> context: cntxt)
> 
> 
> 
> After the call to boundingRect,  aRect has its width set to 60 and its height 
> set to 18.  
> 
> This is not however correct for the contents of the attributed string - I 
> would expect the height to be at least 200 or so with the width constrained 
> to 60.
> 
> Any help gratefully received.
> 
> Peter
> 
> 
> 
> ___
> 
> 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


Attributed strings - and bounding rects

2017-03-03 Thread Peter Hudson
Thanks to both of you for helpful code.

I’m still not out of the wood yet though.

Insofar as I can now determine the size of the rect to hold the attributed 
string, 
I can’t write it to the cell correctly.

This is what i do :-


// aString  is a preprepared attributed string
// Determine the height to set the table row to
let sizeLimit = CGSize(width: 60.0, height: CGFloat.greatestFiniteMagnitude)
let size = aString?.boundingRect(with: sizeLimit, options: 
[.usesLineFragmentOrigin, .usesFontLeading], context: nil).integral.size
rowHeight = (size?.height)!

// Setup the text field to the correct height...
guard let vw = tableView.make(withIdentifier: tableColumn!.identifier, owner: 
self) as? NSTableCellView else { return nil }
vw.textField?.setFrameSize(size!)
   
 
// Assign the string
vw.textField?.attributedStringValue = aString



I set the height of the row independently - and that is fine.
But only part of the attributed string  appears occupying one line across the 
middle of the row - truncated and not wrapped over a few lines to fill the rect.

I have tried to play with the text cell in IB to to tell it to wrap its’ 
content.
But all to no avail.

Any thoughts ?

Peter




> --
> 
> Message: 2
> Date: Fri, 03 Mar 2017 14:23:40 +
> From: Jonathan Mitchell 
> To: "Cocoa-dev@lists.apple.com" 
> Subject: Re: Attributed strings -  and bounding rects
> Message-ID: <4453c98a-481c-48a9-b1f1-d7fd40b9d...@mugginsoft.com>
> Content-Type: text/plain; charset=utf-8
> 
> Hi
> 
> I needed to do this for my pdf builder  implementation:
> 
> Using the NSLayoutManager directly gives the best level of control.
> 
> https://github.com/ThesaurusSoftware/PDFPageBuilder/blob/master/PDFPageBuilder/TSPageTextItem.m#L95
> 
>NSRect boundingRect = self.containerRect;
> 
>// if no rect height defined then use default
>BOOL containerHasExplicitHeight = YES;
>if (boundingRect.size.height == 0) {
>boundingRect.size.height = self.pageHeight - 
> self.containerRect.origin.y ;
>containerHasExplicitHeight = NO;
>}
> 
>// allocate text container and layout manager
>NSTextContainer *textContainer = [[NSTextContainer alloc] 
> initWithContainerSize:boundingRect.size];
>textContainer.lineFragmentPadding = 0;  // defaults to non zero
> 
>NSLayoutManager *layoutManager = [[NSLayoutManager alloc] init];
>[layoutManager addTextContainer:textContainer];
>layoutManager.usesFontLeading = YES;
> 
>// allocate text storage and assign layout manager
>self.textStorage = [[NSTextStorage alloc] 
> initWithAttributedString:self.attributedString];
>[self.textStorage addLayoutManager:layoutManager];
> 
>// do glyph layout
>// NOTE: cannot quite get glyphRangeForBoundingRect configured correctly 
> here
>//self.glyphRange = [layoutManager glyphRangeForBoundingRect:boundingRect 
> inTextContainer:textContainer];
>self.glyphRange = [layoutManager glyphRangeForTextContainer:textContainer];
> 
>// get rect used for actual glyph layout
>self.usedTextRect = [layoutManager usedRectForTextContainer:textContainer];
> 
> Jonathan
> 
>> On 3 Mar 2017, at 13:28, Igor Ranieri  wrote:
>> 
>> Hi Peter.
>> 
>> 
>> Have you tried also passing `usesLineFragmentOrigin` as one of the options? 
>> It works here.
>> 
>> Here’s some code I’m currently using to achieve a similar effect:
>> 
>> let sizeLimit = CGSize(width: 80.0, height: CGFloat.greatestFiniteMagnitude)
>> let size = attrString.boundingRect(with: sizeLimit, options: 
>> [.usesLineFragmentOrigin, .usesFontLeading], context: nil).integral.size
>> 
>> And it returns the expected size.
>> 
>> 
>> best,
>> elland
>> 






___

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: I think I messed up the undo-count during load

2017-03-03 Thread Daryle Walker
Nearly a day later, and the bug doesn’t show up now. I hate Heisen-bugs. But is 
there a timing issue on how “NSManagedObjectContext.save” works?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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

Adding a watchOS complication to an existing project?

2017-03-03 Thread Eric E. Dolecki
Everything I've seen shows adding the complication on project creation. How
does one go about adding it to a project later on? I have my watch app
right where I want it, but I didn't think I would need a complication.
Until today.

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: UTI and/or bundle-IDs with small letters

2017-03-03 Thread Kevin Hardman
FWIW: It is my understanding that UTIs are derived from domain names as defined 
in RFC 1035 (relevant portion quoted below). Nevertheless, as already quoted in 
a previous post it is best to use the “Testing for Equality and Conformance” 
APIs or the NSWorkspace’s function type(String, conFormsToType: String).
—kevin

2.3.3. Character Case

For all parts of the DNS that are part of the official protocol, all
comparisons between character strings (e.g., labels, domain names, etc.)
are done in a case-insensitive manner.  At present, this rule is in
force throughout the domain system without exception.  However, future
additions beyond current usage may need to use the full binary octet
capabilities in names, so attempts to store domain names in 7-bit ASCII
or use of special bytes to terminate labels, etc., should be avoided.

When data enters the domain system, its original case should be
preserved whenever possible.  In certain circumstances this cannot be
done.  For example, if two RRs are stored in a database, one at x.y and
one at X.Y, they are actually stored at the same place in the database,
and hence only one casing would be preserved.  The basic rule is that
case can be discarded only when data is used to define structure in a
database, and two names are identical when compared in a case
insensitive manner.

___

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: Attributed strings - and bounding rects

2017-03-03 Thread Peter Hudson
Thanks for that piece of code - it works a treat and produces a sensible height 
!

The only problem is that my attributed string does not draw correctly .
The string has a number of new lines ( \n ) in it and would need to be wrapped 
into the space.  
It all works perfectly in objective-C !
But, I do seem to remember having to tell the cell to wrap the text …..

Many thanks 

Peter




> On 3 Mar 2017, at 13:28, Igor Ranieri  wrote:
> 
> Hi Peter.
> 
> 
> Have you tried also passing `usesLineFragmentOrigin` as one of the options? 
> It works here.
> 
> Here’s some code I’m currently using to achieve a similar effect:
> 
> let sizeLimit = CGSize(width: 80.0, height: CGFloat.greatestFiniteMagnitude)
> let size = attrString.boundingRect(with: sizeLimit, options: 
> [.usesLineFragmentOrigin, .usesFontLeading], context: nil).integral.size
> 
> And it returns the expected size.
> 
> 
> best,
> elland
> 
> 
>> On 3. Mar 2017, at 14:18, Peter Hudson  wrote:
>> 
>> Hi All
>> 
>> I have done the following to try to determine the rect required to draw an 
>> attributed string( and thus the height of a row in a table view  - on MacOS 
>> ) 
>> 
>> I am trying to constrain my column width to 60 - and let the possible height 
>> of the row be a max of 1000.
>> 
>> 
>> let aString = anAttributedString
>> let constrainedSize = NSMakeSize(60.0, 1000.0)
>> let optns = NSStringDrawingOptions.usesFontLeading
>> let cntxt = NSStringDrawingContext()
>> cntxt.minimumScaleFactor = 1.0
>> 
>> let aRect = aString?.boundingRect(with: constrainedSize, options: optns, 
>> context: cntxt)
>> 
>> 
>> 
>> After the call to boundingRect,  aRect has its width set to 60 and its 
>> height set to 18.  
>> 
>> This is not however correct for the contents of the attributed string - I 
>> would expect the height to be at least 200 or so with the width constrained 
>> to 60.
>> 
>> Any help gratefully received.
>> 
>> Peter
>> 
>> 
>> 
>> ___
>> 
>> 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/igor%40elland.me
>> 
>> This email sent to i...@elland.me
> 


___

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

Issue with addTitlebarAccessoryViewController on 10.10

2017-03-03 Thread Mark Allan
Hi all,

I've got an NSWindow which has an NSToolbar added programmatically. The window 
does not use a shared title/toolbar.  I now want to add a little bit of 
text/button to the window's titlebar, so for OS X 10.6 to 10.9, I'm doing it 
the old way playing around with NSWindow subviews, which works fine.

On versions 10.10+ I'm using addTitlebarAccessoryViewController which works 
great on 10.11 and 10.12, but for some reason it shifts the toolbar buttons out 
of position on 10.10.

Judging by the AppKit release notes, this is a known issue which was fixed in 
10.11, and also by linking on 10.11

> For applications linked on 10.11 and higher, a 
> NSTitlebarAccessoryViewController with the layoutAttribute set to 
> NSLayoutAttributeRight will no longer right indent toolbar items, unless the 
> titleVisibility == NSWindowTitleHidden. This allows placing a 
> view/button/textfield (etc) above the toolbar without right indenting the 
> toolbar. However, for the NSWindowTitleHidden, there is still a desire to 
> indent the toolbar on the right to leave space for the accessory view.

I'm currently building on macOS 10.12 (with target of 10.6) but the issue still 
shows up for users on OS X 10.11, even with the viewcontroller's 
layoutAttribute = NSLayoutAttributeRight.

Does anyone know of a fix or workaround I could use please?

If it comes to it, I could still use the old subview manipulation method on 
10.10 and users would just have to put up with seeing junk in the log about 
adding an unknown subview, but I'd rather avoid that if possible!

Would appreciate any help.

Many thanks
Mark


___

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: Attributed strings - and bounding rects

2017-03-03 Thread Jonathan Mitchell
Hi

I needed to do this for my pdf builder  implementation:

Using the NSLayoutManager directly gives the best level of control.
 
https://github.com/ThesaurusSoftware/PDFPageBuilder/blob/master/PDFPageBuilder/TSPageTextItem.m#L95

NSRect boundingRect = self.containerRect;

// if no rect height defined then use default
BOOL containerHasExplicitHeight = YES;
if (boundingRect.size.height == 0) {
boundingRect.size.height = self.pageHeight - 
self.containerRect.origin.y ;
containerHasExplicitHeight = NO;
}

// allocate text container and layout manager
NSTextContainer *textContainer = [[NSTextContainer alloc] 
initWithContainerSize:boundingRect.size];
textContainer.lineFragmentPadding = 0;  // defaults to non zero

NSLayoutManager *layoutManager = [[NSLayoutManager alloc] init];
[layoutManager addTextContainer:textContainer];
layoutManager.usesFontLeading = YES;

// allocate text storage and assign layout manager
self.textStorage = [[NSTextStorage alloc] 
initWithAttributedString:self.attributedString];
[self.textStorage addLayoutManager:layoutManager];

// do glyph layout
// NOTE: cannot quite get glyphRangeForBoundingRect configured correctly 
here
//self.glyphRange = [layoutManager glyphRangeForBoundingRect:boundingRect 
inTextContainer:textContainer];
self.glyphRange = [layoutManager glyphRangeForTextContainer:textContainer];

// get rect used for actual glyph layout
self.usedTextRect = [layoutManager usedRectForTextContainer:textContainer];

Jonathan

> On 3 Mar 2017, at 13:28, Igor Ranieri  wrote:
> 
> Hi Peter.
> 
> 
> Have you tried also passing `usesLineFragmentOrigin` as one of the options? 
> It works here.
> 
> Here’s some code I’m currently using to achieve a similar effect:
> 
> let sizeLimit = CGSize(width: 80.0, height: CGFloat.greatestFiniteMagnitude)
> let size = attrString.boundingRect(with: sizeLimit, options: 
> [.usesLineFragmentOrigin, .usesFontLeading], context: nil).integral.size
> 
> And it returns the expected size.
> 
> 
> best,
> elland
> 
> 
>> On 3. Mar 2017, at 14:18, Peter Hudson  wrote:
>> 
>> Hi All
>> 
>> I have done the following to try to determine the rect required to draw an 
>> attributed string( and thus the height of a row in a table view  - on MacOS 
>> ) 
>> 
>> I am trying to constrain my column width to 60 - and let the possible height 
>> of the row be a max of 1000.
>> 
>> 
>> let aString = anAttributedString
>> let constrainedSize = NSMakeSize(60.0, 1000.0)
>> let optns = NSStringDrawingOptions.usesFontLeading
>> let cntxt = NSStringDrawingContext()
>> cntxt.minimumScaleFactor = 1.0
>> 
>> let aRect = aString?.boundingRect(with: constrainedSize, options: optns, 
>> context: cntxt)
>> 
>> 
>> 
>> After the call to boundingRect,  aRect has its width set to 60 and its 
>> height set to 18.  
>> 
>> This is not however correct for the contents of the attributed string - I 
>> would expect the height to be at least 200 or so with the width constrained 
>> to 60.
>> 
>> Any help gratefully received.
>> 
>> Peter
>> 
>> 
>> 
>> ___
>> 
>> 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/igor%40elland.me
>> 
>> This email sent to i...@elland.me
> 
> 
> ___
> 
> 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/lists%40mugginsoft.com
> 
> This email sent to li...@mugginsoft.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: Attributed strings - and bounding rects

2017-03-03 Thread Igor Ranieri
Hi Peter.


Have you tried also passing `usesLineFragmentOrigin` as one of the options? It 
works here.

Here’s some code I’m currently using to achieve a similar effect:

let sizeLimit = CGSize(width: 80.0, height: CGFloat.greatestFiniteMagnitude)
let size = attrString.boundingRect(with: sizeLimit, options: 
[.usesLineFragmentOrigin, .usesFontLeading], context: nil).integral.size

And it returns the expected size.


best,
elland


> On 3. Mar 2017, at 14:18, Peter Hudson  wrote:
> 
> Hi All
> 
> I have done the following to try to determine the rect required to draw an 
> attributed string( and thus the height of a row in a table view  - on MacOS ) 
> 
> I am trying to constrain my column width to 60 - and let the possible height 
> of the row be a max of 1000.
> 
> 
> let aString = anAttributedString
> let constrainedSize = NSMakeSize(60.0, 1000.0)
> let optns = NSStringDrawingOptions.usesFontLeading
> let cntxt = NSStringDrawingContext()
> cntxt.minimumScaleFactor = 1.0
> 
> let aRect = aString?.boundingRect(with: constrainedSize, options: optns, 
> context: cntxt)
> 
> 
> 
> After the call to boundingRect,  aRect has its width set to 60 and its height 
> set to 18.  
> 
> This is not however correct for the contents of the attributed string - I 
> would expect the height to be at least 200 or so with the width constrained 
> to 60.
> 
> Any help gratefully received.
> 
> Peter
> 
> 
> 
> ___
> 
> 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/igor%40elland.me
> 
> This email sent to i...@elland.me


___

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

Attributed strings - and bounding rects

2017-03-03 Thread Peter Hudson
Hi All

I have done the following to try to determine the rect required to draw an 
attributed string( and thus the height of a row in a table view  - on MacOS ) 

I am trying to constrain my column width to 60 - and let the possible height of 
the row be a max of 1000.


let aString = anAttributedString
let constrainedSize = NSMakeSize(60.0, 1000.0)
let optns = NSStringDrawingOptions.usesFontLeading
let cntxt = NSStringDrawingContext()
cntxt.minimumScaleFactor = 1.0

let aRect = aString?.boundingRect(with: constrainedSize, options: optns, 
context: cntxt)



After the call to boundingRect,  aRect has its width set to 60 and its height 
set to 18.  

This is not however correct for the contents of the attributed string - I would 
expect the height to be at least 200 or so with the width constrained to 60.

Any help gratefully received.

Peter



___

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: KVC Validation w/ custom Formatter not working

2017-03-03 Thread Luc Van Bogaert
The formatting with the custom formatter is working. Due to a misunderstanding 
on my part, I was incorrectly assuming that the validation method was not 
called. Actually, that is only the case when the formatter returns "false" from 
its getObjectValue(:for:errorDescription:) method, which I guess is by design. 
On the contrary, when the formatter decides the input is valid, my validation 
method indeed gets called.

Thanks for your suggestion on using a custom validation method.

-- 
Luc Van Bogaert
Follow my Blog @ http://folkwire.wordpress.com

> On 27 Feb 2017, at 22:58, Quincey Morris 
>  wrote:
> 
> On Feb 26, 2017, at 12:40 , Luc Van Bogaert  > wrote:
>> 
>> my model class overrides 
>> 
>> validateValue(_ ioValue: AutoreleasingUnsafeMutablePointer, 
>> forKey inKey: String) throws
>> 
>> After changing the text in the textfield, my validation method is not 
>> called. When I replace my custom formatter with an instance of 
>> NSNumberFormatter, everything works as expected.
> 
> You don’t say whether your custom formatter is used for formatting, and it’s 
> just validation that’s missing, or if the formatter is totally ignored. It 
> might be worth adding code that checks to see if the field has a formatter, 
> and if the formatter has the correct class. Or, if the NIB loading calls a 
> different initializer than you were expecting, then perhaps your formatter 
> isn’t being set up properly.
> 
> I have a vague recollection that there was an IB bug where custom formatters 
> were not honored, which was fixed in a recent version of Xcode. However, I 
> can’t find anything about this in the release notes, so I may have dreamed 
> it. Still, it might be worth trying this in the latest Xcode beta.
> 
> Also, I would not recommend overriding validateValue(_:forKey:) directly, 
> since that overrides the entire KVC  validation mechanism. That shouldn’t be 
> a problem if you invoke the super implementation properly for keys you don’t 
> handle, but it’s probably safer and clearer to use a custom validation method 
> of the form validate(_:). See:
> 
>   
> https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/KeyValueCoding/ValidatingProperties.html
>  
> 
> 
> 

___

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