Re: needsDisplay and subviews

2017-03-08 Thread Quincey Morris 
On Mar 8, 2017, at 15:25 , Jeremy Hughes  wrote:
> 
> My conclusion (for now) is that “needsDisplay” causes subviews to be redrawn 
> - except when “wantsLayer” has been set to true.
> 
> Does that make sense?

Sure. In some cases, such as when using layers, the result of your “draw(_:)” 
methods for custom subviews can be skipped as an optimization, since their 
output might have been cached earlier in a backing store.

“needDisplay” applies to the view(s) for which it is set. That means the 
“draw(_:)” method is called for that view (or those views). However, in a later 
part of the screen update process, this new drawing output must be composited 
with subview drawing output.

For subviews that didn’t have “needsDisplay” set, this compositing can be done 
with the existing backing store, if available. Otherwise, the subview 
“draw(_:)” methods have to be called too, simply to (re)create the subview 
contents. It can be difficult to predict which drawing paths will be taken.

One situation where subviews may already be cached is when you are using 
layers, since layers *are* drawing caches.

So, the correct answer to your original question, I think, is that if your 
model data has changed in such a way that the representation in custom views no 
longer reflects the data, then you should set “needsDisplay” on *every* custom 
subview that uses “draw(_:)”.

If you just need your changed view to be re-composited with the same subview 
contents as previously, then you don’t need to set “needsDisplay” on the 
subviews, just the parent view.
___

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: needsDisplay and subviews

2017-03-08 Thread Jeremy Hughes 
The situation in which subviews were not being redrawn seems to have been a xib 
problem. After spending some time getting nowhere I decided to recreate the xib 
by taking a different xib (which used the same custom view) and cutting it 
down. This worked without any problems. Then I compared the two xibs in 
TextWrangler and found that the one which didn’t work had a view where 
“wantsLayer” was set to YES - and this corresponded to a “Core Animation Layer” 
checkbox in Interface Builder.

I didn’t intentionally select this checkbox, and I didn’t originally look at 
this pane (View Effects) when I was trying to spot differences between the view 
that worked and the view that didn’t. But in my first attempt at creating this 
xib (where the problem occurred) I copied and pasted a view from another xib, 
whereas in my second attempt I duplicated the entire xib and modified it - so 
maybe the checkbox property was set as a side effect of copying and pasting.

One other strange behaviour with the problem xib occurred when I added some 
debugging code to try and find out why the subview wasn’t being redrawn:

