Re: progress bar not updating

[Steve Mills]

On Oct 06, 2016, at 12:05 PM, "J.E. Schotsman"  wrote:

I have simple progress bar in a window that refuses to update normally.

I don't suppose it's as simple as progress.usesThreadedAnimation = YES;?

Sent from iCloud's ridiculous UI, so, sorry about the formatting

 
___

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: progress bar not updating

[Quincey Morris]

On Oct 6, 2016, at 13:26 , Jens Alfke  wrote:
> 
> Maybe someone’s come up with a generic proxy class that can be used to 
> dispatch the notifications to the main thread?

Well, Apple has. NSProgress is a multi-purpose class, one of whose purposes is 
to provide a thread-safe way of trampolining the progress completion reports 
from a background worker thread to properties that may be safely accessed from 
the main thread.

However, there’s a bit of a learning curve associated with NSProgress, since it 
does other stuff that may or may not be useful here. Also, some additional 
coding may be needed to rewire the properties that the UI bindings actually 
use, to match to the NSProgress API. For that reason, it may be simpler (in 
this case) just to dispatch to the main thread and keep the rest of existing 
code structure.

I remember you had an excursion into the weird world of NSProgress, maybe 2-3 
years ago, because you posted about it here. It’s only fairly recently that 
I’ve started using NSProgress too.

___

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: progress bar not updating

[Jens Alfke]

> On Oct 6, 2016, at 11:36 AM, J.E. Schotsman  wrote:
> 
> CoreAnimation: warning, deleted thread with uncommitted CATransaction; set 
> CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.

Definitely looks like a threading problem — the view tried to use CA on the 
background thread, but that thread isn’t set up to use CA.

KVO and bindings aren’t aware of threads; they just call observers 
synchronously when properties change. Maybe someone’s come up with a generic 
proxy class that can be used to dispatch the notifications to the main thread?

Threading is infamously hard. Any kind of messaging or data sharing between 
threads has to be thought through really carefully. Most Cocoa classes are 
_not_ thread-safe, so you have to be careful to either call them only on the 
main thread (AppKit, UIKit), or at least only use them from one thread at a 
time (Foundation).

—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: Extra logging in Simulators for iOS 10 & for macOS Sierra?

[Eric E. Dolecki]

Thank you very much. It's especially annoying when using
MultipeerConnectivity. I'll check it out.

On Thu, Oct 6, 2016 at 3:54 PM Quincey Morris <
quinceymor...@rivergatesoftware.com> wrote:

> On Oct 6, 2016, at 12:06 , Eric E. Dolecki  wrote:
>
>
> Is there a way to turn this off for Xcode 8.0?
>
>
> I believe this (the unwanted messages) is resolved in Xcode 8.1 beta 2,
> although I haven’t verified this personally.
>
>
___

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: Extra logging in Simulators for iOS 10 & for macOS Sierra?

[Quincey Morris]

On Oct 6, 2016, at 12:06 , Eric E. Dolecki  wrote:
> 
> Is there a way to turn this off for Xcode 8.0?

I believe this (the unwanted messages) is resolved in Xcode 8.1 beta 2, 
although I haven’t verified this personally.

___

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: Extra logging in Simulators for iOS 10 & for macOS Sierra?

[David Brittain]

You can set the environment variable OS_ACTIVITY_MODE=disable on the
scheme's Run page in the arguments tab. In the simulator that stops all the
stuff from the system and NSLog in your app still works. Unfortunately on
device this also suppresses NSLogs from your own code.

On 6 October 2016 at 12:06, Eric E. Dolecki  wrote:

> When I build to device for iOS - I get the expected logging. If I build to
> an iOS Simulated device, I am getting a bunch of logging to the console.
>
> 2016-10-06 15:02:35.138443 testBars[59267:10948290] subsystem:
> com.apple.UIKit, category: HIDEventFiltered, enable_level: 0,
> persist_level: 0, default_ttl: 0, info_ttl: 0, debug_ttl: 0,
> generate_symptoms: 0, enable_oversize: 1, privacy_setting: 2,
> enable_private_data: 0
> ...
>
> The same goes for when I build a macOS application - I am getting all kinds
> of extra logging (not the same as for iOS).
>
> Is there a way to turn this off for Xcode 8.0? Is this new and to be
> expected? Did an Apple Engineer mistakenly leave some flags on prior to
> release?
>
> Thank you,
> Eric
> ___
>
> 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/websites%40paperetto.com
>
> This email sent to websi...@paperetto.com




-- 
David Brittain
da...@paperetto.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

Extra logging in Simulators for iOS 10 & for macOS Sierra?

[Eric E. Dolecki]

When I build to device for iOS - I get the expected logging. If I build to
an iOS Simulated device, I am getting a bunch of logging to the console.

