Re: WKWebView and tooltips

2016-10-20 Thread Rick Mann 
This seems to be new behavior in iOS 10. The exact same code on iOS 9 does not 
exhibit this behavior.

Mobile Safari does not exhibit this behavior in either iOS.

In all cases, clicking turns the control blue (our hover state), although in 
iOS 9 when the action completes, the control turns back to white.

> On Oct 20, 2016, at 17:52 , Rick Mann  wrote:
> 
> We have a complex WebGL app that has some controls defined via HTML elements. 
> We use this code both on the web, and in an iOS app inside a WKWebView. We 
> recently added tooltips (as a title attribute on an  element), and now the 
> first tap brings up the tooltip. Subsequent taps actuate the control. Tapping 
> the tooltip hides it.
> 
> But this only happens in my WKWebView version of the app. Loading the same 
> app via Safari on iOS doesn't exhibit this behavior.
> 
> I've tried googling for an answer, but so far nothing.
> 
> Any ideas? Thanks.
> 
> -- 
> 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/rmann%40latencyzero.com
> 
> This email sent to rm...@latencyzero.com


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

WKWebView and tooltips

2016-10-20 Thread Rick Mann 
We have a complex WebGL app that has some controls defined via HTML elements. 
We use this code both on the web, and in an iOS app inside a WKWebView. We 
recently added tooltips (as a title attribute on an  element), and now the 
first tap brings up the tooltip. Subsequent taps actuate the control. Tapping 
the tooltip hides it.

But this only happens in my WKWebView version of the app. Loading the same app 
via Safari on iOS doesn't exhibit this behavior.

I've tried googling for an answer, but so far nothing.

Any ideas? Thanks.

-- 
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: iOS: Preventing a singleton from being deallocated when the app is in the background.

2016-10-20 Thread Alex Zavatone 

On Oct 20, 2016, at 6:37 PM, Greg Parker wrote:

> 
>> On Oct 19, 2016, at 8:41 PM, Alex Zavatone  wrote:
>> 
>> In that case we would find out really quickly, because this is one of the 
>> classes that starts up as soon as the app makes several server calls.  When 
>> our error happens that appears like a dealloc, the app has been running and 
>> using this class for a while and is sitting around on iOS while it is in the 
>> background.
>> 
>> Yet we are seeing log output indicating the init method getting executed 
>> twice.  
> 
> Verify that you are seeing two init logs from one process rather than one 
> init log each from two processes. (Adding the PID to the log should resolve 
> that, if you don't have it already.)
> 
> Verify that your singleton enforcement is thread-safe. Thread-unsafe 
> singleton enforcement can create a second singleton if there is a race.
> 
> Log the stack trace of each init call. Perhaps one caller is bypassing your 
> singleton enforcement somehow. (For example, you wrote singleton enforcement 
> in +alloc but some call sites are using +allocWithZone:.)
> 
> Log the address of the object being returned by init. Perhaps there is only 
> one object but init is being called a second time on it.

That's a big one right there.  The address would be different if this was 
another instance.  

Thanks Greg, I'll make sure that we track this more closely to verify if this 
is or is not happening.

We did have one case months ago where the object was losing the reference to 
the singleton's static ref.  No idea how that happened, but directly calling 
the singleton through it's sharedReference solved the issue.  

Thanks.

> 
> Log or crash in dealloc, if your singleton enforcement might allow the object 
> to be deallocated and then a new one to be created.
> 
> 



___

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: Resize NSCollectionView items after resize

2016-10-20 Thread Steve Mills 
On Oct 20, 2016, at 17:26:47, Laurent Daudelin  wrote:
> 
> I used a UICollectionView in an iPad app. But the NSCollectionView is very 
> similar. The only difference I can tell is that, when you drag a collection 
> view onto your view controller view, you get contentArray layout type. But, 
> if you switch to “Flow”, you will automatically get a collection view flow 
> layout. That’s what I used from my view controller to resize the collection 
> view cells inside the collection view by setting the item size properties. 
> There is a little bit of math to do since you need to take into account the 
> items spacing but that is not very hard. On iOS, you don’t have any choice in 
> the layout of the UICollectionView.

That's not really what I asked. I already know how to size the items.

--
Steve Mills
Drummer, Mac geek


___

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: iOS: Preventing a singleton from being deallocated when the app is in the background.

2016-10-20 Thread Greg Parker 

> On Oct 19, 2016, at 8:41 PM, Alex Zavatone  wrote:
> 
> In that case we would find out really quickly, because this is one of the 
> classes that starts up as soon as the app makes several server calls.  When 
> our error happens that appears like a dealloc, the app has been running and 
> using this class for a while and is sitting around on iOS while it is in the 
> background.
> 
> Yet we are seeing log output indicating the init method getting executed 
> twice.  

Verify that you are seeing two init logs from one process rather than one init 
log each from two processes. (Adding the PID to the log should resolve that, if 
you don't have it already.)

Verify that your singleton enforcement is thread-safe. Thread-unsafe singleton 
enforcement can create a second singleton if there is a race.

Log the stack trace of each init call. Perhaps one caller is bypassing your 
singleton enforcement somehow. (For example, you wrote singleton enforcement in 
+alloc but some call sites are using +allocWithZone:.)

Log the address of the object being returned by init. Perhaps there is only one 
object but init is being called a second time on it.

Log or crash in dealloc, if your singleton enforcement might allow the object 
to be deallocated and then a new one to be created.


-- 
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: Resize NSCollectionView items after resize

2016-10-20 Thread Laurent Daudelin 
I used a UICollectionView in an iPad app. But the NSCollectionView is very 
similar. The only difference I can tell is that, when you drag a collection 
view onto your view controller view, you get contentArray layout type. But, if 
you switch to “Flow”, you will automatically get a collection view flow layout. 
That’s what I used from my view controller to resize the collection view cells 
inside the collection view by setting the item size properties. There is a 
little bit of math to do since you need to take into account the items spacing 
but that is not very hard. On iOS, you don’t have any choice in the layout of 
the UICollectionView.

-Laurent.
-- 
Laurent Daudelin
laur...@nemesys-soft.com 
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/ 
Logiciels Nemesys Software

> On Oct 20, 2016, at 13:47, Steve Mills  wrote:
> 
> I have an NSCollectionView whose items' size are dependent on a zoom slider, 
> with the largest zoom fitting 1 item within the width or height of the 
> enclosingScrollView. What's the best way to cause the items to resize as a 
> result of the NSCollectionView being resized (caused by window resize, 
> enclosing splitter resize, etc)? Maybe set up a notification handler for 
> NSViewFrameDidChangeNotification on the NSCollectionView's 
> enclosingScrollView? Or is there something in the massive collection of 
> collection and layout classes that would be better? I looked through it all, 
> but nothing makes sense for this.
> 
> --
> Steve Mills
> Drummer, Mac geek
> 
> 
> ___
> 
> 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/laurent%40nemesys-soft.com
> 
> This email sent to laur...@nemesys-soft.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

Layout and Popovers

2016-10-20 Thread Rick Aurbach 
I’m sure I’m missing something really basic here, but I’ve been trying to 
figure this out for several days without success:

I have a sequence of panels that I am displaying in a 
UIPopoverPresentationController. I am implementing this using a 
UINavigationController with a stack of panels.

The panel that is causing a problem is a UITableViewController. The problem is 
that the controller’s tableView retains the default height that the 
UINavigationController has (1024 in my case), rather than the height of the 
visible rectangle of the UIPopoverPresentationController. In other words, the 
presentation controller is acting like a clipping window through which the 
(unmodified) tableView is displayed.

This is a problem because tableView.scrollToRow(at: indexPath, at: .middle, 
animated: true) places the specified row at the middle of what it thinks is the 
tableView (i.e., around 512 in my case), rather than in the center of the 
revealed rectangle defined by the popup presentation controller. In this case, 
this means the the scrolled row is not visible.

Note that I am using a storyboard, specifying Content Size: Use Preferred 
Explicit Size.

What should I do to fix this problem? Must I explicitly resize the UITableView 
to fit the popover’s view? Is there any way to get the autoLayout system to do 
this for me? Has anyone else experienced a similar problem?

Or am I just stupidly overlooking a completely obvious step that I really OUGHT 
to know?

Cheers,

Rick Aurbach
___

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

Resize NSCollectionView items after resize

2016-10-20 Thread Steve Mills 
I have an NSCollectionView whose items' size are dependent on a zoom slider, 
with the largest zoom fitting 1 item within the width or height of the 
enclosingScrollView. What's the best way to cause the items to resize as a 
result of the NSCollectionView being resized (caused by window resize, 
enclosing splitter resize, etc)? Maybe set up a notification handler for 
NSViewFrameDidChangeNotification on the NSCollectionView's enclosingScrollView? 
Or is there something in the massive collection of collection and layout 
classes that would be better? I looked through it all, but nothing makes sense 
for this.

--
Steve Mills
Drummer, Mac geek


___

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: inconsistencies in view renderings

2016-10-20 Thread Quincey Morris 
On Oct 20, 2016, at 09:53 , Alan Snyder  wrote:
> 
> If you exclude textured controls in the window content area, then my examples 
> are all moot.

Here’s what the HIG has to say about this 
(developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/ControlsAll.html#//apple_ref/doc/uid/2957-CH46-SW2):

> Some Controls Can Be Used in the Window Frame
> 
> A small subset of controls have a display style that makes them suitable for 
> use in the window-frame areas (that is, in the toolbar or a bottom bar); 
> these controls are listed in Table 35-1.
> 
> [… table lists rounded textured buttons, along with textured segmented 
> controls and textured popup menus …]
> 
> *Don’t use the window frame–specific control styles in the window 
> body*[emphasis in original]. The control and style combinations listed Table 
> 35-1 are specially designed to look good on the window-frame, whether it’s 
> translucent or opaque. *These control styles don't look good in the window 
> body*[emphasis in original]. In particular, these control styles can use 
> inactive and other appearances that don't harmonize with standard control 
> styles.
> 
> Don’t use window-body controls or styles in the window frame. All 
> system-provided controls and styles other than those listed in Table 35-1 are 
> designed to look good in the window body and its content regions, and should 
> not be used in the window frame.

Isn’t that the answer to the question you’re asking? I’m not excluding textured 
controls from the content area, Apple is.

> Can you tell me how to create a window with a bottom status bar in IB? It 
> seems to depend on some sort of analysis by AppKit.

Select the window in IB and display the Size inspector. In the last section, 
“Content Border”, enter a manual value in the “Bottom” field. (I haven’t had 
much success with any of the menu choices that promise to set the bottom border 
height automatically.)

___

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: inconsistencies in view renderings

2016-10-20 Thread Alan Snyder 
If you exclude textured controls in the window content area, then my examples 
are all moot.

Can you tell me how to create a window with a bottom status bar in IB? It seems 
to depend on some sort of analysis by AppKit.





> On Oct 19, 2016, at 8:16 PM, Quincey Morris 
>  wrote:
> 
> So, clearly, there is an intention to gray out toolbars and status bars in 
> inactive window, and an intention not to gray out controls in the body of a 
> window. At a high level, doesn’t that describe the things that you’ve been 
> seeing?

___

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: iOS: Preventing a singleton from being deallocated when the app is in the background.

2016-10-20 Thread Alex Zavatone 

On Oct 19, 2016, at 4:04 PM, Doug Hill wrote:

> 
>> On Oct 19, 2016, at 2:00 PM, Jens Alfke  wrote:
>> 
>> 
>>> On Oct 19, 2016, at 1:23 PM, Steve Mills  wrote:
>>> 
>>> Pardon my obvious question, but this isn't a matter of your app napping 
>>> while in the background, is it? Or something like that?
>> 
>> Why would that cause a singleton to be dealloced? The app just stops getting 
>> CPU time for a while.
>> 
>> —Jens
> 
> Presumably if the app is terminated due to inactivity everything would be 
> dealloc'd including singletons. No idea if that is happening or not in this 
> case though.
> 
> Doug Hill

We have a repeating background task scheduled to operate when the app is within 
the background.
___

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