dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: 1 standard generic callback system

Re: 1 standard generic callback system

From: Michael Sevakis <>
Date: Tue, 5 Jun 2007 16:10:24 -0400

I really think it's best to avoid a separate callback function for each
particular things and instead just go with an interface model that groups of
related callbacks and functions. If you want audio events, provide a pointer
to some sort of audio events interface. Any receiver of events can just
ignore what it doesn't care about and a tendency towards a single call with
an event id parameter and an intptr_t parameter to pass data or pointers to
data can keep the number of functions to a minimum. Some more specialized
functions in the interface can be declared if needed of course.

struct xxx_something_something
    intptr_t (*function)(int ev_id, intptr_t data); <== standard fare
    rettype (*function2)(params.......); <== something more specialized

Not really much different than having the plugin api structure. Just
register the structure pointer with the caller of the callback.

Having set_xxxx_callback for each particular event or callback doesn't
really address clutter imo but then maybe I like C++-like stuff to much.
IIRC GCC can have C structures with constructors. :P :D

----- Original Message -----
From: "Jonathan Gordon" <>
To: "Rockbox development" <>
Sent: Tuesday, June 05, 2007 10:32 AM
Subject: 1 standard generic callback system

> hey all,
> so, in IRC we somehow got onto the problem that the filebrowser needs
> to know when a track changes (so the follow playlist can work
> properly), and scrobbler and database also need to know when this
> happens.
> playback.c has a few callbacks but only allows one function to be
> registered for each, which causes a bit of a mess in playback.c (and
> is one reason why scrobbler is broken on hwcodec.)
> My attached patch addresses this issue, by taking the existing
> ata_notify_callback code and extending it so functions are registered
> as callback for certain events.
> so, what would happen is database, scrobbler and tree would all
> register individual callbacks on the PLAYBACK_TRACK_CHANGED event,
> then playback.c (or mpeg.c) would call call_event_callbacks() with the
> PLAYBACK_TRACK_CHANGED event id and some known data which would then
> call each registered function (for that id).
> Firstly, my reasoning for having a seperate module for this is so
> playback.c doesnt have the extra clutter which just makes it more
> difficult to work in then it already is, It makes adding more
> callbacks for an event very simple, and hopefully makes the code a bit
> smaller if this is current used in a similar way in other parts of the
> code?
> The reason for the event id and a single array for the callbacks is
> that it wastes less ram than having a seperate array for each event
> group.
> At the moment, all this patch does it replace the existing ata
> callback stuff with this, it doesnt touch playback yet. I just wanted
> to get this out and hopefully get some feedback on weather this is
> good or not?
> Also, which other events would be usefull to add?
> Questions, comments?
> cheers,
> Jonathan
Received on 2007-06-05

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy