On Fri, Nov 21, 2008 at 11:46 PM, Sam Spilsbury <[EMAIL PROTECTED]> wrote: > I'm posting here to let you all know that a big elements plugin > rewrite is coming up. > > For those of you who don't know, 'elements' was a plugin written by > PatrickFisher about > a few months ago which was an attempt to bring together all of the > arbitrary particle > movement plugins to form one big plugin which is managed by itself. > The idea is a good > one, however I was concerned with the implementation of it (as it > currently stands) and > also the fact that it hasn't been updated in a few months. Now that we > have extension plugins, > this gives me a good oppurtunity to make elements more flexible and > modular as well as > learning the extension plugin system while cornelius and I work on > animation in the future > (hopefully). > > Here's what I plan to do, hopefully within the next 2 weeks: > > * Right now, all the snow, fireflies, stars code is too tightly > integrated. I am currently modularizing > this out into separate functions for each movement pattern. Some > movement patterns even use > the same variables! (For example, bubbles uses the 'AutumnSway' > variable, which is clearly wrong > according to coding practice) > * I also aim to have a generic function ABI, so that each element > extension plugin can have a function > table with a bunch of function pointers to generic functions (move, > intiate, step etc). > * Export compiz-elements.h (duh) > * Much like compiz, for an element allocated to an extension plugin > (one element per plugin), they > attach their own structure to the 'ptr' variable in the struct, > allowing them to save data and calculate > X/Y/Z values more easily > * Extension plugins in compizconfig for elements would be rather easy, > just export the element movement > pattern as a restricted string base_option to a selection box (much > like animation) > * Multi-List settings: Element movement pattern and texture path would > be our two options (perhaps a > speed factor too? Discuss please =) ) > * Clean up code to make it more compiz-like. Right now, it's rather > non-conforming =) > > This is what my ideas look like for now, please discuss. I have > already started working on this. > > -- > Sam Spilsbury >
OK, I've made some fair progress with this. The plugin is currently hosted at git://git.compiz-fusion.org/users/smspillaz/elements-extensible. The work of I have done so far is: * Modularize out the movement mode into movement functions for each separate element * Remove the individual toggle bindings for each element, instead there is a 'cycle-through' approach as in colorfilter. * Refer to elements by a string, not an int * Created new structure, ElementsAnimation, which handles the element type and elements within it so that we can have multiple animations of the same element * Added multi-list to cycle through using actions as stated beforehand * Created ElementTypeInfo struct, extension plugins register a new type with function pointers to element initialization, movement, and cleaning up functions for each respective element * Call those function pointers instead of calling each separate function for each element. * Not a trace of hardcoded element reference to jumping or moving execution of code (I hope) * Compiz coding style (mostly) Things I still need to do: * Make private structures for elements [DONE internally] * Latch on those private structures to the 'Element' type on element type initialization * Create fini functions for element types * Add ability to have multiple textures that cycle through every X repaints * Add a popup (via text) to show the element pattern being used and also the texture(s) when hitting the 'next', 'prev' or 'toggle' keybindings. * Fade out elements as they are untoggled. Please give me any input. My hope is once this is cleaned up, it can obsolete the 'snow' plugin and go into plugins-extra. -- Sam Spilsbury _______________________________________________ Dev mailing list [email protected] http://lists.compiz-fusion.org/mailman/listinfo/dev
