Re: Scroll views

[Jeremy Hughes]

Hi Quincey,

I saw Kyle Sluder’s post some time ago, but it’s quite old and I’m not sure how 
relevant it is now. My complaint about scroll views is not that they don’t 
work, but that they’re confusing and I struggle each time I use them. My 
initial email was an attempt to summarise what I’ve discovered (so that it 
might be easier next time) and perhaps elicit helpful insights.

One of the things I’ve discovered is that you don’t have to fight the 
auto-resizing constraints that Apple adds by default. If you’re using actual 
constraints further down the view hierarchy, it’s much better to add explicit 
constraints to the “document” view - in which case the autoresize mask is 
removed and you don’t need to worry about it. Or if you’re adding a view from a 
nib, you can turn off autoresizing for this view (in IB or in code).

Placeholder constraints are useful in situations where IB doesn’t know about 
constraints that are added in code or in other views.

The solution that I have is working fine. I’ve used similar solutions in the 
past, and they’ve also worked fine - on different macOSes and with different 
versions of Xcode. The “problem” is that it seems like I have to go through a 
process of trial and error to rediscover this solution on each occasion, so 
I’ve been trying to consolidate my experience.

What I’m doing in a nutshell is:

1. Add explicit constraints to the “document” view so that the leading and 
trailing edges are pinned to the superview (i.e. the clip view). This prevents 
horizontal scrolling. This is similar to using an autoresize mask with the 
horizontal lines/arrows turned on, except that autoresizing will also generate 
additional constraints that conflict with explicit constraints in subviews.

2. Add placeholder constraints for the top and bottom edges. These aren’t 
needed as actual constraints (because the height of the “document" view is 
determined by a subview that is added in code) but they’re required in order to 
keep IB from complaining about missing constraints.

Thanks to your emails, I do now have a clearer idea of how to use constraints 
between the clip view and “document” view. I’d figured out by trial and error 
that I should use a placeholder constraint for the bottom edge (to allow 
scrolling), but your comments also prompted me to use a placeholder constraint 
for the top edge. This "makes sense" because you don’t logically want the top 
edge to be pinned to the clip view. (Still, it’s curious that everything still 
works if the top constraint is not a placeholder.)

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: Scroll views

[Quincey Morris]

Well, I can’t figure out if IB supports your scenario in Xcode 9.2. In part, IB 
has some bugs in displaying the correct set of constraints error messages. In 
some cases, it displays errors for the wrong view; in some cases, it displays 
out-of-date messages until you rebuild the project, or close and re-open the 
project.

I did remember that Kyle Sluder had posted about this before, and I was able to 
track down this post here:


http://www.cocoabuilder.com/archive/cocoa/326783-guidelines-for-using-autolayout-with-nsscrollview.html#326786
 


The relevant text is:

> The biggest issue with using auto layout in an NSScrollView's document view 
> is that NSScrollView itself is completely unaware of auto layout. Thus, it 
> relies on the behavior provided by setting 
> translatesAutoresizingMaskIntoConstraints=YES on its subviews so it can 
> continue to use -setFrame: to position them even if auto layout is turned on 
> for the window.
> 
> At this point it's worth noting another difference between NSScrollView and 
> UIScrollView: UIScrollView directly manipulates its own bounds.origin to 
> perform scrolling of its entire subview hierarchy. The contentSize property 
> dictates the size of the scrollable region.
> 
> NSScrollView, on the other hand, doesn't actually do any scrolling on its 
> own: it delegates that responsibility to an NSClipView. The scroll view 
> positions the clip view and scrollers (if they are visible) using -setFrame:. 
> Rather than exposing a contentSize property, NSClipView observes the frame of 
> _one specific subview_ called its documentView. This view's frame.size 
> becomes the equivalent of UIScrollView's contentSize.
> 
> In order to perform scrolling correctly, the documentView's frame.origin must 
> lie at (0,0) in the clip view's bounds coordinate system. NSClipView, like 
> NSScrollView, is unaware of auto layout, so it uses -setFrameOrigin: to put 
> the document view at (0,0). If auto layout gets turned on for the window, 
> this position gets turned into a pair of constraints with a priority of 1000 
> (required).
> 
> Two more constraints will be synthesized to define the width and height of 
> the document view. These constraints are the problem. In either direction, 
> one of two kinds of constraints will be generated, depending on the 
> documentView's autoresizing mask for that direction:
> 
> 1. If the view is stretchable in that direction, a constraint will be 
> installed relating the opposing edge of the documentView to the edge of the 
> superview.
> 
> 2. If the view is not stretchable in that direction, a constraint will be 
> installed dictating the absolute value of the documentView's frame.size in 
> that dimension.
> 
> Like all autoresizing-mask constraints, these constraints are required 
> (priority 1000). Because the entire constraint system is solved at once, it 
> should be intuitive that any constraints that attempt to influence the size 
> of the documentView will conflict with either the constraints installed by 
> the clip view on the documentView and/or with the constraints installed by 
> the scroll view on the clip view.
> 
> So we have a dilemma. We need to somehow break the bidirectionality of the 
> relationship between the clip view and the documentView. There is no 
> straightforward way to express this using the constraints API, but it is 
> indeed possible without resorting to mucking with private internal details.
> 
> In other words, we want to somehow run layout of arbitrary constraints on our 
> documentView's subtree and retrieve the resultant frame of the documentView 
> without involving the documentView itself in our constraint system. Once we 
> have the right values, we can use -setFrameSize: on the documentView; the 
> clip view will notice and it will update its scrollable area.
> 
> The way we accomplish this is to install another view in our subtree and 
> define all our constraints relative to _that_ view. I'm going to call this 
> the adaptor view. The documentView installs constraints to keep the adaptor 
> view's top and leading margins equal to zero, but critically it does NOT 
> install any constraints on the trailing or bottom edges. This leaves the 
> adaptorView's width and height free to be defined by its content's layout.
> 
> The documentView signs up for frame change notifications from the adaptor 
> view. Whenever it changes its frame, the documentView calls [self 
> setFrameSize:] with the same size.  Then the clip view hears about this, and 
> the scroll view reflects the correct document size. For this to work, the 
> documentView's autoresizing mask should be set to width and height 
> NON-stretchable, that way when the clip view resizes (perhaps during window 
> dragging) it doesn't resize your documentView.
> 
> If you're laying out the contents of your scroll view in IB, the 

Re: Scroll views

[Jeremy Hughes]

> On 19 Jan 2018, at 22:15, Quincey Morris 
>  wrote:
> 
>> Interface Builder complains if I don’t also add vertical constraints, so 
>> I’ve done that, but made the bottom constraint into a placeholder (“Remove 
>> at build time”). Your email suggests that I can also make the top constraint 
>> into a placeholder. I’ve tried that now, and it seems to work fine. It also 
>> makes sense :)
> 
> Using placeholder constraints makes no sense to me.
> 
> First of all, you need to understand that in current versions of Xcode, IB 
> translates those resizing control arrows into constraints for you, unless you 
> add *explicit* constraints that it regards as overriding this “free” 
> translation. This means that those arrows are *not necessarily* honored. If 
> you’re getting messages about missing constraints, then that means you’ve 
> added some subview constraints that prevent the document view height 
> constraint from being inferred.