view.needsDisplay = true
print("view.needsDisplay: \(view.needsDisplay)”)

and this consistently printed “ view.needsDisplay: false” after 
view.needsDisplay had been set to true. Despite this, “draw” (= drawRect in 
ObjC) was being called for “view” - but not for view’s subviews.

My conclusion (for now) is that “needsDisplay” causes subviews to be redrawn - 
except when “wantsLayer” has been set to true.

Does that make sense?

Jeremy

--

> On 8 Mar 2017, at 17:12, Jeremy Hughes  wrote:
> 
> Thanks - that seems reasonably clear, and it agrees with what I previously 
> thought, but I’ve got a situation where it doesn’t seem to be happening.
> 
> There are contradictory opinions on Stack Overflow: 
> 
> http://stackoverflow.com/questions/8718290/setneedsdisplay-and-subviews
> http://stackoverflow.com/questions/11480341/setneedsdisplay-does-not-trigger-drawrect-in-subviews-as-expected
> 
> Jeremy
> 
> --
> 
>> On 8 Mar 2017, at 17:01, Ben Kennedy  wrote:
>> 
>> 
>>> On 08 Mar 2017, at 8:46 am, Jeremy Hughes  
>>> wrote:
>>> 
>>> If needsDisplay is set to true for an NSView, does that also cause subviews 
>>> to be redrawn?
>> 
>> Admittedly I've been mostly doing iOS development for the last several years 
>> and barely any Mac lately, but, according to the current docs:
>> 
>> needsDisplay: "The displayIfNeeded methods check the value of this property 
>> to avoid unnecessary drawing, and all display methods set the value back to 
>> false when the view is up to date."
>> 
>> display(): "Displays the view and all its subviews if possible, invoking 
>> each of the NSView methods lockFocus(), draw(_:), and unlockFocus() as 
>> necessary."
>> 
>> Thus, it seems to follow that so long a custom view's display() calls super, 
>> then all of its subviews should also be drawn when its needsDisplay is true.
>> 
>> What sort of contradictions are out there?
>> 
>> b
>> 
> 


___

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: Unicode filenames with Apple File System and UIManagedDocument

2017-03-08 Thread Peter Edberg 

> On Mar 8, 2017, at 1:44 PM, David Reed  wrote:
> 
> 
>> On Mar 8, 2017, at 4:35 PM, Peter Edberg  wrote:
>> 
>> 
>>> On Mar 8, 2017, at 12:00 PM, cocoa-dev-requ...@lists.apple.com wrote:
>>> 
>>> Message: 1
>>> Date: Tue, 07 Mar 2017 15:03:41 -0500
>>> From: davel...@mac.com
>>> To: Alastair Houghton ,   David Duncan
>>> 
>>> Cc: cocoa-dev list 
>>> Subject: Re: Unicode filenames with Apple File System and
>>> UIManagedDocument
>>> 
>>> 
>>> 
>>> My app has the option to zip up the directories UIManagedDocument creates 
>>> and email it (so users can back up their data or share it with others). The 
>>> person sent it to me. Below is what I did in the Terminal so you can see 
>>> what happens when I try to unzip it. If this doesn’t come through on the 
>>> email list with the characters looking correct, I can screenshot it.
>>> 
>>> This is one of the data files that was created on iOS 10.2 and then won’t 
>>> open now on an iOS 10.3 device. It appears the directory name and zip file 
>>> name do not match and it won’t unzip correctly. It does create a directory 
>>> but the directory is empty instead of containing the StoreContent and 
>>> persistentStore files. The zip file is 34KB so it may or may not actually 
>>> have the data in it.
>>> 
>>> $ ls
>>> إعلام.zip
>> 
>> 
>> It is probably worth noting that the first Arabic character in the above 
>> filename (i.e. the one that appears on the right, adjacent to the period) 
>> has a canonical decomposition, as per this line from UnicodeData.txt 
>> (http://www.unicode.org/Public/9.0.0/ucd/UnicodeData.txt 
>> ):
>> 0625;ARABIC LETTER ALEF WITH HAMZA BELOW;Lo;0;AL;0627 0655;...
>> 
>> That is, in some cases this character 0625 (UTF8: D8 A5)  will be converted 
>> to the sequence 0627 0655 (UTF8: D8 A7 D9 95).
>> 
>> This decomposition was introduced in Unicode 3.0. If there are processes 
>> that use decomposition according to Unicode 9 versus Unicode 2.x, or 
>> processes that don't decompose versus ones that do, then the filename bytes 
>> will be different.
>> 
>> - Peter E
> 
> Thanks Peter.
> 
> I am going to try to find time in the next few days to file a bug report. 
> I'll obviously include this information. Is there anything else you think I 
> should include?

Nothing else leaps out at me other than the usuals (system version, exact steps 
to repro, etc.).
- Peter E
___

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: Unicode filenames with Apple File System and UIManagedDocument

2017-03-08 Thread davelist 

> On Mar 8, 2017, at 4:35 PM, Peter Edberg  wrote:
> 
> 
>> On Mar 8, 2017, at 12:00 PM, cocoa-dev-requ...@lists.apple.com wrote:
>> 
>> 
>> My app has the option to zip up the directories UIManagedDocument creates 
>> and email it (so users can back up their data or share it with others). The 
>> person sent it to me. Below is what I did in the Terminal so you can see 
>> what happens when I try to unzip it. If this doesn’t come through on the 
>> email list with the characters looking correct, I can screenshot it.
>> 
>> This is one of the data files that was created on iOS 10.2 and then won’t 
>> open now on an iOS 10.3 device. It appears the directory name and zip file 
>> name do not match and it won’t unzip correctly. It does create a directory 
>> but the directory is empty instead of containing the StoreContent and 
>> persistentStore files. The zip file is 34KB so it may or may not actually 
>> have the data in it.
>> 
>> $ ls
>> إعلام.zip
> 
> 
> It is probably worth noting that the first Arabic character in the above 
> filename (i.e. the one that appears on the right, adjacent to the period) has 
> a canonical decomposition, as per this line from UnicodeData.txt 
> (http://www.unicode.org/Public/9.0.0/ucd/UnicodeData.txt 
> ):
> 0625;ARABIC LETTER ALEF WITH HAMZA BELOW;Lo;0;AL;0627 0655;...
> 
> That is, in some cases this character 0625 (UTF8: D8 A5)  will be converted 
> to the sequence 0627 0655 (UTF8: D8 A7 D9 95).
> 
> This decomposition was introduced in Unicode 3.0. If there are processes that 
> use decomposition according to Unicode 9 versus Unicode 2.x, or processes 
> that don't decompose versus ones that do, then the filename bytes will be 
> different.
> 
> - Peter E

Thanks Peter.

I am going to try to find time in the next few days to file a bug report. I'll 
obviously include this information. Is there anything else you think I should 
include?

Thanks,
Dave Reed
___

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: Unicode filenames with Apple File System and UIManagedDocument

2017-03-08 Thread Peter Edberg 

> On Mar 8, 2017, at 12:00 PM, cocoa-dev-requ...@lists.apple.com wrote:
> 
> Message: 1
> Date: Tue, 07 Mar 2017 15:03:41 -0500
> From: davel...@mac.com
> To: Alastair Houghton , David Duncan
>   
> Cc: cocoa-dev list 
> Subject: Re: Unicode filenames with Apple File System and
>   UIManagedDocument
> 
> 
> 
> My app has the option to zip up the directories UIManagedDocument creates and 
> email it (so users can back up their data or share it with others). The 
> person sent it to me. Below is what I did in the Terminal so you can see what 
> happens when I try to unzip it. If this doesn’t come through on the email 
> list with the characters looking correct, I can screenshot it.
> 
> This is one of the data files that was created on iOS 10.2 and then won’t 
> open now on an iOS 10.3 device. It appears the directory name and zip file 
> name do not match and it won’t unzip correctly. It does create a directory 
> but the directory is empty instead of containing the StoreContent and 
> persistentStore files. The zip file is 34KB so it may or may not actually 
> have the data in it.
> 
> $ ls
> إعلام.zip


It is probably worth noting that the first Arabic character in the above 
filename (i.e. the one that appears on the right, adjacent to the period) has a 
canonical decomposition, as per this line from UnicodeData.txt 
(http://www.unicode.org/Public/9.0.0/ucd/UnicodeData.txt 
):
0625;ARABIC LETTER ALEF WITH HAMZA BELOW;Lo;0;AL;0627 0655;...

That is, in some cases this character 0625 (UTF8: D8 A5)  will be converted to 
the sequence 0627 0655 (UTF8: D8 A7 D9 95).

This decomposition was introduced in Unicode 3.0. If there are processes that 
use decomposition according to Unicode 9 versus Unicode 2.x, or processes that 
don't decompose versus ones that do, then the filename bytes will be different.

- Peter E



___

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

How do I use a NSTextBlock in an attributed string?

2017-03-08 Thread Daryle Walker 
I tried:

> // Set the paragraph formatting for the body...
> let bodyAdvancement = bodyFont.maximumAdvancement
> let bodyIndent = max(bodyAdvancement.width, 
> bodyAdvancement.height) / 2.0
> let bodyParagraphStyle = NSParagraphStyle.default().mutableCopy() 
> as! NSMutableParagraphStyle
> bodyParagraphStyle.headIndent = bodyIndent
> bodyParagraphStyle.lineBreakMode = .byWordWrapping
> 
> // ...and separator
> let separatorParagraphStyle = bodyParagraphStyle.mutableCopy() 
> as! NSMutableParagraphStyle
> let separatorTextBlock = NSTextBlock()
> separatorParagraphStyle.textBlocks.append(separatorTextBlock)
> 
> // Set the body, but add a line for the initial separator
> let richSeparator = NSMutableAttributedString(string: " \n", 
> attributes: [NSFontAttributeName: bodyFont, NSParagraphStyleAttributeName: 
> separatorParagraphStyle])
> let richBody = NSMutableAttributedString(string: body, 
> attributes: [NSFontAttributeName: bodyFont, NSParagraphStyleAttributeName: 
> bodyParagraphStyle])
> result.append(richSeparator)
> result.append(richBody)

What I wanted: the separator line surrounded by a block.
What I got: the separator and the body all surrounded by a block.

I originally had the separator and body in a single string, and used a range to 
influence just the separator. This got the same result. I thought treating the 
separator and body in separate strings first wouldn’t infect the body with the 
text block, but it (illogically) does!

How do I end the influence of a block? Put -1 entries in the text-block array?

— 
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

Re: needsDisplay and subviews

2017-03-08 Thread Ben Kennedy 

> On 08 Mar 2017, at 8:46 am, Jeremy Hughes  wrote:
> 
> If needsDisplay is set to true for an NSView, does that also cause subviews 
> to be redrawn?

Admittedly I've been mostly doing iOS development for the last several years 
and barely any Mac lately, but, according to the current docs:

needsDisplay: "The displayIfNeeded methods check the value of this property to 
avoid unnecessary drawing, and all display methods set the value back to false 
when the view is up to date."

display(): "Displays the view and all its subviews if possible, invoking each 
of the NSView methods lockFocus(), draw(_:), and unlockFocus() as necessary."

Thus, it seems to follow that so long a custom view's display() calls super, 
then all of its subviews should also be drawn when its needsDisplay is true.

What sort of contradictions are out there?

b


___

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

needsDisplay and subviews

2017-03-08 Thread Jeremy Hughes 
If needsDisplay is set to true for an NSView, does that also cause subviews to 
be redrawn?

I’ve seen conflicting statements about this, but haven’t found anything in 
Apple’s documentation.

Jeremy


___

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: boundingRectForGlyphRange is very inaccurate

2017-03-08 Thread Ken Thomases 
On Mar 8, 2017, at 12:42 AM, Gerriet M. Denkmann  wrote:
> 
> Both boundingRectForGlyphRange and enumerateEnclosingRectsForGlyphRange are 
> right in the case of lines just containing Ascii chars.
> 
> But for more general cases (e.g. lines containing Thai chars) 
> boundingRectForGlyphRange is wrong and enumerateEnclosingRectsForGlyphRange 
> is still right.

It's not really about ASCII vs. Thai (or character sets in general), it's about 
the glyphs and whether they draw outside the line fragment rectangle.  For 
example, plenty of ASCII characters would if the font were Zapfino.

> Sorry for my flawed initial tests. And thanks a lot for your help!

You're welcome!  Glad I could help!

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