hi..

> I suggested a loadable module apporach. I believe it should reduce CPU
> waste (no context switching, no extra job for X), bandwidth waste (no
> talking through X) and probably memory waste (less duplication of code).
> Aaron Seigo said this should not be a very difficult path.

in the open source spirit of "you say it, you do it", if this is indeed a 
desired approach i could supply the loader, base class for plugins and basic 
docus for creating plugins... i've done this on other projects and so have 
(GPLd) code kicking around that does this.. would just need some modification 
to be blackboxy =) ...

i would also need to know from the developers what parts of the bb API would 
be good to have exposed (if any)...

i've looked through the source tree for bb a few times in the past (and found 
it fairly clean and self-evident, kudos to the developers!) but haven't done 
any real devel on it, therefore input on the API exposure would be good so i 
don't do something silly...

of course, i could just tack on a loader and basic module/plugin class that 
we could extend (though every time we extend it we risk breaking binary or 
even source compat, depending on the changes; not that it really matters at 
the begining ... =)

i'd also assume that the config for the plugins to load would be done in the 
.blackboxrc file ... yes, no?

if so, what i'd probably do is in Blackbox::load_rc(BScreen*) i'd add checks 
for plugin requests that would look like:

bbplugin:pluginName: /path/to/plugin/pluginlin.so

it would then hand these off to a plugin loader (would keep this extremely 
minimal so overhead would be negligent) that would attempt to load the 
pluginName class from /path/to/plugin/pluginlin.so ...

anyways, if any of the devels say "sure go ahead" i can do this in fairly 
short order =)

/me opening his big mouth

-- 
Aaron Seigo

Reply via email to