Re: Smooth adjustScroll of NSScrollView

[Nick]

Let me explain what I am trying to achieve.

Here's my application with an NSScrollView, and it's documentView (which is
an NSView subclass) implements a method

-(NSRect)adjustScroll:(NSRect)newVisible {

NSRect modifiedRect = newVisible;

modifiedRect.origin.y = (int)(modifiedRect.origin.y/50.0)*50.0;

return modifiedRect;

}

This is what my running app looks like (it's a 300 KB screen capture video
file):
http://rghost.net/download/6xkClpQ6h/b1829f6195168b62fad853fc96c73c42a998b367/MyApp.mov

On the other hand, this is what Calendar's scrolling looks like (notice how
smoothly it gravitates to make the week rows always fit into the view
completely):
(3 MB video)
http://rghost.net/download/6G2jf9Xgy/b49a74b9d0877d2b6324aca37c481f636e070b8b/CalendarApp.mov

I am trying to have a similar "smooth" scrolling adjustment animation
effect, instead of jerky scrolling I have now with adjustScroll.
But I don't know how Apple did it.
Can you give me some hints, if anyone faced with a similar problem?

Thank you




2015-10-26 20:16 GMT+02:00 Nick :

> Hi
> I am developing an application that looks similar to the OS X's
> Calendar.app.
>
> One of the nice features it has is the "gravity effect" to the grid lines,
> when the user performs vertical scrolling - if you scroll the calendar so
> that half-row is clipped by the Clip View, it automatically scrolls
>  further until the whole row fits into the view.
>
> Documentation says that we should implement the adjustScroll method of the
> document view, where, given a proposed NSRect, we can update it however we
> want.
> I did implement this method, and it works, but the problem is that now
> scrolling is not smooth at all - It just scrolls "line by line", as it does
> in Windows (as in I move two fingers on the trackpad - and get lines simply
> displayed one after the other). Is this the intended behavior? If it is,
> how did Apple developers make their  Calendar "adjustScroll"-ed scrolling
> so smooth? Or is there anything wrong in my code i should be looking to fix?
>
> Thank 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 sent to arch...@mail-archive.com

Re: Updated View Bounds After Orientation Change...

[Peters, Brandon]

Ken,

Thanks. I think I have the idea. I will have to try it when I get home.

--Brandon