Once you add explicit constraints, IB turns off autoresizing altogether. The 
red arrows/lines disappear - there’s nothing there to be honoured or not 
honoured.

In my case, IB doesn’t know about the “document" height because it’s determined 
by a subview that is in a separate nib. That’s why I need to use placeholder 
constraints (otherwise IB complains about missing constraints). There are 
several subviews, and they are swapped in and out at runtime.

> — You don’t want IB to provide default constraints on the document view. You 
> should probably write code to remove any existing constraints from the 
> document view before you swap in new subviews. (Even if you turn off all the 
> arrows in the IB resize control, it’s not obvious to me that IB won’t add a 
> height constraint anyway.)

You don’t need to turn off the red arrows/lines because they disappear as soon 
as you add explicit constraints. Without autoresizing, IB doesn’t provide any 
default constraints. I don’t think you should ever have to remove default 
constraints in code - you should turn off autoresizing (in IB or in code) to 
prevent the default constraints from being created in the first place. 

I think I mentioned previously that constraints are added to the subviews at 
run time - and, yes, they are removed and recreated when subviews are swapped.

It is the subview that determines the width of the “document” view, so the 
horizontal (explicit) constraints pinning the “document” view to its superview 
are required. They perform the same task that the horizontal red arrows/lines 
do with autoresizing (prevent horizontal scrolling). I can’t use autoresizing 
here because it will create additional constraints that generate conflicts with 
subview constraints.

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: Scroll views

[Quincey Morris]

On Jan 19, 2018, at 12:36 , Jeremy Hughes  wrote:
> 
> If you add a scroll view in Interface Builder, that’s how it is set up for 
> you by Interface Builder. You don’t have to add an autoresizing mask or use 
> it to pin the document edges - because Apple has already done that for you! 
> So you’re confirming my view that it’s confusing.

IB doesn’t know what you intend, so this is a case where you do need to go in 
and change the settings to what you need. In this cases, there are 3 things to 
think about:

1. You need to constrain the NSScrollView to (usually) fill up the view it’s 
in. You can do this by turning on all 6 arrows inside the resize control in the 
inspector.

2. You can only edit the outer 4 arrows of the NSClipView but you generally 
shouldn’t change the default setting at all.

3. For a document view that scrolls vertically, turn on the 3 horizontal resize 
arrows, turn off the 3 vertical ones. (I was wrong before, you *do* have to 
turn on the center one. I believe this is different to how this worked in 
earlier versions of Xcode.)

Because of #3, the document view height is now whatever it’s created at in IB, 
which by default is the same size as the clip view. You must set it to whatever 
you really need, in IB or later in code.

For example, I created a project and put a scroll view inside the root content 
view. The default height was about 250, so I tried making the document view 500 
instead. By putting some subviews inside this document view, I was able to see 
that the view scrolled correctly when the app runs. Resizing the window did 
what seemed to be a reasonable thing (the top left visible pixel before the 
resize stayed at the top left of the visible rect during the resize).

All of this is exactly what I would expect, and you should be able to reproduce 
this behavior.

> I mentioned in my follow-up email that I need to use explicit constraints in 
> order to avoid conflicts between autoresize constraints and the constraints 
> I’m adding to a subview. In order to avoid horizontal scrolling I’ve added 
> explicit constraints to pin the left and right edges of the “document” view 
> to its superview.

Yep, that part is the same as #3 above.

> Interface Builder complains if I don’t also add vertical constraints, so I’ve 
> done that, but made the bottom constraint into a placeholder (“Remove at 
> build time”). Your email suggests that I can also make the top constraint 
> into a placeholder. I’ve tried that now, and it seems to work fine. It also 
> makes sense :)

Using placeholder constraints makes no sense to me.

First of all, you need to understand that in current versions of Xcode, IB 
translates those resizing control arrows into constraints for you, unless you 
add *explicit* constraints that it regards as overriding this “free” 
translation. This means that those arrows are *not necessarily* honored. If 
you’re getting messages about missing constraints, then that means you’ve added 
some subview constraints that prevent the document view height constraint from 
being inferred.

What you actually do about such messages depends on what size you want for the 
document view. 

— If you want a one-time fixed height, you should add an explicit height 
constraint. 

— If you want a fixed height (that is, not derived from the subviews by 
auto-layout) that changes at various times according to decisions made in code, 
you should add an explicit height constraint and modify the constraint at 
run-time. 

— If you want a height that is derived from the subviews, you need to add 
sufficient constraints within the document view, and between the document view 
and its child views, to satisfy auto-layout’s requirements. In this case, there 
should be *no* vertical constraints relating the document view to its superview.

If your application is swapping subviews into the document view at run-time, 
then you have a couple of points to remember:

— You don’t want IB to provide default constraints on the document view. You 
should probably write code to remove any existing constraints from the document 
view before you swap in new subviews. (Even if you turn off all the arrows in 
the IB resize control, it’s not obvious to me that IB won’t add a height 
constraint anyway.)

— The document view’s vertical auto-layout universe is self-contained. You need 
to ignore the clip view or any other ancestor views, but make sure you 
establish a complete set of vertical constraints between the document view and 
its children. Whether that resizes or preserves the document view height is up 
to you.

___

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 

Re: Scroll views

[Quincey Morris]

On Jan 19, 2018, at 04:28 , Jeremy Hughes  wrote:
> 
> Summarising: it seems that to get a vertically scrolling view that works as 
> expected, the content view must be set to be flipped (no way of doing this in 
> IB) and the flexible-height arrow must be turned off. The top-margin line can 
> also be turned off, but it actually makes no difference if it is on or off.
> 
> Does anyone have a way to make sense of this or is it just inherently 
> confusing?

In general, you should *not* use autoresizing masks on the document view, 
precisely because the point of a scroll view is that the document view’s size 
is *unrelated* to the size of the piece of window real estate (the clip view) 
in which it is displayed. This is made worse if you also use autoresizing masks 
to pin the document view’s edges to the clip view, because the point of 
scrolling is to change the position of the document view origin relative to the 
clip view origin. Pinning the origin just conflicts with that.

IOW, you should set the size of the document view absolutely, either one time 
initially or whenever the size needed to encompass the contents changes. You 
may or may not need to set the position of the document view relative to the 
clip view initially or whenever the document view size changes, depending on 
whether the default behavior is what you want.

All of that is true for using auto-layout constraints, too.

However, in the case of a view like a text view which (for horizontal writing 
systems) can wrap its contents to a fixed width, it’s common to pin the 
left/right edges of the document view to the left/right edges of the clip view. 
(In terms of the autoresizing control, that means turning on the outer arrows 
on the left and right sides, and turning off the inner horizontal arrow.) In 
that case, there is never any actual horizontal scrolling, because the two 
views are the same width.

So:

1. Don’t pin any of the edges of the document view to the clip view, except 
when you want the widths to match.

2. Set the height of the document view manually to the size that encompasses 
all of its scrollable content. You can do this one time in IB, one time in 
code, or whenever the needed size changes, depending on how your app works.

___

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

Scroll views and autolayout

[Jeremy Hughes]

This is a follow-up to my previous email on Scroll views.

