Re: LiMux student "kick-off"

Hi Florian,

On Wed, 2014-09-24 at 14:18 +0200, Florian Haftmann wrote:
> From a bird's-eye perspective, this would IMHOP consist of the following
> tasks:

        I love your breakdown =)

> * Identify the hot-sport where events are announced.

        Sure - so, this is a matter of looking for finding / documenting all
'Timer' sub-classes.

> * Formally extend this interface with a priority parameter with not-yet
> a meaning.

        Sure - so, what I'd do is create a 'Idle' class - initially derived
from Timer (I guess), and start to add a series of #defines or similar
to give each an integer priority [ leaving some nice spaces ]. Then
inside the Timer class map that back to the ~awful '35ms is low
priority' '50ms is after that' etc. ;-)

        Of course, -some- things we may actually want to do inside a timer -
eg. blinking the cursor =) for this we really want a 'TimerSeconds'
sub-class that moves the timeouts to a second boundary: this is
important for reducing power-use: so the CPU wakes up once per second
sharp on the transition, and does as much work as possible before going
back to sleep =) [ we're missing that concept sadly - for now just
stub / wrap that ]. Our cursor should blink either once-per-second or
every half-second I think to get the benefit there.

        Having done that I hope we are back where we started - but we have a
nice series of priorities for these various things.

> Any comments or hints?  Otherwise I guess the first item is the one to
> start with.

        I think we missed some unit tests =) it'd be great to create some of
these too particularly for Timers - which we've just re-worked on
Windows to make them might higher resolution.

        Personally, I'd do the API work as described above first - then take a
long hard look at it =) before starting to work on the implementations
of prioritized idle handlers in the backends. Of course - we can detect
if the backend can do the priority foo (should be easy for glib users
eg.) and if not use the fall-back 'orrible hard-coded times.

        Perhaps that gives a good, incremental path to go so commits can go to
master, and we can keep everything working ?

        Anyhow - thanks for the investigation, a good plan;

        HTH,

                Michael.

-- 
 michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot