Hi,

I'm in agreement with what we've captured in Mark's and Daryl's summaries.

Fabien's post made me think quite carefully about the scope of a theme and how this works with component plug-ins. I think there is a difference, which will force us to leave some theming bits in each plug-in package rather than in the core output 'theme'. I've tried to illustrate this in the following scenario:

We have identified the following plug-in types (amongst others): components (= interactions) and themes. We ought to make it possible for the community to write each of these types in isolation, ie. developer A could write a new 'rounded edges brown / wood effect theme' (bad example, I know), while developer B might write a new multiple choice type interaction.

Either should be able to work in isolation of the other and the new MCQ should be able to take the basic styling from the new theme plugin without the developer knowing that this even exists. Naturally, the interaction component would still need some CSS / styling, which would be embedded in the component package.

Likewise, a theme should work without having to deal with all possible component plug-ins, especially once we have a community codebase (with millions of great plugins :-).

I therefore think the key thing would be to determine the scope of the core theme and how this applies to an interaction plug-in and also package some CSS etc with the plugin itself - but have a well documented interface between the two and guidelines on how to code either.

Hope this makes sense. Thoughts welcome!

Sven