Re: Scheduling functions to be run all the time in runloop

[Richard Frith-Macdonald]

On 10 Jul 2012, at 07:27, Dr. H. Nikolaus Schaller wrote:

> 
> Am 10.07.2012 um 08:21 schrieb Richard Frith-Macdonald:
> 
>> 
>> On 10 Jul 2012, at 06:20, Dr. H. Nikolaus Schaller wrote:
>> 
>>> 
>>> Am 09.07.2012 um 23:13 schrieb Ivan Vučica:
>>> 
>> 
>>>> They seem to be triggered whenever a "source is processed" and "before the 
>>>> run loop goes to sleep" - which sounds exactly like what I need. However, 
>>>> based on their name and the location inside Core Foundation framework, I 
>>>> presume that they are not implemented in this form in GNUstep.
>>>> 
>>>> So, is there an alternative way to insert my functions whenever a source 
>>>> is processed and before the run loop goes to sleep that works with GNUstep?
>>> 
>>> AFAIK, this is not available in GNUstep.
>> 
>> Sure it is ...
>> 
>> The Apple compatible method to do something in the next loop iteration is: 
>> -performSelector: target: argument: order: modes: 
>> The Apple compatible way to do something when the loop becomes idle is to 
>> use NSNotificationQueue
> 
> Ah, good to know. But it looks to be the OpenSTEP compatible way. Apple has 
> CFRunLoopObservers...

My blind spot ... I only think in terms of Cocoa/ObjC and never, ever use the 
old-fashioned C interfaces, so the CF stuff didn't occur to me.

>> 
>> And if you want higher performance/flexibility and don't need Apple 
>> compatibility, you might use the GNUstep extension -addEvent: type: watcher: 
>> forMode: as this allows your watcher to provide callbacks controlling 
>> how/when the runloop fires it.
>> 
>> All that being said, I would have thought that animation was something that 
>> you would want to do at regular intervals ... so using a timer would make 
>> sense.
> 
> From my understanding of the documentation of the CATransaction, he wants to 
> batch actions and commit (flush) them once when the system is becoming idle 
> (or at least could become). So it is the same mechanism as being used for 
> setNeedsDisplay and displayIfNeeded which does not occur regularily, but when 
> the system has time to do so.
> 
> This is why I think it should be integrated into the GUI system (Appkit or 
> UIkit or something else doesn't care).

I would have thought  using NSNotificationQueue with NSPostWhenIdle and 
NSNotificationCoalescingOnName would be ideal for this then ... whenever some 
work needs doing, you'd post a notification to the queue, and when the loop is 
next idle your notification observer would get a single notification ... 
perfect.