What I actually want to is be able to swap different views (with different 
heights) in and out of the scroll view. To do this, I’m adding the different 
views as a subview of the “document" view (called contentParent below):

contentParent.subviews = [subview]

I then add constraints that pin the edges of this subview to the edges of its 
parent.

Unfortunately, this creates autolayout conflicts when autoresizing is used with 
contentParent, since the autoresizing mask has created a fixed height for 
contentParent, and this fails to match the height of the subview.

It seems that I can fix this by using autolayout on the document view 
(contentParent), so I’ve added constraints that pin the left, top, and right of 
contentParent to its superview. In order to keep IB happy I’ve also added a 
placeholder (“Remove at build time”) constraint that pins the bottom of 
contentParent to the bottom of its superview.

This seems to do what I want. I’m slightly concerned about the fact that the 
superview of contentParent is a clip view, because we don’t actually want the 
edges of contentParent to be pinned to the clip view (or it wouldn’t actually 
scroll within the clip view) - but I assume that there is some kind of magic 
that goes on behind the scenes when constraints are added to views that are 
enclosed within scroll/clip views (although I haven’t seen this discussed 
anywhere).

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

Scroll views

[Jeremy Hughes]

Does anyone understand scroll views? I struggle every time I use them, and it 
seems that I have to go through a process of trial and error to get them 
working properly.

If I drag a scroll view into another view in Interface Builder, I get a 
“Bordered Scroll View” that contains a “Clip View” that contains a “View” - 
which seems fine. The clip view will clip the content (“document”) view. So I 
can see what’s happening, I create a subclass for the document view, which 
looks like this (for debugging purposes):

class ContentView: NSView
{
//  override var isFlipped: Bool { return true }

override func draw(_ dirtyRect: NSRect)
{
super.draw(dirtyRect)

NSColor.red.set()
NSBezierPath.stroke(self.bounds)
}
}

isFlipped is commented out at this stage, but I’ve added it in case I need it 
later.

The document view’s class is set to ContentView in the Identity inspector in 
Interface Builder.

By default, Interface Builder gives the content/document view an autoresizing 
mask where all the red lines are turned on in the Size inspector - meaning that 
the width and height are flexible, and also (I think) that the margins are not 
flexible. What happens when I build and run without changing this is that the 
content view resizes to match the parent view - so the scroll view is 
completely redundant (nothing ever scrolls). That’s fine for horizontal 
scrolling, which I don’t want, but I do want to have vertical scrolling, so I 
turn off the adjustable height arrow.

What I now have is a view that scrolls vertically, but is pinned to the bottom 
of its parent view. Uncommenting isFlipped in ContentView fixes this problem, 
and I think everything is now working correctly. I’ve looked for a flipped 
setting in Interface Builder, but I haven’t found it, so I assume it’s missing 
for some reason that I don’t understand.

But there are other alternatives that seem confusing. Before turning on 
isFlipped in code, I tried turning off the bottom margin red line in Interface 
Builder. This gives me a view that is still pinned to the bottom of its parent 
view - but when the window is shrunk smaller than the height of the content 
view, the bottom rather than the top of the content view is scrolled out of 
view. If I turn isFlipped on at this point, I get a content view that is pinned 
to the top of its parent view (good), but when the window is shrunk smaller the 
top of the content view is scrolled out of view (not good). If I go back and 
turn the bottom red line back on and turn the top red line off (in IB), it 
works correctly.

Summarising: it seems that to get a vertically scrolling view that works as 
expected, the content view must be set to be flipped (no way of doing this in 
IB) and the flexible-height arrow must be turned off. The top-margin line can 
also be turned off, but it actually makes no difference if it is on or off.

Does anyone have a way to make sense of this or is it just inherently confusing?

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

Autolayout and Scroll Views?

[Dave]

Hi,

I’m trying to setup a Scroll View for Auto Layout, at the suggestion to someone 
on the list, I’m looking at:

http://natashatherobot.com/ios-autolayout-scrollview/

I have the following View Hierarchy setup in the Window NIB.

Window
Custom View
WindowHeaderView

Bordered Scroll View
Flipped Clip View
View
StackView
Scroller
Scroller

Currently I have no constraints setup, so I follow the above link to the “Equal 
Widths” section, I then select “Flipped Clip View” in XCode/IB and add the top, 
bottom, left, right constraints as shown. But then it says:

 “To create the Equal Width Constraint between the ContentView and the View, 
select the ContentView on the view hierarchy and Control + Drag to the View – 
you should get a pop-up that gives you the “Equal Widths” option:”

I’m confused as to how to do this, what do I control drag to what? I’ve tried 
selecting "Flipped Clip View” and Control Dragging it to "Bordered Scroll 
View”, but I don’t get the Pop Up Window as described in the link. How do I do 
this?

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: Auto layout and scroll views on OS X

[Allison Newman]

OK, I did eventually figure out my problem with Autolayout and scrollviews.  It 
turns out that I wasn’t setting up my scrollview constraints correctly in the 
storyboard (which is another way of saying I hadn’t set *any* size constraints 
on the scrollview’s frame).  So, I did eventually figure that out.  That’s not 
the important point though, the important point is that everything else Just 
Worked.  In other words, you no longer (as of 10.10) need to use Kyle’s tricks 
to make scroll views work as expected with AutoLayout.  I thought people might 
like to know.

So, Kyle, Keary, thanks for the help, it did help me eliminate potential 
problems, which helped me identify the true problem :)

Allison
___

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: Auto layout and scroll views on OS X

[Dave]

On 31 Jul 2014, at 11:52, Allison Newman demall...@mac.com wrote:

 OK, I did eventually figure out my problem with Autolayout and scrollviews.  
 It turns out that I wasn’t setting up my scrollview constraints correctly in 
 the storyboard (which is another way of saying I hadn’t set *any* size 
 constraints on the scrollview’s frame).  So, I did eventually figure that 
 out.  That’s not the important point though, the important point is that 
 everything else Just Worked.  In other words, you no longer (as of 10.10) 
 need to use Kyle’s tricks to make scroll views work as expected with 
 AutoLayout.  I thought people might like to know.
 
 So, Kyle, Keary, thanks for the help, it did help me eliminate potential 
 problems, which helped me identify the true problem :)
 
 Allison

Sadly it doesn’t help with this one though, cos there isn’t a Storyboard file 
and Auto Layout is disabled.

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

Auto layout and scroll views on OS X

[Allison Newman]

