|
Rockbox mail archiveSubject: Re: 1 standard generic callback systemRe: 1 standard generic callback system
From: Michael Sevakis <jethead71_at_sbcglobal.net>
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" <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 > 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 |