I have an NSTableView in my app which has started to behave differently on
10.10.
I periodically change the datasource and delegate to the table view ( which is
on screen )
This has worked perfectly up until recently.
After having changed the datasource/delegate to the table view, I confirm th
On Sep 26, 2015, at 5:13 AM, Peter Hudson wrote:
> I have an NSTableView in my app which has started to behave differently on
> 10.10.
>
> I periodically change the datasource and delegate to the table view ( which
> is on screen )
> This has worked perfectly up until recently.
>
>
> After h
Ken, Thanks for this insight.
Reading through your comments, I suspect the best way to deal with this is to
switch entire table views in and out ( or, perhaps, deal with datasources ).
I’ll probably do it with table view swapping as this avoids setting up the
views with each change.
Regard
On 2015 Sep 22, at 19:51, Greg Parker wrote:
> But at some point the timer callback will provoke an OpenGL buffer swap, and
> that will block until the next retrace when vertical synchronization is
> enabled. The gated buffer swap inside the timer callback is the rate-limiting
> factor, not a
It has seem like a rule that has been in place forever that an application
pauses processing when the mouse is down on a menu. Is there a way to make the
application continue processing even with the mouse down?
___
Cocoa-dev mailing list (Cocoa-dev@li
On Sep 26, 2015, at 8:11 AM, Programmingkid wrote:
>
> It has seem like a rule that has been in place forever that an application
> pauses processing when the mouse is down on a menu.
System 1 through OS 9, not so much OS X.
> Is there a way to make the application continue processing even wit
On Sep 26, 2015, at 10:23 AM, Scott Ribe wrote:
>> It has seem like a rule that has been in place forever that an application
>> pauses processing when the mouse is down on a menu.
Why? It's not like all the threads are locked in a repeat loop.
___
> On Sep 26, 2015, at 7:11 AM, Programmingkid wrote:
>
> It has seem like a rule that has been in place forever that an application
> pauses processing when the mouse is down on a menu. Is there a way to make
> the application continue processing even with the mouse down?
No, that was only tr
> On Sep 26, 2015, at 9:51 AM, Jens Alfke wrote:
>
>
>> On Sep 26, 2015, at 7:11 AM, Programmingkid
>> wrote:
>>
>> It has seem like a rule that has been in place forever that an application
>> pauses processing when the mouse is down on a menu. Is there a way to make
>> the application co
On Sep 26, 2015, at 12:51 PM, Jens Alfke wrote:
>
>> On Sep 26, 2015, at 7:11 AM, Programmingkid
>> wrote:
>>
>> It has seem like a rule that has been in place forever that an application
>> pauses processing when the mouse is down on a menu. Is there a way to make
>> the application contin
> On Sep 26, 2015, at 10:03 AM, Eric Schlegel wrote:
>
> However, there are the usual ways around this:
> - an event loop timer (using NSEventTrackingRunLoopMode)
I guess that’s why I’ve never noticed that it blocked the main thread — my apps
never do anything on the main thread except in resp
On Sep 26, 2015, at 12:07 PM, Alex Zavatone wrote:
>
> On Sep 26, 2015, at 10:23 AM, Scott Ribe wrote:
>
>>> It has seem like a rule that has been in place forever that an application
>>> pauses processing when the mouse is down on a menu.
>
> Why? It's not like all the threads are locked in
On Sep 26, 2015, at 1:03 PM, Eric Schlegel wrote:
>
>> On Sep 26, 2015, at 9:51 AM, Jens Alfke wrote:
>>
>>
>>> On Sep 26, 2015, at 7:11 AM, Programmingkid
>>> wrote:
>>>
>>> It has seem like a rule that has been in place forever that an application
>>> pauses processing when the mouse is
> On Sep 26, 2015, at 10:51 AM, Programmingkid
> wrote:
>
> When I click on a menu, the application pauses. That seems pretty much like a
> smoking gun that things haven't changed much with the Mac OS.
“The application pauses” is a pretty vague statement. If you’ve got a periodic
task on the
> On Sep 26, 2015, at 10:55 AM, Programmingkid
> wrote:
>
> I think the reasoning for this is the user interface is expected to be
> responsive and if other processes are running, then the interface will be
> sluggish.
Not at all. All processes are always running — the OS has pre-emptive
s
On Sep 26, 2015, at 2:03 PM, Jens Alfke wrote:
>
>> On Sep 26, 2015, at 10:51 AM, Programmingkid
>> wrote:
>>
>> When I click on a menu, the application pauses. That seems pretty much like
>> a smoking gun that things haven't changed much with the Mac OS.
>
> “The application pauses” is a p
> On Sep 26, 2015, at 11:19 AM, Programmingkid
> wrote:
>
> I just wish there were an easy way for the a task on the main thread to
> continue to work even if the user is looking at a menu. Using multiple
> threads has a lot of problems associated with it.
Well, it kind of goes without sayin
On Sep 26, 2015, at 11:55 AM, Programmingkid wrote:
>
> I think the reasoning for this is the user interface is expected to be
> responsive and if other processes are running, then the interface will be
> sluggish.
That *WAS* the reasoning, in 1984 ;-)
--
Scott Ribe
scott_r...@elevated-dev.c
My app sets a custom tint color on the main window as part of its
initialization.
Later it creates a UIActivityViewController instance and explicitly set its
controller.view's tint color to the blue system tint color before having the
root view controller present it. I added this last piece in
On Sep 26, 2015, at 3:19 PM, Jens Alfke wrote:
>
>> On Sep 26, 2015, at 11:19 AM, Programmingkid
>> wrote:
>>
>> I just wish there were an easy way for the a task on the main thread to
>> continue to work even if the user is looking at a menu. Using multiple
>> threads has a lot of problems
> On Sep 26, 2015, at 2:28 PM, Programmingkid wrote:
>
> What is the right runloop mode to use?
Um, scroll back up to Eric Schlegel’s reply from earlier today, where he said
what it is. (I don’t have it in my mailbox anymore.) Something like
NSEventsAndButtonsAndMenusAndStuffRunloopMode.
And
In a OS X app, predating Grand Central Dispatch, in the main thread, I create
and start a new thread
NSThread* worker ;
worker = [[NSThread alloc] initWithTarget:instance
selector:@selector(beginWithInfo:)
object:info] ;
[worker
On Sep 26, 2015, at 15:33 , Jerry Krinock wrote:
>
> Should not -[NSThread start] always return before running any of my code in
> the new thread?
You have absolutely no control over it, unless you introduce your own
synchronization mechanisms.
The *earliest* it can return is before the new t
> On 2015 Sep 26, at 15:53, Quincey Morris
> wrote:
>
> On Sep 26, 2015, at 15:33 , Jerry Krinock wrote:
>>
>> Should not -[NSThread start] always return before running any of my code in
>> the new thread?
>
> You have absolutely no control over it, unless you introduce your own
> synchron
On Sep 26, 2015, at 16:49 , Jerry Krinock wrote:
>
> By “starter thread”, I presume you mean the one which is invoking -[NSThread
> start].
Yup.
> If what you are saying is true, how could we ever execute
> -performSelectorOnMainThread::: in a secondary thread without possibility of
> deadlo
25 matches
Mail list logo