2016-10-06 15:02:35.138443 testBars[59267:10948290] subsystem:
com.apple.UIKit, category: HIDEventFiltered, enable_level: 0,
persist_level: 0, default_ttl: 0, info_ttl: 0, debug_ttl: 0,
generate_symptoms: 0, enable_oversize: 1, privacy_setting: 2,
enable_private_data: 0
...

The same goes for when I build a macOS application - I am getting all kinds
of extra logging (not the same as for iOS).

Is there a way to turn this off for Xcode 8.0? Is this new and to be
expected? Did an Apple Engineer mistakenly leave some flags on prior to
release?

Thank you,
Eric
___

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: progress bar not updating

[Ken Thomases]

On Oct 6, 2016, at 1:36 PM, J.E. Schotsman  wrote:
> 
> 
>> On 06 Oct 2016, at 19:43, Jens Alfke  wrote:
>> 
>> That means that KVO is going to call the view’s observeChange method on your 
>> background thread, not on the main thread. Which I believe qualifies as 
>> “updating the UI from a background thread”, which is illegal. It may be that 
>> the view has fail-safe code to check for this and ignores the change. Have 
>> you checked the console for warnings?
> 
> …
> Are you saying I cannot use bindings in this scenario?

When you are using bindings, you must ensure that changes to the properties to 
which UI is bound happen only on the main thread.  Depending on your design, 
you can often do something like:

dispatch_async(dispatch_get_main_queue(), ^{ self.myProperty = newValue; });

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: progress bar not updating

[J.E. Schotsman]

> On 06 Oct 2016, at 19:43, Jens Alfke  wrote:
> 
> That means that KVO is going to call the view’s observeChange method on your 
> background thread, not on the main thread. Which I believe qualifies as 
> “updating the UI from a background thread”, which is illegal. It may be that 
> the view has fail-safe code to check for this and ignores the change. Have 
> you checked the console for warnings?

I only see this warning once:

CoreAnimation: warning, deleted thread with uncommitted CATransaction; set 
CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.

Are you saying I cannot use bindings in this scenario?

Jan E.
___

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

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

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

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

Re: progress bar not updating

[Jens Alfke]

> On Oct 6, 2016, at 10:04 AM, J.E. Schotsman  wrote:
> 
> Its doubleValue is bound to the progress value of my ProgressController 
> class, so is “animating" and “indeterminate".
> ...
> The progress value and other values are changed on a background thread.

That means that KVO is going to call the view’s observeChange method on your 
background thread, not on the main thread. Which I believe qualifies as 
“updating the UI from a background thread”, which is illegal. It may be that 
the view has fail-safe code to check for this and ignores the change. Have you 
checked the console for warnings?

(Disclaimer: It’s been way too long since I did any serious AppKit coding, so 
for all I know, maybe this setup is legal now. But this does seem a likely 
reason why things aren’t working.)

—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

progress bar not updating

[J.E. Schotsman]

Hello,

I have simple progress bar in a window that refuses to update normally.
Its doubleValue is bound to the progress value of my ProgressController class, 
so is “animating" and “indeterminate".
If I print the values during a job everything is correct, but the progress bar 
won’t update. It looks indeterminate or determinate at 100%.
Only the “animating” binding results in animated display.
The progress value and other values are changed on a background thread.
The main thread remains responsive (for example I can click on a checkbox and 
see its state change).
I would expect this to work but no dice.

I have checked the visibleRect, tried every combination of 
setNeedsDisplayInRect,displayIfNeeded() and display() in order to force it but 
no success.The only way to get it to draw is this code:

progressBar.performSelectorOnMainThread( #selector(NSView.display), 
withObject:nil, waitUntilDone:false )

What am I missing (or is this normal)?
Bindings don’t get me much here if I need to create an outlet to progressBar 
and call perform...

TIA,

Jan E.


___

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

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

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

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

Re: Where are the ICU Headers?

[Gary L. Wade]

Apple has historically suggested using ICU for functionality that it's 
higher-level frameworks don't provide, and it's easy enough to get at all 
needed functionality through its C functions without using C++ (at least what I 
care about). Since most significant changes only occur in the data across 
releases, or below an API layer, the interfaces would not be as much of an 
issue for most when using the current installed library.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Oct 6, 2016, at 5:23 AM, Alastair Houghton  
> wrote:
> 
>> On 6 Oct 2016, at 10:43, dangerwillrobinsondan...@gmail.com wrote:
>> 
>> Pretty sure the reason is a simple one. 
>> If you look at the history of open source in the OS on the Apple open source 
>> page, you'll notice they pretty much bump the ICU version they use annually. 
>> Although unlikely, ICU might change in ways that breaks your app. They don't 
>> want to support ICU directly. It's a pretty tough API in C or C++ 
> 
> Also, historically, C++ ABI compatibility has been a thorny issue.  Even now, 
> if you want a C++ dynamic library to provide binary compatibility you have to 
> be pretty careful.
> 
> ICU is largely a C++ library.  It does have a C interface, but I’m not sure 
> the entire feature set is available without using C++, and ICU explicitly 
> doesn’t provide for binary compatibility at the C++ API level (or even for 
> some of its C API(!)) - see
> 
> http://userguide.icu-project.org/design#TOC-ICU-Binary-Compatibility:-Using-ICU-as-an-Operating-System-Level-Library
> 
> Kind regards,
> 
> Alastair.
> 
> --
> http://alastairs-place.net
> 


