Re: Refresh View After Mouse Inactivity

[Quincey Morris]

On Apr 30, 2016, at 17:27 , Richard Charles  wrote:
> 
> NSNumber *yes = [NSNumber numberWithBool:YES];
> [self performSelector:@selector(setNeedsDisplay:) withObject:yes 
> afterDelay:0.0];

No, that’s the opposite of the solution to that particular issue. :)

The problem is that you’re passing an object pointer (an 8-byte value) to a 
method that takes its value from the low-order byte of the the value it 
receives (more or less — exactly what it looks at is platform-dependent). A 
value of @YES or @NO is likely to be a tagged pointer, which is going to have 
at least one bit set in the low-order byte, which will make *either* @YES *or* 
@NO appear to be YES to the receiver.

You simply cannot validly invoke “setNeedsDisplay:” via ‘perfomSelector’. But 
this is not your problem.

> I have tried all these crazy ways to get the run loop to run once but nothing 
> works.

The next place I’d go is to investigate NSActivityOptions, along with 
begin/end/performActivity… in NSProcessInfo.

IOW, you might have to declare that your app is “busy” until after the 2 
seconds has expired.



___

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: Refresh View After Mouse Inactivity

[Richard Charles]

> On Apr 30, 2016, at 5:39 PM, Quincey Morris 
>  wrote:
> 
> Do you have any proof that ‘mouseMoved’ is called at all?

Yes adding logging shows that both methods mouseMoved: and mouseInactive are 
being called.

> Note that there are two different ‘mouseMoved’s. One is a continuous stream 
> of events that come from via the window if “acceptsMouseMovedEvents” is YES. 
> (It’s NO by default, and it’s a pretty bad idea to set it to YES, unless you 
> enjoy avalanches.) The other is a stream of events that come from moving the 
> mouse inside a NSTrackingArea, provided that the right initial conditions for 
> detecting that the mouse is inside are satisfied. It’s not clear which 
> technique you’re using here.

I am using NSTrackingArea.

> The other thing that occurs to me is that, following a recent discussion here 
> about performSelector, you can’t validly pass @YES (an object) as a parameter 
> to a method that expects a scalar value (a BOOL in this case). You’d need to 
> wrap this in your own method that takes a NSNumber parameter, except that 
> you’ve already sort of done that by providing this ‘mouseInactive’ method. 
> (However, @YES would almost certainly produce a result of YES if 
> mis-interpreted as a BOOL scalar, so that’s likely not the cause.)

I have tried this and get the same results.

NSNumber *yes = [NSNumber numberWithBool:YES];
[self performSelector:@selector(setNeedsDisplay:) withObject:yes 
afterDelay:0.0];

> Lastly, it’s always possible that something to do with power management is 
> preventing events from being sent from the run loop. This is hard to figure 
> out, because trying to debug it changes the scenario.

My programming notes say that calling performSelector:withObject:afterDelay: 
with a delay of 0.0 would cause the run loop run once but that stopped working 
with OS X 10.10 Yosemite (mid 2014 time frame).

I have tried all these crazy ways to get the run loop to run once but nothing 
works.

http://stackoverflow.com/questions/4739748/is-there-a-way-to-make-drawrect-work-right-now

It may be that the above stackoverflow discussion was pre Yosemite.

However if I press any key on the keyboard after mouse has stopped moving and 
the delay time period has passed then presto the view refreshes.

--Richard 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: undomanger performance

[Quincey Morris]

On Apr 30, 2016, at 12:49 , Jean-Daniel Dupas  wrote:
> 
> Maybe registering the changes is not executed immediately but deferred until 
> the end of the current event loop cycle

There’s no “maybe” about it. By default, the undo manager groups all undo 
actions registered between iterations of the run loop into a single top-level 
group.
___

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: Refresh View After Mouse Inactivity

[Quincey Morris]

On Apr 30, 2016, at 16:08 , Richard Charles  wrote:
> 
> - (void)mouseInactive
> {
>// This does not work.
>[self setNeedsDisplay:YES];
> 
>// This does not work. I think this did work at one time but stopped
>// working on OS X 10.10 Yosemite.
>[self performSelector:@selector(setNeedsDisplay:)
>   withObject:@YES afterDelay:0.0];
> }
> 
> - (void)mouseMoved:(NSEvent *)event
> {
>[NSObject cancelPreviousPerformRequestsWithTarget:self];
>[self performSelector:@selector(mouseInactive)
>   withObject:nil afterDelay:2.0];
> }
> 
> The problem is that calling setNeedsDisplay: does not work. It appears that 
> the run loop is stopped. Once the user does something like press a key on the 
> keyboard then the view is refreshed.

Do you have any proof that ‘mouseMoved’ is called at all?

Note that there are two different ‘mouseMoved’s. One is a continuous stream of 
events that come from via the window if “acceptsMouseMovedEvents” is YES. (It’s 
NO by default, and it’s a pretty bad idea to set it to YES, unless you enjoy 
avalanches.) The other is a stream of events that come from moving the mouse 
inside a NSTrackingArea, provided that the right initial conditions for 
detecting that the mouse is inside are satisfied. It’s not clear which 
technique you’re using here.

The other thing that occurs to me is that, following a recent discussion here 
about performSelector, you can’t validly pass @YES (an object) as a parameter 
to a method that expects a scalar value (a BOOL in this case). You’d need to 
wrap this in your own method that takes a NSNumber parameter, except that 
you’ve already sort of done that by providing this ‘mouseInactive’ method. 
(However, @YES would almost certainly produce a result of YES if 
mis-interpreted as a BOOL scalar, so that’s likely not the cause.)

Lastly, it’s always possible that something to do with power management is 
preventing events from being sent from the run loop. This is hard to figure 
out, because trying to debug it changes the scenario.

___

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

Refresh View After Mouse Inactivity

[Richard Charles]

I have a view that needs to be refreshed after a period of mouse inactivity.

- (void)mouseInactive
{
// This does not work.
[self setNeedsDisplay:YES];

// This does not work. I think this did work at one time but stopped
// working on OS X 10.10 Yosemite.
[self performSelector:@selector(setNeedsDisplay:)
   withObject:@YES afterDelay:0.0];
}

- (void)mouseMoved:(NSEvent *)event
{
[NSObject cancelPreviousPerformRequestsWithTarget:self];
[self performSelector:@selector(mouseInactive)
   withObject:nil afterDelay:2.0];
}

The problem is that calling setNeedsDisplay: does not work. It appears that the 
run loop is stopped. Once the user does something like press a key on the 
keyboard then the view is refreshed.

Does anyone have any ideas?

--Richard 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: undomanger performance

[Jean-Daniel Dupas]

Just my 2 cents. 

Maybe registering the changes is not executed immediately but deferred until 
the end of the current event loop cycle, so the undo manager can group them 
into a single operation.

In such case, it would mean that what you think is the undo registration is 
just a call to schedule the real operation and is relatively fast, but the real 
works take much more time and is deferred until the end of the current event 
handling.

> Le 30 avr. 2016 à 21:39, Georg Seifert  a écrit :
> 
> Hi
> 
> My app deals with an object tree that can have millions of leaves. It is 
> possible to run an operation on all of them. Each will register its own 
> change with the undo manager. The hole operation might tale a few second (the 
> last line in the trace below). But after my operation is finished, there is 
> another operation triggered by the system that takes much longer than the 
> original task and it blocks the UI. It is directly linked to the undo 
> registration, if I disable it, this does not happen. 
> 
> Running Time  Self (ms)   Symbol Name
> 26258.0ms   81.3% 0,0 _dispatch_mgr_thread  0x4ef18d
> 26258.0ms   81.3% 0,0  _dispatch_mgr_thread
> 26258.0ms   81.3% 0,0   _dispatch_mgr_invoke
> 26250.0ms   81.2% 0,0_dispatch_mgr_queue_drain
> 26248.0ms   81.2% 48,0_dispatch_queue_drain
> 26168.0ms   81.0% 1,0  _dispatch_client_callout
> 26141.0ms   80.9% 97,0  _dispatch_source_set_timer3
> 25561.0ms   79.1% 25561,0_dispatch_timers_update
> 481.0ms1.4%   8,0_dispatch_resume_slow
> 2.0ms0.0% 2,0_dispatch_queue_wakeup
> 8.0ms0.0% 0,0   free
> 6.0ms0.0% 6,0   dispatch_release
> 6.0ms0.0% 6,0   _os_object_release
> 4.0ms0.0% 4,0   dispatch_resume
> 1.0ms0.0% 1,0   nano_free_definite_size
> 1.0ms0.0% 0,0   
> 12.0ms0.0%12,0 OSAtomicEnqueue
> 9.0ms0.0% 4,0  gcd_queue_item_complete_hook
> 6.0ms0.0% 1,0  _dispatch_continuation_free_to_cache_limit
> 3.0ms0.0% 2,0  
> _dispatch_introspection_queue_item_dequeue_hook
> 1.0ms0.0% 1,0  DYLD-STUB$$free
> 1.0ms0.0% 0,0  
> 2.0ms0.0% 2,0 _dispatch_introspection_callout_return
> 7.0ms0.0% 6,0_dispatch_cache_cleanup
> 1.0ms0.0% 0,0_dispatch_timers_run
> 4162.0ms   12.8%  0,0 Main Thread  0x4ef176
> 
> Does anyone has an idea what’s going on?
> 
> Thanks
> Georg Seifert
> Xcode 7.2 on MacOS 10.10.5, 27" Retina-iMac.
> 
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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

undomanger performance

[Georg Seifert]

Hi

My app deals with an object tree that can have millions of leaves. It is 
possible to run an operation on all of them. Each will register its own change 
with the undo manager. The hole operation might tale a few second (the last 
line in the trace below). But after my operation is finished, there is another 
operation triggered by the system that takes much longer than the original task 
and it blocks the UI. It is directly linked to the undo registration, if I 
disable it, this does not happen. 

Running TimeSelf (ms)   Symbol Name
26258.0ms   81.3%   0,0 _dispatch_mgr_thread  0x4ef18d
26258.0ms   81.3%   0,0  _dispatch_mgr_thread
26258.0ms   81.3%   0,0   _dispatch_mgr_invoke
26250.0ms   81.2%   0,0_dispatch_mgr_queue_drain
26248.0ms   81.2%   48,0_dispatch_queue_drain
26168.0ms   81.0%   1,0  _dispatch_client_callout
26141.0ms   80.9%   97,0  _dispatch_source_set_timer3
25561.0ms   79.1%   25561,0_dispatch_timers_update
481.0ms1.4% 8,0_dispatch_resume_slow
2.0ms0.0%   2,0_dispatch_queue_wakeup
8.0ms0.0%   0,0   free
6.0ms0.0%   6,0   dispatch_release
6.0ms0.0%   6,0   _os_object_release
4.0ms0.0%   4,0   dispatch_resume
1.0ms0.0%   1,0   nano_free_definite_size
1.0ms0.0%   0,0   
12.0ms0.0%  12,0 OSAtomicEnqueue
9.0ms0.0%   4,0  gcd_queue_item_complete_hook
6.0ms0.0%   1,0  _dispatch_continuation_free_to_cache_limit
3.0ms0.0%   2,0  
_dispatch_introspection_queue_item_dequeue_hook
1.0ms0.0%   1,0  DYLD-STUB$$free
1.0ms0.0%   0,0  
2.0ms0.0%   2,0 _dispatch_introspection_callout_return
7.0ms0.0%   6,0_dispatch_cache_cleanup
1.0ms0.0%   0,0_dispatch_timers_run
4162.0ms   12.8%0,0 Main Thread  0x4ef176

Does anyone has an idea what’s going on?

Thanks
Georg Seifert
Xcode 7.2 on MacOS 10.10.5, 27" Retina-iMac.


___

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

What is the AXSections accessibility attribute in OS X?

[Bill Cheeseman]

I asked this question early yesterday on the accessibility-dev list and 
received no answers, so I thought I would try here.

Using my UI Browser application , I am seeing a new 
"AXSections" accessibility attribute in all windows of all applications in OS X 
10.11 El Capitan, but I can find no reference to it online and no documentation 
for it. Can anybody enlighten me as to what it is and how it is meant to be 
used in assistive applications for persons with disabilities, or point me to 
documentation?

The AXSections attribute returns an array of dictionaries, where each 
dictionary has three items with keys "SectionDescription", "SectionObject" and 
"SectionUniqueID".

As you can see from the examples below, I have run across a total of four kinds 
of unique IDs for AXSections attributes, so far; namely, AXContent, 
AXContentNavigator, AXTopLevelNavigator, and AXSearch. From these, and from the 
nature of the standard UI elements that are associated with them, I suspect 
that AXSections is a new attribute designed to categorize key functional 
sections of any application window into a very small number of core operations 
that are common to most applications. This could be used to help assistive 
applications guide users to the most important parts of any application window. 
(However, I don't understand why the AXSections attribute is marked as 
settable.)

For example, the AXSections attribute in a TextEdit window contains two array 
items:

SectionDescription = "content"
SectionObject = an AXUIElementRef object
SectionUniqueID = "AXContent"

SectionDescription = "top level navigator"
SectionObject = an AXUIElement object
SectionUniqueID = "AXTopLevelNavigator

A Finder window's AXSections attribute adds a third kind:

SectionDescription = "search"
SectionObject = an AXUIElementRef object
SectionUniqueID = "AXSearch"

An Xcode window's attribute adds a fourth:

SectionDescription = "content navigator"
SectionObject = an AXUIElementRef object
SectionUniqueID = "AXContentNavigator"

The AXUIElementRef objects are always standard UI elements that perform a 
function aptly described by the SectionDescription. For example, the AXContent 
item for a TextEdit window refers to an AXTextArea UI element, and the AXSearch 
item for a Finder or Xcode window refers to an AXTextField with a subrole of 
AXSearchField.

-- 

Bill Cheeseman - wjcheese...@comcast.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