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.
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" <jdgordy_at_gmail.com>
To: "Rockbox development" <rockbox-dev_at_cool.haxx.se>
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
> 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
> 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
> 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?
Received on 2007-06-05