I have a simple application (zipped project can be found here: 
http://phonicnoise.com/UIsandbox.zip ) that generates two rows of square 
buttons.  The number of buttons is generated dynamically based on model data.  
The buttons plus spacing should take up the entire vertical space of their 
parent view, and the width adjusts accordingly (as buttons need to remain 
square, if you increase their height, the width has to increase as well).
   
Anyway, the application works just fine if I add the content directly into a 
window - resizing the window resizes the buttons.  But if I try to create a 
scrollview that takes up all of the window, and then place the content in the 
scroll view, nothing is drawn.  Instead I get the following error message:
  
 2014-07-21 12:29:33.382 UI sandbox[14370:2640458] Failed to set 
(contentViewController) user defined inspected property on (NSWindow): Unable 
to install constraint on view.  Does the constraint reference something from 
outside the subtree of the view?  That's illegal. 
constraint:NSLayoutConstraint:0x608832f0 V:|-(0)-[NSView:0x608000120d20]   
(Names: '|':NSClipView:0x1002077f0 ) view:NSView: 0x608000120d20
   
I have read the Auto layout programming guide,, and in particular the section 
concerning scrollviews, and I also looked up this tech note 
(https://developer.apple.com/library/ios/technotes/tn2154/_index.html) but 
neither really shed much light on the problem for me, and I didn’t find 
anything useful searching back through the history of cocoadev…
   
In the project code, I have a define that can be activated to switch between 
the scrollview / no scrollview configurations: PN_USING_SCROLLVIEW.
   
If anyone can point me in the right direction for sorting this out, that would 
be much appreciated!
   

Allison
___

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: Auto layout and scroll views on OS X

[Keary Suska]

On Jul 22, 2014, at 5:02 AM, Allison Newman demall...@mac.com wrote:

 I have a simple application (zipped project can be found here: 
 http://phonicnoise.com/UIsandbox.zip ) that generates two rows of square 
 buttons.  The number of buttons is generated dynamically based on model data. 
  The buttons plus spacing should take up the entire vertical space of their 
 parent view, and the width adjusts accordingly (as buttons need to remain 
 square, if you increase their height, the width has to increase as well).
 
 Anyway, the application works just fine if I add the content directly into a 
 window - resizing the window resizes the buttons.  But if I try to create a 
 scrollview that takes up all of the window, and then place the content in the 
 scroll view, nothing is drawn.  Instead I get the following error message:
 
 2014-07-21 12:29:33.382 UI sandbox[14370:2640458] Failed to set 
 (contentViewController) user defined inspected property on (NSWindow): Unable 
 to install constraint on view.  Does the constraint reference something from 
 outside the subtree of the view?  That's illegal. 
 constraint:NSLayoutConstraint:0x608832f0 V:|-(0)-[NSView:0x608000120d20] 
   (Names: '|':NSClipView:0x1002077f0 ) view:NSView: 0x608000120d20
 
 I have read the Auto layout programming guide,, and in particular the section 
 concerning scrollviews, and I also looked up this tech note 
 (https://developer.apple.com/library/ios/technotes/tn2154/_index.html) but 
 neither really shed much light on the problem for me, and I didn’t find 
 anything useful searching back through the history of cocoadev…
 
 In the project code, I have a define that can be activated to switch between 
 the scrollview / no scrollview configurations: PN_USING_SCROLLVIEW.
 
 If anyone can point me in the right direction for sorting this out, that 
 would be much appreciated!

Based on the error it looks like a Mac OS X project, but if not, please always 
specify because there isn't complete feature parity with iOS. So, for Mac OS X, 
auto layout is broken for NSScrollViews. Perhaps this will change in 10.10.

The only advice I have found, which I have not yet been able to utilize 
successfully but might still be useful advice:

http://www.cocoabuilder.com/archive/cocoa/326783-guidelines-for-using-autolayout-with-nsscrollview.html
http://www.cocoabuilder.com/archive/cocoa/326788-ambiguous-layout-for-documentview-in-nsscrollview.html

HTH,

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


___

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

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

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

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

Re: Auto layout and scroll views on OS X

[Kyle Sluder]

On Jul 22, 2014, at 7:13 AM, Keary Suska cocoa-...@esoteritech.com wrote:
 
 Based on the error it looks like a Mac OS X project, but if not, please 
 always specify because there isn't complete feature parity with iOS.

Allison did put “OS X” in the subject line.

 So, for Mac OS X, auto layout is broken for NSScrollViews. Perhaps this will 
 change in 10.10.

Auto Layout should work fine with scroll views in 10.9, in much the same way as 
it does in iOS.

The key difference is that on OS X, your interior constraints need to be set up 
relative to the clip view, not the scroll view itself. That means you need to 
upgrade your XIBs to the new Xcode 5 format, because older formats don’t expose 
the clip view object.

--Kyle Sluder

___

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: Auto layout and scroll views on OS X

[Keary Suska]

On Jul 22, 2014, at 10:59 AM, Kyle Sluder k...@ksluder.com wrote:

 On Jul 22, 2014, at 7:13 AM, Keary Suska cocoa-...@esoteritech.com wrote:
 
 Based on the error it looks like a Mac OS X project, but if not, please 
 always specify because there isn't complete feature parity with iOS.
 
 Allison did put “OS X” in the subject line.

Sorry my bad--didn't notice.

 So, for Mac OS X, auto layout is broken for NSScrollViews. Perhaps this will 
 change in 10.10.
 
 Auto Layout should work fine with scroll views in 10.9, in much the same way 
 as it does in iOS.

Listen to Kyle. He knows best.

 The key difference is that on OS X, your interior constraints need to be set 
 up relative to the clip view, not the scroll view itself. That means you need 
 to upgrade your XIBs to the new Xcode 5 format, because older formats don’t 
 expose the clip view object.

Did they also fix auto layout for split views? I was thinking it was split 
views that were fixed in 10.9 but not scroll views, but I could have that 
backwards, and also be a version behind.

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


___

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

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

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

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

Re: Auto layout and scroll views on OS X

[Kyle Sluder]

On Jul 22, 2014, at 7:38 PM, Keary Suska cocoa-...@esoteritech.com wrote:
 
 Did they also fix auto layout for split views? I was thinking it was split 
 views that were fixed in 10.9 but not scroll views, but I could have that 
 backwards, and also be a version behind.

Yeah, I think split views were fixed in 10.8. (But subsequent releases, 
including Yosemite, still have some refinements.)

--Kyle Sluder 

___

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

Keeping Scroll Views in Sync

[Dave]

Hi,

I've got a number of scroll views (A, B and C) I'm trying to keep in sync with 
each other, e.g. if the user scrolls A then I want B and C to scroll in sync 
with it. I've got this working by adding code in the scrollViewDidScroll method 
that passes the contentOffset onto the other two scroll views.

This works ok, but it is judders a bit and flickers when scrolling quickly.

This is the code:

- (void) scrollViewDidScroll:(LTWScrollView*) theScrollView
{
if (theScrollView.tag == kScrollViewA)
{
self.scrollViewB.contentOffset = theScrollView.contentOffset;
self.scrollViewC.contentOffset = theScrollView.contentOffset;
}

else if (theScrollView.tag == kScrollViewB)
{
self.scrollViewA.contentOffset = theScrollView.contentOffset;
self.scrollViewC.contentOffset = theScrollView.contentOffset;
}
else if (theScrollView.tag == kScrollViewC)
{
self.scrollViewA.contentOffset = theScrollView.contentOffset;
self.scrollViewB.contentOffset = theScrollView.contentOffset;
}
}

I've tried a few things, but nothing seem to make a difference.

Any ideas anyone?

Thanks a lot
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: Keeping Scroll Views in Sync

[Tamas Nagy]

Hi,

in one of my apps I'm doing this too, but without any problems. I'm using 
scrollToPoint: method instead.

[[NSNotificationCenter defaultCenter] addObserver:self
 
selector:@selector(viewScrolled:)
 
name:NSViewBoundsDidChangeNotification
   object:[[self 
timelineViewScrollView] contentView]];

…


-(void)viewScrolled:(NSNotification *)notification {


if ([[notification object] isEqualTo:[[self timelineViewScrollView] 
contentView]]) {


[[[self trackHelperViewScrollView] contentView] 
scrollToPoint:NSMakePoint([[[self trackHelperViewScrollView] contentView] 
bounds].origin.x, [[[self timelineViewScrollView] contentView] 
bounds].origin.y)];

[[[self markerViewScrollView] contentView] 
scrollToPoint:NSMakePoint([[[self timelineViewScrollView] contentView] 
bounds].origin.x, [[[self markerViewScrollView] contentView] bounds].origin.y)];


} else

.
.
.
.

Cheers,
Tamas

On Oct 9, 2013, at 3:44 PM, Dave d...@looktowindward.com wrote:

 Hi,
 
 I've got a number of scroll views (A, B and C) I'm trying to keep in sync 
 with each other, e.g. if the user scrolls A then I want B and C to scroll in 
 sync with it. I've got this working by adding code in the scrollViewDidScroll 
 method that passes the contentOffset onto the other two scroll views.
 
 This works ok, but it is judders a bit and flickers when scrolling quickly.
 
 This is the code:
 
 - (void) scrollViewDidScroll:(LTWScrollView*) theScrollView
 {
 if (theScrollView.tag == kScrollViewA)
   {
   self.scrollViewB.contentOffset = theScrollView.contentOffset;
   self.scrollViewC.contentOffset = theScrollView.contentOffset;
   }
 
 else if (theScrollView.tag == kScrollViewB)
   {
   self.scrollViewA.contentOffset = theScrollView.contentOffset;
   self.scrollViewC.contentOffset = theScrollView.contentOffset;
   }
 else if (theScrollView.tag == kScrollViewC)
   {
   self.scrollViewA.contentOffset = theScrollView.contentOffset;
   self.scrollViewB.contentOffset = theScrollView.contentOffset;
   }
 }
 
 I've tried a few things, but nothing seem to make a difference.
 
 Any ideas anyone?
 
 Thanks a lot
 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/tamas.lov.nagy%40gmail.com
 
 This email sent to tamas.lov.n...@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: Keeping Scroll Views in Sync

[Damian Carrillo]

Dave,

Try the following: 

- (void) scrollViewDidScroll:(LTWScrollView*) theScrollView
{
if (theScrollView.tag == kScrollViewA)
{
[self.scrollViewB setContentOffset:theScrollView.contentOffset 
animated:NO];
[self.scrollViewC setContentOffset:theScrollView.contentOffset 
animated:NO];
}
else if (theScrollView.tag == kScrollViewB)
{
[self.scrollViewA setContentOffset:theScrollView.contentOffset 
animated:NO];
[self.scrollViewC setContentOffset:theScrollView.contentOffset 
animated:NO];
}
else if (theScrollView.tag == kScrollViewC)
{
[self.scrollViewA setContentOffset:theScrollView.contentOffset 
animated:NO];
[self.scrollViewB setContentOffset:theScrollView.contentOffset 
animated:NO];
}
}

It may help.

Damian

On Oct 9, 2013, at 8:44 AM, Dave d...@looktowindward.com wrote:

 Hi,
 
 I've got a number of scroll views (A, B and C) I'm trying to keep in sync 
 with each other, e.g. if the user scrolls A then I want B and C to scroll in 
 sync with it. I've got this working by adding code in the scrollViewDidScroll 
 method that passes the contentOffset onto the other two scroll views.
 
 This works ok, but it is judders a bit and flickers when scrolling quickly.
 
 This is the code:
 
 - (void) scrollViewDidScroll:(LTWScrollView*) theScrollView
 {
 if (theScrollView.tag == kScrollViewA)
   {
   self.scrollViewB.contentOffset = theScrollView.contentOffset;
   self.scrollViewC.contentOffset = theScrollView.contentOffset;
   }
 
 else if (theScrollView.tag == kScrollViewB)
   {
   self.scrollViewA.contentOffset = theScrollView.contentOffset;
   self.scrollViewC.contentOffset = theScrollView.contentOffset;
   }
 else if (theScrollView.tag == kScrollViewC)
   {
   self.scrollViewA.contentOffset = theScrollView.contentOffset;
   self.scrollViewB.contentOffset = theScrollView.contentOffset;
   }
 }
 
 I've tried a few things, but nothing seem to make a difference.
 
 Any ideas anyone?
 
 Thanks a lot
 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/damiancarrillo%40me.com
 
 This email sent to damiancarri...@me.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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: Keeping Scroll Views in Sync

[Dave]

Hi,

I should have said, this is for iOS and it doesn't look like UIScrollView has 
the scrollToPoint method defined.

There is also something about using notifications for this in a Mac Reference:

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/NSScrollViewGuide/Articles/SynchroScroll.html

But I'm not sure if this is recommended for iOS?

Thanks a lot
Dave

On 9 Oct 2013, at 14:52, Tamas Nagy tamas.lov.n...@gmail.com wrote:

 Hi,
 
 in one of my apps I'm doing this too, but without any problems. I'm using 
 scrollToPoint: method instead.
 
 [[NSNotificationCenter defaultCenter] addObserver:self
  
 selector:@selector(viewScrolled:)
  
 name:NSViewBoundsDidChangeNotification
object:[[self 
 timelineViewScrollView] contentView]];
 
 …
 
 
 -(void)viewScrolled:(NSNotification *)notification {
 
 
 if ([[notification object] isEqualTo:[[self timelineViewScrollView] 
 contentView]]) {
 
 
 [[[self trackHelperViewScrollView] contentView] 
 scrollToPoint:NSMakePoint([[[self trackHelperViewScrollView] contentView] 
 bounds].origin.x, [[[self timelineViewScrollView] contentView] 
 bounds].origin.y)];
 
 [[[self markerViewScrollView] contentView] 
 scrollToPoint:NSMakePoint([[[self timelineViewScrollView] contentView] 
 bounds].origin.x, [[[self markerViewScrollView] contentView] 
 bounds].origin.y)];
 
 
 } else
 
 .
 .
 .
 .
 
 Cheers,
 Tamas
 
 On Oct 9, 2013, at 3:44 PM, Dave d...@looktowindward.com wrote:
 
 Hi,
 
 I've got a number of scroll views (A, B and C) I'm trying to keep in sync 
 with each other, e.g. if the user scrolls A then I want B and C to scroll in 
 sync with it. I've got this working by adding code in the 
 scrollViewDidScroll method that passes the contentOffset onto the other two 
 scroll views.
 
 This works ok, but it is judders a bit and flickers when scrolling quickly.
 
 This is the code:
 
 - (void) scrollViewDidScroll:(LTWScrollView*) theScrollView
 {
 if (theScrollView.tag == kScrollViewA)
  {
  self.scrollViewB.contentOffset = theScrollView.contentOffset;
  self.scrollViewC.contentOffset = theScrollView.contentOffset;
  }
 
 else if (theScrollView.tag == kScrollViewB)
  {
  self.scrollViewA.contentOffset = theScrollView.contentOffset;
  self.scrollViewC.contentOffset = theScrollView.contentOffset;
  }
 else if (theScrollView.tag == kScrollViewC)
  {
  self.scrollViewA.contentOffset = theScrollView.contentOffset;
  self.scrollViewB.contentOffset = theScrollView.contentOffset;
  }
 }
 
 I've tried a few things, but nothing seem to make a difference.
 
 Any ideas anyone?
 
 Thanks a lot
 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/tamas.lov.nagy%40gmail.com
 
 This email sent to tamas.lov.n...@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: Keeping Scroll Views in Sync

[Dave]

Hi,

This works really well, but of course there is no inertia/deceleration which 
feels a bit strange and I'm willing to bet marketing won't like it!

I'm still playing about trying to get it to work. When you couple this with the 
Infinite Scroll View I've been working on, you get some very interesting 
results!!

Thanks a lot
Dave

On 9 Oct 2013, at 16:29, Damian Carrillo damiancarri...@me.com wrote:

 Dave,
 
 Try the following: 
 
 - (void) scrollViewDidScroll:(LTWScrollView*) theScrollView
 {
 if (theScrollView.tag == kScrollViewA)
   {
   [self.scrollViewB setContentOffset:theScrollView.contentOffset 
 animated:NO];
   [self.scrollViewC setContentOffset:theScrollView.contentOffset 
 animated:NO];
   }
 else if (theScrollView.tag == kScrollViewB)
   {
   [self.scrollViewA setContentOffset:theScrollView.contentOffset 
 animated:NO];
   [self.scrollViewC setContentOffset:theScrollView.contentOffset 
 animated:NO];
   }
 else if (theScrollView.tag == kScrollViewC)
   {
   [self.scrollViewA setContentOffset:theScrollView.contentOffset 
 animated:NO];
   [self.scrollViewB setContentOffset:theScrollView.contentOffset 
 animated:NO];
   }
 }
 
 It may help.
 
 Damian
 
 On Oct 9, 2013, at 8:44 AM, Dave d...@looktowindward.com wrote:
 
 Hi,
 
 I've got a number of scroll views (A, B and C) I'm trying to keep in sync 
 with each other, e.g. if the user scrolls A then I want B and C to scroll in 
 sync with it. I've got this working by adding code in the 
 scrollViewDidScroll method that passes the contentOffset onto the other two 
 scroll views.
 
 This works ok, but it is judders a bit and flickers when scrolling quickly.
 
 This is the code:
 
 - (void) scrollViewDidScroll:(LTWScrollView*) theScrollView
 {
 if (theScrollView.tag == kScrollViewA)
  {
  self.scrollViewB.contentOffset = theScrollView.contentOffset;
  self.scrollViewC.contentOffset = theScrollView.contentOffset;
  }
 
 else if (theScrollView.tag == kScrollViewB)
  {
  self.scrollViewA.contentOffset = theScrollView.contentOffset;
  self.scrollViewC.contentOffset = theScrollView.contentOffset;
  }
 else if (theScrollView.tag == kScrollViewC)
  {
  self.scrollViewA.contentOffset = theScrollView.contentOffset;
  self.scrollViewB.contentOffset = theScrollView.contentOffset;
  }
 }
 
 I've tried a few things, but nothing seem to make a difference.
 
 Any ideas anyone?
 
 Thanks a lot
 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/damiancarrillo%40me.com
 
 This email sent to damiancarri...@me.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: Layer-hosting views and layer-backed scroll views

[Kyle Sluder]

On Mon, May 24, 2010 at 2:24 PM, Kyle Sluder kyle.slu...@gmail.com wrote:
 At this point, I don't think there's anything further I can do to work
 around this bug.

Well, Tim Wood gave me the idea to call -_updateLayerGeometryFromView
in an override of -viewWillDraw. This does the trick, and avoids the
single frame flicker of the layer in the wrong spot. So I think it's
as good as I'm going to get for now. I don't know if this workaround
works on 10.5, since -viewWillDraw is documented to not be called in
many cases of non-traditional drawing. But since we've publicly
announced that all new major versions of our apps will be 10.6-only, I
really don't care.

I do hope someone at Apple takes the time to fix this bug, and I hope
my workaround holds up.

--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Layer-hosting views and layer-backed scroll views

[Kyle Sluder]

On Fri, May 21, 2010 at 3:20 PM, Kyle Sluder kyle.slu...@gmail.com wrote:
 I'm hoping I've done something wrong in setting up the layer. Is it
 perhaps because of the way I've turned off the redraw policy and set
 the layer resizing behavior? The documentation seems to imply that I
 have done the correct thing (setting the resize independently
 behavior and turning off layer redraw).

Nothing I do to -setLayerContentsPlacement: and/or
-setLayerContentsRedrawPolicy: (including doing nothing at all) is
able to fix the issue. The only thing I've gotten to work is to do a
delay-perform of -_updateLayerGeometryFromView, wrapped in a
CATransaction whose disableActions=YES. Even then, results are
suboptimal since the layer starts out positioned incorrectly and snaps
into the right spot on the next window refresh.

At this point, I don't think there's anything further I can do to work
around this bug.

--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Layer-hosting views and layer-backed scroll views

[Troy Stephens]

Hi Kyle,

On May 20, 2010, at 12:12 PM, Kyle Sluder wrote:
 On Thu, May 20, 2010 at 9:52 AM, Kyle Sluder kyle.slu...@gmail.com wrote:
 I have uploaded a sample project to
 http://www.lanechng.com/ScrolledLayerHostingView.zip. Resize the
 window to see the problem in action; then click one of the scroll
 arrows to see it fix itself.
 
 Well, I've filed rdar://problem/8009542 with this demo project
 attached. I've also been informed that IKImageBrowserView isn't
 flipped, perhaps because of this very same issue. It's also the only
 class besides NSView to implement _updateLayerGeometryFromView.
 Needless to say, I'm more than a little suspicious that scroll views
 are just plain broken.
 
 --Kyle Sluder

CALayers don't support the same notion of flippedness that NSView's geometry 
model uses.  (CALayer's geometryFlipped property is recursive in its effect, 
so isn't semantically identical.)

Therefore, whenever AppKit resizes the backing layer of a flipped NSView, we 
have to compute and assign new position values for its sublayers, to keep 
them in the same place relative to the top left.  (Don't count on this not 
changing in a future release, but for debugging purposes you can look for 
-_updateSublayerPositionsForFlippedSuperview, which gets invoked from 
-setFrameSize:)

We do this for sublayers that we created and therefore consider ourselves to 
own, but in your test app you're instantiating and assigning a layer of your 
own to the documentView.  Therefore, when we resize the ClipView's backing 
layer (and the ClipView is flipped, because it always matches the flippedness 
of the ScrollView's documentView), we don't touch the position of your 
documentView's layer.  (If you modify your example to omit the custom layer 
creation and -setLayer:, and instead override -drawRect: to draw your content 
into the view's AppKit-provided backing layer, you'll see the problem goes 
away.)

Arguably it would actually be OK for us to modify the layer's position in this 
case (and clearly our hands off policy isn't quite consistent about this, 
since, as you noted, scrolling will fix the incorrect document layer 
position).

Meanwhile, the simplest solution, if you require a custom backing layer, is to 
override NSView's -makeBackingLayer method (added in 10.6) to instantiate and 
return your (autoreleased) layer.  When layer instantiation goes through this 
path, AppKit considers the layer AppKit-owned, so you won't run into the 
positioning problem.

By the way: I don't know whether CAGradientLayer disregards -setNeedsDisplay 
(since the layer renders its content programmatically), possibly making this 
irrelevant in practice, but in cases like this, where you provide a layer of 
your own that already has content, and you don't want AppKit to ever invoke the 
view's -drawRect: to draw view content into the layer, it's a good idea to 
-setLayerContentsRedrawPolicy:NSViewLayerContentsRedrawNever on the view.

Troy Stephens
AppKit

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Layer-hosting views and layer-backed scroll views

[David Duncan]

On May 21, 2010, at 10:37 AM, Troy Stephens wrote:

 By the way: I don't know whether CAGradientLayer disregards -setNeedsDisplay 
 (since the layer renders its content programmatically), possibly making this 
 irrelevant in practice, but in cases like this, where you provide a layer of 
 your own that already has content, and you don't want AppKit to ever invoke 
 the view's -drawRect: to draw view content into the layer, it's a good idea 
 to -setLayerContentsRedrawPolicy:NSViewLayerContentsRedrawNever on the view.


The CAGradientLayer (and the CAShapeLayer) both respect -setNeedsDisplay and go 
through the normal CG drawing path, so it would definitely be recommended to 
specify the never redraw policy.
--
David Duncan
Apple DTS Animation and Printing

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Layer-hosting views and layer-backed scroll views

[Kyle Sluder]

On Fri, May 21, 2010 at 10:37 AM, Troy Stephens tsteph...@apple.com wrote:
 CALayers don't support the same notion of flippedness that NSView's 
 geometry model uses.  (CALayer's geometryFlipped property is recursive in 
 its effect, so isn't semantically identical.)

Hmm. Perhaps instead of using geometryFlipped on our layer, we should
manually calculate the bounds rectangle as appropriate? Or would
setting the anchor point to (0,1) suffice? Basically, we want to lay
out our contents like a text view would, which means that we want our
first row of stuff (which is contained in a child layer) to appear at
the upper left of the view, which should be at (0,0) in the layer's
bounds coordinate space.

 Therefore, whenever AppKit resizes the backing layer of a flipped NSView, we 
 have to compute and assign new position values for its sublayers, to keep 
 them in the same place relative to the top left.  (Don't count on this not 
 changing in a future release, but for debugging purposes you can look for 
 -_updateSublayerPositionsForFlippedSuperview, which gets invoked from 
 -setFrameSize:)

 We do this for sublayers that we created and therefore consider ourselves to 
 own, but in your test app you're instantiating and assigning a layer of 
 your own to the documentView.  Therefore, when we resize the ClipView's 
 backing layer (and the ClipView is flipped, because it always matches the 
 flippedness of the ScrollView's documentView), we don't touch the position of 
 your documentView's layer.  (If you modify your example to omit the custom 
 layer creation and -setLayer:, and instead override -drawRect: to draw your 
 content into the view's AppKit-provided backing layer, you'll see the problem 
 goes away.)

Indeed it does. :) I had tested that, and was actually contemplating
adding a button to toggle that behavior, but I wound up heading down
the road of rewrite NSScrollView using CAScrollLayer instead.

 Arguably it would actually be OK for us to modify the layer's position in 
 this case (and clearly our hands off policy isn't quite consistent about 
 this, since, as you noted, scrolling will fix the incorrect document layer 
 position).

The inconsistency is what's so maddening. I thought I had just failed
to do something on initialization.

 Meanwhile, the simplest solution, if you require a custom backing layer, is 
 to override NSView's -makeBackingLayer method (added in 10.6) to instantiate 
 and return your (autoreleased) layer.  When layer instantiation goes through 
 this path, AppKit considers the layer AppKit-owned, so you won't run into the 
 positioning problem.

I can't believe we've overlooked this method. We do, however, need to
resize the layer vertically as our document grows/shrinks, and we need
it to always be at least as high as the visible area of the scroll
view. Does this have the same potential for conflict with AppKit's
layer resizing? (Or perhaps if we just resize the view to the
appropriate size, this entire question just goes away. But that can't
be right, it doesn't involve impossible contortions and overriding
private methods! grin)

 By the way: I don't know whether CAGradientLayer disregards -setNeedsDisplay 
 (since the layer renders its content programmatically), possibly making this 
 irrelevant in practice, but in cases like this, where you provide a layer of 
 your own that already has content, and you don't want AppKit to ever invoke 
 the view's -drawRect: to draw view content into the layer, it's a good idea 
 to -setLayerContentsRedrawPolicy:NSViewLayerContentsRedrawNever on the view.

The CAGradientLayer is a red herring that I was using to visually
establish which end of the layer was up.

You and David have been thoroughly amazing with your help. Thanks so much!

--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Layer-hosting views and layer-backed scroll views

[Troy Stephens]

On May 21, 2010, at 10:52 AM, Kyle Sluder wrote:
 On Fri, May 21, 2010 at 10:37 AM, Troy Stephens tsteph...@apple.com wrote:
 CALayers don't support the same notion of flippedness that NSView's 
 geometry model uses.  (CALayer's geometryFlipped property is recursive in 
 its effect, so isn't semantically identical.)
 
 Hmm. Perhaps instead of using geometryFlipped on our layer, we should
 manually calculate the bounds rectangle as appropriate? Or would
 setting the anchor point to (0,1) suffice? Basically, we want to lay
 out our contents like a text view would, which means that we want our
 first row of stuff (which is contained in a child layer) to appear at
 the upper left of the view, which should be at (0,0) in the layer's
 bounds coordinate space.

You can use geometryFlipped on your documentView's layer for this purpose, if 
and only if your documentView isn't going to have any subviews.  If you control 
all the content (build it out of your own layers) from there on down, you're 
OK.  If AppKit has to position subview backing layers within the documentView's 
layer, it won't take the geometryFlipped setting into account and the 
positioning won't turn out right.

You should never modify the anchorPoint of a view backing layer.  If you modify 
your code to override -makeBackingLayer, AppKit will set the returned layer's 
anchorPoint automatically the way it wants it (to (0,1) if the superview is 
flipped, or (0,0) if the superview is unflipped).

 Therefore, whenever AppKit resizes the backing layer of a flipped NSView, we 
 have to compute and assign new position values for its sublayers, to keep 
 them in the same place relative to the top left.  (Don't count on this not 
 changing in a future release, but for debugging purposes you can look for 
 -_updateSublayerPositionsForFlippedSuperview, which gets invoked from 
 -setFrameSize:)
 
 We do this for sublayers that we created and therefore consider ourselves to 
 own, but in your test app you're instantiating and assigning a layer of 
 your own to the documentView.  Therefore, when we resize the ClipView's 
 backing layer (and the ClipView is flipped, because it always matches the 
 flippedness of the ScrollView's documentView), we don't touch the position 
 of your documentView's layer.  (If you modify your example to omit the 
 custom layer creation and -setLayer:, and instead override -drawRect: to 
 draw your content into the view's AppKit-provided backing layer, you'll see 
 the problem goes away.)
 
 Indeed it does. :) I had tested that, and was actually contemplating
 adding a button to toggle that behavior, but I wound up heading down
 the road of rewrite NSScrollView using CAScrollLayer instead.

There should be no need for that.  Just change your backing layer instantiation 
to user -makeBackingLayer.

 Arguably it would actually be OK for us to modify the layer's position in 
 this case (and clearly our hands off policy isn't quite consistent about 
 this, since, as you noted, scrolling will fix the incorrect document layer 
 position).
 
 The inconsistency is what's so maddening. I thought I had just failed
 to do something on initialization.

We'll look at improving the consistency of this behavior.

 Meanwhile, the simplest solution, if you require a custom backing layer, is 
 to override NSView's -makeBackingLayer method (added in 10.6) to instantiate 
 and return your (autoreleased) layer.  When layer instantiation goes through 
 this path, AppKit considers the layer AppKit-owned, so you won't run into 
 the positioning problem.
 
 I can't believe we've overlooked this method. We do, however, need to
 resize the layer vertically as our document grows/shrinks, and we need
 it to always be at least as high as the visible area of the scroll
 view. Does this have the same potential for conflict with AppKit's
 layer resizing? (Or perhaps if we just resize the view to the
 appropriate size, this entire question just goes away. But that can't
 be right, it doesn't involve impossible contortions and overriding
 private methods! grin)

Once you're using -makeBackingLayer, just size the documentView the way you 
want it, and let AppKit automatically resize the layer to match.

For document view should always be at least as big as the clip area behavior, 
you'll want to monitor the ClipView for size changes, and resize the 
documentView as desired in response.

 By the way: I don't know whether CAGradientLayer disregards -setNeedsDisplay 
 (since the layer renders its content programmatically), possibly making this 
 irrelevant in practice, but in cases like this, where you provide a layer of 
 your own that already has content, and you don't want AppKit to ever invoke 
 the view's -drawRect: to draw view content into the layer, it's a good idea 
 to -setLayerContentsRedrawPolicy:NSViewLayerContentsRedrawNever on the view.
 
 The CAGradientLayer is a red herring that I was using to visually
 establish which end of the layer was up.
 
 You 

Re: Layer-hosting views and layer-backed scroll views

[Kyle Sluder]

On Fri, May 21, 2010 at 11:06 AM, Troy Stephens tsteph...@apple.com wrote:
 You can use geometryFlipped on your documentView's layer for this purpose, if 
 and only if your documentView isn't going to have any subviews.  If you 
 control all the content (build it out of your own layers) from there on down, 
 you're OK.  If AppKit has to position subview backing layers within the 
 documentView's layer, it won't take the geometryFlipped setting into account 
 and the positioning won't turn out right.

We're already following David's advice and putting our field editors
in a companion layer-backed view that is a peer of our document view
(but whose layer we don't disturb). But it was briefly funny when
field editors would appear upside down and at the opposite end of the
document from the content they were editing. :)

 You should never modify the anchorPoint of a view backing layer.  If you 
 modify your code to override -makeBackingLayer, AppKit will set the returned 
 layer's anchorPoint automatically the way it wants it (to (0,1) if the 
 superview is flipped, or (0,0) if the superview is unflipped).

Hmm. Are we free to move the bounds origin, though? We always want to
put the layer's bounds origin at the upper left, and for one instance
of this view we want to inset the origin by about 20px. This has
wreaked havoc with AppKit's custom layer content provider (which
apparently maps layer positions directly to CGImageSource points for
the purposes of calling -drawRect:, and has trouble when either
coordinate is negative). The result was a black 20px-wide stripe down
the left side of the view.

We did solve this at one point (when we were still abusing
layer-backed drawing) by turning off drawsBackground on the scroll
view, and inserting a custom sublayer with a background color. Then
AppKit's image source isn't invoked at all (or if it is, it doesn't
draw anything, and then our sublayer draws on top of it). I suppose if
I return my own layer from -makeBackingLayer, then AppKit won't attach
its image source since it won't be trying to hook up the -drawRect:
rendering path?

 Arguably it would actually be OK for us to modify the layer's position in 
 this case (and clearly our hands off policy isn't quite consistent about 
 this, since, as you noted, scrolling will fix the incorrect document 
 layer position).

 The inconsistency is what's so maddening. I thought I had just failed
 to do something on initialization.

 We'll look at improving the consistency of this behavior.

Thanks.

 Once you're using -makeBackingLayer, just size the documentView the way you 
 want it, and let AppKit automatically resize the layer to match.

If AppKit does in fact try to attach an image source to the layer
returned by -makeBackingLayer, then we need to match our
background-fill sublayer's size, but that's made a heck of a lot
easier by being able to return a layer with a custom
-resizeSublayersWithOldSize: implementation. Or, at the very worst,
our background-fill layer could listen for bounds KVO from the
view-backing layer.

--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Layer-hosting views and layer-backed scroll views

[Kyle Sluder]

On Fri, May 21, 2010 at 11:06 AM, Troy Stephens tsteph...@apple.com wrote:
 Sure.  Let us know if you run into further difficulty with this.

Unfortunately I have indeed hit more difficulty.  I've attached an
updated demo project to the Radar as well as uploaded it to
http://www.lanechng.com/ScrolledLayerHostingView.zip , and despite (I
believe) correctly handing over the layer to AppKit, it still has the
repositioning problem.

Instructions to trigger it:

1. Open the app.
2. Scroll the document around such that the scrollers are left at a
non-zero position.
3. Save the document.
4. Close the document.
5. Reopen the document.

The layer will be positioned incorrectly. :(

I'm hoping I've done something wrong in setting up the layer. Is it
perhaps because of the way I've turned off the redraw policy and set
the layer resizing behavior? The documentation seems to imply that I
have done the correct thing (setting the resize independently
behavior and turning off layer redraw).

Thanks,
--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Layer-hosting views and layer-backed scroll views

[Kyle Sluder]

We have a layer-hosting document view that is contained in a
layer-backed scroll view. We have noticed that the scroll view does
some funky stuff to the layer if the view's -isFlipped returns YES.
This manifests itself in our app in the form of our document view
being scrolled by the correct amount but in the wrong direction at
startup. Everything gets fixed if the user scrolls the document.

Is there a known bug with NSScrollView and layer-hosting views? It
looks like NSClipView's implementation of
-_updateLayerGeometryFromView is at fault here. It is not being called
to correctly position the document view's layer within the clip view.

I have uploaded a sample project to
http://www.lanechng.com/ScrolledLayerHostingView.zip. Resize the
window to see the problem in action; then click one of the scroll
arrows to see it fix itself.

--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Layer-hosting views and layer-backed scroll views

[Kyle Sluder]

On Thu, May 20, 2010 at 9:52 AM, Kyle Sluder kyle.slu...@gmail.com wrote:
 I have uploaded a sample project to
 http://www.lanechng.com/ScrolledLayerHostingView.zip. Resize the
 window to see the problem in action; then click one of the scroll
 arrows to see it fix itself.

Well, I've filed rdar://problem/8009542 with this demo project
attached. I've also been informed that IKImageBrowserView isn't
flipped, perhaps because of this very same issue. It's also the only
class besides NSView to implement _updateLayerGeometryFromView.
Needless to say, I'm more than a little suspicious that scroll views
are just plain broken.

--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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