> On Oct 26, 2015, at 23:40, Ken Thomases  wrote:
> 
> Read these lines over and over until you see it:
> 
>> On Oct 26, 2015, at 9:49 PM, Peters, Brandon  wrote:
>> 
>> (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't 
>> understand, refer to the documentation for the UIView property 
>> translatesAutoresizingMaskIntoConstraints)
>> (
>>   "> UIActivityIndicatorView:0x14eb3760.midX == + 10>",
> 
> Regards,
> Ken
> 

___

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

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

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

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

Re: Smooth adjustScroll of NSScrollView

[Jens Alfke]

I’m guessing they wait for the scrolling to finish [not sure how, maybe just 
polling the scroll position], then use Core Animation to set the scroll 
position to the nearest grid-line.

—Jens
___

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

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

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

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

Re: Hide UINavigationBar and keep UIPageController content static

[Stevo Brock]

Hi David and Kyle,

Thanks so much for the insight and pointers.

I was manually calling setNeedsDisplay() when toggling the navigation bar 
hidden, and now I can remove that and just set the contentMode to .Redraw.  
That’s great.

And setting the automaticallyAdjustsScrollViewInsets to false helps, and I can 
now go back to drawing the content under the top bars and the content stays put 
while the bar animates up and down.

Thanks again guys for your expert insight.


-Stevo Brock
 Owner
 Sunset Magicwerks, LLC
 www.sunsetmagicwerks.com
@SunsetMagicwrks
 818-478-9758

> On Oct 25, 2015, at 10:09 AM, David Duncan  wrote:
> 
> 
>> On Oct 24, 2015, at 10:23 AM, Kyle Sluder  wrote:
>> 
>> On Tue, Oct 20, 2015, at 11:21 AM, Stevo Brock wrote:
>>> The trick is, if in the storyboard, on the UIPageController, I set the
>>> “Under Top Bars” to yes, my custom view draws full screen.  But when I
>>> toggle the navigationBarHidden, the custom view and its superview scroll
>>> up and down the size of the navigation bar.
>> 
>> This sounds like it might be a bug in automatic content inset
>> adjustment. Please file a Radar with a sample project.
>> 
>> In the meantime, you can try turning off
>> automaticallyAdjustsScrollViewInsets on your view controller and
>> managing layout manually (relative to the view controller's
>> topLayoutGuide) in an override of -viewDidLayoutSubviews.
>> 
>>> 
>>> 
>>> Alternatively, if in the storyboard, on the UIPageController, I set the
>>> “Under Top Bars” to no, my custom view draws in the screen space under
>>> the navigation bar.  When I toggle the navigationBarHidden, the view
>>> stretches to fill the full height of the screen, but I never get a redraw
>>> call, so the drawing is stretched.
>> 
>> This is expected. Views that need to redraw when they change size should
>> override -setBounds: to call [self setNeedsDisplay].
> 
> If you need to redraw on bounds change, change the contentMode to Redraw. 
> Overriding -setBounds: is insufficient and unnecessary.
> 
>> 
>> --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/david.duncan%40apple.com
>> 
>> This email sent to david.dun...@apple.com
> 
> --
> David Duncan
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/devlists%40sunsetmagicwerks.com
> 
> This email sent to devli...@sunsetmagicwerks.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: Updated View Bounds After Orientation Change...

[David Duncan]

In general I would highly recommend spending some time with this years Auto 
Layout talks from WWDC. One of the many gems is the discussion on how to read 
these logs:





> On Oct 27, 2015, at 6:53 AM, Peters, Brandon  wrote:
> 
> Ken,
> 
> Thanks. I think I have the idea. I will have to try it when I get home.
> 
> --Brandon
> 
>> On Oct 26, 2015, at 23:40, Ken Thomases  wrote:
>> 
>> Read these lines over and over until you see it:
>> 
>>> On Oct 26, 2015, at 9:49 PM, Peters, Brandon  wrote:
>>> 
>>> (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't 
>>> understand, refer to the documentation for the UIView property 
>>> translatesAutoresizingMaskIntoConstraints)
>>> (
>>>  ">> UIActivityIndicatorView:0x14eb3760.midX == + 10>",
>> 
>> Regards,
>> Ken
>> 

--
David Duncan


___

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

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

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

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

Re: Hide UINavigationBar and keep UIPageController content static

[Kyle Sluder]

On Tue, Oct 27, 2015, at 11:49 AM, Stevo Brock wrote:
> Hi David and Kyle,
> 
> Thanks so much for the insight and pointers.
> 
> I was manually calling setNeedsDisplay() when toggling the navigation bar
> hidden, and now I can remove that and just set the contentMode to
> .Redraw.  That’s great.
> 
> And setting the automaticallyAdjustsScrollViewInsets to false helps, and
> I can now go back to drawing the content under the top bars and the
> content stays put while the bar animates up and down.
> 
> Thanks again guys for your expert insight.

You're welcome. You can pay me back by filing a bug about this issue
with an attached sample project. :P

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

How to completely destroy/close a Window

[Dave]

Hi,

I know I’ve seen a property that controls if a Window’s storage is released etc 
and the window properly closed or if it just “hides” but I can’t seem to find 
it? I’ve looked in NSWindowController and NSWindow but I just can’t see it 
anywhere.

I have a NSWindowController and NSWindow Pair and I just want them both 
disposed of and re-created next time.

What is the recommended way do doing 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: How to completely destroy/close a Window

[Jens Alfke]

> On Oct 27, 2015, at 12:13 PM, Dave  wrote:
> 
> I know I’ve seen a property that controls if a Window’s storage is released 
> etc and the window properly closed or if it just “hides” but I can’t seem to 
> find it? I’ve looked in NSWindowController and NSWindow but I just can’t see 
> it anywhere.


NSWindow.h, line 373:

@property (getter=isReleasedWhenClosed) BOOL releasedWhenClosed;

___

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

Dictionary and Range

[Michael de Haan ]

I know it is possible to do this,

let isolated = Range(start: 20, end: 25)
let k_Index = ["isolatedTstm":isolated]

But what i really want is this,  

let foo = <30
and bar = [key:foo]

Is that possible?

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

NSFileWrapper - is this really so bad?

[Graham Cox]

In XCode 7, I’m getting a new warning when compiling some code that uses 
NSFileWrapper, due to the addition of the NON_NULL qualifier:

Null passed to a callee that requires a non-null argument

The code is:

NSFileWrapper* fw = [[NSFileWrapper alloc] 
initDirectoryWithFileWrappers:nil];  //<—  Null passed to a callee that 
requires a non-null argument
[fw setPreferredFilename:[self name]];
[fw addRegularFileWithContents:content 
preferredFilename:kDKOLibraryItemDataFileName];

I’ve been doing this forever without any issue - create the directory file 
wrapper, then add regular files to it. The API design appears to condone this 
approach, even if it’s not spelt out anywhere. Now it seems we have to turn 
this all around and precreate the dictionary then create the enclosing 
directory wrapper.

While this change isn’t too hard, it seems like extra work and means going 
through old code that’s working fine, with the possiblity of creating bugs.

Has this approach always been bad, or is it a new thing? I’m all for tightening 
up sloppy coding, but could it be that in this case the non-null qualifier is 
in error?

—Graham



___

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

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

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

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

Re: NSFileWrapper - is this really so bad?

[Rick Mann]

> On Oct 27, 2015, at 16:24 , Graham Cox  wrote:
> 
> In XCode 7, I’m getting a new warning when compiling some code that uses 
> NSFileWrapper, due to the addition of the NON_NULL qualifier:
> 
> Null passed to a callee that requires a non-null argument
> 
> The code is:
> 
>   NSFileWrapper* fw = [[NSFileWrapper alloc] 
> initDirectoryWithFileWrappers:nil];  //<—  Null passed to a callee 
> that requires a non-null argument
>   [fw setPreferredFilename:[self name]];
>   [fw addRegularFileWithContents:content 
> preferredFilename:kDKOLibraryItemDataFileName];
> 
> I’ve been doing this forever without any issue - create the directory file 
> wrapper, then add regular files to it. The API design appears to condone this 
> approach, even if it’s not spelt out anywhere. Now it seems we have to turn 
> this all around and precreate the dictionary then create the enclosing 
> directory wrapper.
> 
> While this change isn’t too hard, it seems like extra work and means going 
> through old code that’s working fine, with the possiblity of creating bugs.
> 
> Has this approach always been bad, or is it a new thing? I’m all for 
> tightening up sloppy coding, but could it be that in this case the non-null 
> qualifier is in error?

That's entirely possible. I'd suggest writing a bug with this explanation, and 
see if they're willing to formalize "nil" being okay there.


-- 
Rick Mann
rm...@latencyzero.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: NSFileWrapper - is this really so bad?

[Greg Parker]

> On Oct 27, 2015, at 4:24 PM, Graham Cox  wrote:
> 
> In XCode 7, I’m getting a new warning when compiling some code that uses 
> NSFileWrapper, due to the addition of the NON_NULL qualifier:
> 
> Null passed to a callee that requires a non-null argument
> 
> The code is:
> 
>   NSFileWrapper* fw = [[NSFileWrapper alloc] 
> initDirectoryWithFileWrappers:nil];  //<—  Null passed to a callee 
> that requires a non-null argument
>   [fw setPreferredFilename:[self name]];
>   [fw addRegularFileWithContents:content 
> preferredFilename:kDKOLibraryItemDataFileName];
> 
> I’ve been doing this forever without any issue - create the directory file 
> wrapper, then add regular files to it. The API design appears to condone this 
> approach, even if it’s not spelt out anywhere. Now it seems we have to turn 
> this all around and precreate the dictionary then create the enclosing 
> directory wrapper.
> 
> While this change isn’t too hard, it seems like extra work and means going 
> through old code that’s working fine, with the possiblity of creating bugs.
> 
> Has this approach always been bad, or is it a new thing? I’m all for 
> tightening up sloppy coding, but could it be that in this case the non-null 
> qualifier is in error?

Please file a bug report if you think a nullability annotation may be incorrect 
or that a nullability annotation and the documentation don't match. It is 
unlikely that all of the new annotations and all of the documentation are 
correct.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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

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

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

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

Re: NSFileWrapper - is this really so bad?

[Graham Cox]

> On 28 Oct 2015, at 10:24 AM, Graham Cox  wrote:
> 
> due to the addition of the NON_NULL qualifier


Actually, I should amend that: it doesn’t have ANY qualifier, so that appears 
by default to mean that it’s NOT nullable. I’m still getting used to this 
additional syntax.

—G.



___

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: NSFileWrapper - is this really so bad?

[Quincey Morris]

On Oct 27, 2015, at 16:24 , Graham Cox  wrote:
> 
>   NSFileWrapper* fw = [[NSFileWrapper alloc] 
> initDirectoryWithFileWrappers:nil];  //<—  Null passed to a callee 
> that requires a non-null argument

It’s not necessarily so much about null vs non-null. A side effect of the API 
audit that’s been ongoing after Swift happened is that it’s become preferred 
(when there’s a choice) to pass an empty collection instead of a nil pointer. 
(In the past, in many cases, it was ambiguous/inconsistent whether both were 
allowed/equivalent.)

So my guess is that the API hasn’t changed (that is, if you somehow force a nil 
value to be passed, it will still work the same), but that the SDK has changed 
(that is, you’re now supposed to pass an empty dictionary). Have you tried an 
empty dictionary?



___

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: NSFileWrapper - is this really so bad?

[Graham Cox]

> On 28 Oct 2015, at 10:53 AM, Alex Kac  wrote:
> 
> Have you tried simply passing in a blank dictionary? Is that OK?


Yes, that works OK. It’s at least a simple way to shut the warning up, though 
strikes me as unnecessary and inefficient, FWIW.

—G.



___

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

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

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

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

Re: How to completely destroy/close a Window

[Ken Thomases]

On Oct 27, 2015, at 2:58 PM, Jens Alfke  wrote:

> On Oct 27, 2015, at 12:13 PM, Dave  wrote:
>> 
>> I know I’ve seen a property that controls if a Window’s storage is released 
>> etc and the window properly closed or if it just “hides” but I can’t seem to 
>> find it? I’ve looked in NSWindowController and NSWindow but I just can’t see 
>> it anywhere.
> 
> 
> NSWindow.h, line 373:
> 
> @property (getter=isReleasedWhenClosed) BOOL releasedWhenClosed;

No, this isn't relevant.  When a window is controlled by a window controller, 
releasedWhenClosed has no effect.  See the docs.

I suspect he's thinking of oneShot or maybe backingType, but this is misguided, 
too.


On Oct 27, 2015, at 2:13 PM, Dave  wrote:

> I have a NSWindowController and NSWindow Pair and I just want them both 
> disposed of and re-created next time.


Dave, if you want to fully release a window and window controller, just 
clear/release all strong references you have to them.  If you feel like it, you 
can call -close on the window controller first or something like that, but it's 
not necessary.

Then, to create a new pair just, um, create a new pair.  Instantiate a new 
window controller and have it load its window NIB when its window is requested, 
etc.

In other words, what exactly is the mystery here?

Regards,
Ken


___

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

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

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

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

Re: NSFileWrapper - is this really so bad?

[Charles Srstka]

> On Oct 27, 2015, at 7:08 PM, Graham Cox  wrote:
> 
>> On 28 Oct 2015, at 10:53 AM, Alex Kac > > wrote:
>> 
>> Have you tried simply passing in a blank dictionary? Is that OK?
> 
> 
> Yes, that works OK. It’s at least a simple way to shut the warning up, though 
> strikes me as unnecessary and inefficient, FWIW.

It’s not that inefficient, given that an immutable empty array or dictionary is 
just going to end up being a shared instance anyway, rather than actually 
allocating and deallocating an object. The only costs should be asking the 
container if it’s empty, and the usual ARC retain/release stuff.

Charles

___

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: Smooth adjustScroll of NSScrollView

[Charles Constant]

I don't know if this information can solve your issue directly, but I used
it to fix my issue last week. I have a custom NSScroller that had jerky
scrolling. I didn't realize that views have an ".animator()" proxy that you
can use instead.

NSAnimationContext.beginGrouping()
NSAnimationContext.currentContext().duration = seconds

clipview.animator().setBoundsOrigin( clipview_pt )

NSAnimationContext.endGrouping()

Probably common knowledge, but I haven't done heaps of animations in Cocoa.
So, by setting my clipview bounds using the animator it glides to the
correct point. Hope it's relevant for your project.





On Tue, Oct 27, 2015 at 9:33 AM, Jens Alfke  wrote:

> I’m guessing they wait for the scrolling to finish [not sure how, maybe
> just polling the scroll position], then use Core Animation to set the
> scroll position to the nearest grid-line.
>
> —Jens
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/charles%40charlesism.com
>
> This email sent to char...@charlesism.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