___

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: Where are the ICU Headers?

[Alastair Houghton]

On 6 Oct 2016, at 10:43, dangerwillrobinsondan...@gmail.com wrote:
> 
> Pretty sure the reason is a simple one. 
> If you look at the history of open source in the OS on the Apple open source 
> page, you'll notice they pretty much bump the ICU version they use annually. 
> Although unlikely, ICU might change in ways that breaks your app. They don't 
> want to support ICU directly. It's a pretty tough API in C or C++ 

Also, historically, C++ ABI compatibility has been a thorny issue.  Even now, 
if you want a C++ dynamic library to provide binary compatibility you have to 
be pretty careful.

ICU is largely a C++ library.  It does have a C interface, but I’m not sure the 
entire feature set is available without using C++, and ICU explicitly doesn’t 
provide for binary compatibility at the C++ API level (or even for some of its 
C API(!)) - see

http://userguide.icu-project.org/design#TOC-ICU-Binary-Compatibility:-Using-ICU-as-an-Operating-System-Level-Library

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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: Where are the ICU Headers?

[dangerwillrobinsondanger]

Pretty sure the reason is a simple one. 
If you look at the history of open source in the OS on the Apple open source 
page, you'll notice they pretty much bump the ICU version they use annually. 
Although unlikely, ICU might change in ways that breaks your app. They don't 
want to support ICU directly. It's a pretty tough API in C or C++ 

You could always build your own version and bundle it. 

If you download the open source version they post you'll get the right 
settings. 

It's not easy to build it right, but it's doable and you can link to one you 
build and bundle in your app. 

Linking to theirs would leave them beholden to a fast outdated version to 
support your app. 

Sent from my iPhone

> On 6 Oct 2016, at 18:32, Gary L. Wade  wrote:
> 
> My experience has been that last year (iOS 9 and OS X 10.11) Apple made ICU a 
> private framework worthy of rejection from its App Store if you used its APIs 
> directly. I encountered this because like in years past when Apple did not 
> provide ICU through a higher-level framework, we were encouraged to call ICU 
> directly, and that's when I supplied a signature to translate between 
> 2-letter and 3-letter language codes to work around the no-headers issue, 
> which I needed to support a 3rd party services requirement. However, the app 
> was rejected as using a private API. I was going to challenge it, but my 
> management decided we should hard code the mappings.
> --
> Gary L. Wade (Sent from my iPad)
> http://www.garywade.com/
> 
>> On Oct 6, 2016, at 1:22 AM, Gerriet M. Denkmann  wrote:
>> 
>> The Icu stuff (57.1) is included in macOS 12.
>> 
>> There is:
>> /usr/lib/libicucore.A.dylib
>> 
>> and Xcode has:
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libicucore.tbd
>>  
>> 
>> But I cannot find the headers.
>> 
>> Gerriet.
>> 
>> 
>> ___
>> 
>> 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/garywade%40desisoftsystems.com
>> 
>> This email sent to garyw...@desisoftsystems.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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@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: Where are the ICU Headers?

[Gary L. Wade]

My experience has been that last year (iOS 9 and OS X 10.11) Apple made ICU a 
private framework worthy of rejection from its App Store if you used its APIs 
directly. I encountered this because like in years past when Apple did not 
provide ICU through a higher-level framework, we were encouraged to call ICU 
directly, and that's when I supplied a signature to translate between 2-letter 
and 3-letter language codes to work around the no-headers issue, which I needed 
to support a 3rd party services requirement. However, the app was rejected as 
using a private API. I was going to challenge it, but my management decided we 
should hard code the mappings.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Oct 6, 2016, at 1:22 AM, Gerriet M. Denkmann  wrote:
> 
> The Icu stuff (57.1) is included in macOS 12.
> 
> There is:
> /usr/lib/libicucore.A.dylib
> 
> and Xcode has:
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libicucore.tbd
>  
> 
> But I cannot find the headers.
> 
> Gerriet.
> 
> 
> ___
> 
> 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/garywade%40desisoftsystems.com
> 
> This email sent to garyw...@desisoftsystems.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

Where are the ICU Headers?

[Gerriet M. Denkmann]

The Icu stuff (57.1) is included in macOS 12.

There is:
 /usr/lib/libicucore.A.dylib

and Xcode has:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libicucore.tbd
 

But I cannot find the headers.

Gerriet.


___

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