> On Sep 28, 2015, at 1:06 PM, Lee Ann Rucker wrote:
>
> I would really really like my NSStatusItem to be able to process whatever it
> takes to let it think my menu is a key window so I can process key events in
> the search field and the rest of the menu
Filed a bug, with a sample app to re
On Sep 26, 2015, at 10:03 AM, 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
On Sep 27, 2015, at 10:33 AM, Scott Ribe wrote:
> On Sep 26, 2015, at 12:19 PM, 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 ass
On Sep 26, 2015, at 12:00 PM, Programmingkid wrote:
>
> I did try using a separate thread, but that caused part of the application to
> stop responding to events.
A background thread will *not* cause your application to stop responding to
events. You need to go back and look more closely at w
On Sep 26, 2015, at 12:19 PM, 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.
A simple way to interleave execution of t
> 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
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 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
> 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 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 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 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 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 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 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: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 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 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 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 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
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
21 matches
Mail list logo
