Urs Hunkler

Good documentation makes the work easier for theme developers/designers. Good documentation is also essential for theme quality.

By the way Sam, the documentation you have written in the Moodle docs wiki is really good. Thanks for that huge help to understand Moodle 2 themeing.

Having easily readable CSS is part of a good documentation. So please change the one liners to a human readable format.

Smashing Magazine published an interesting article how formatting supports understanding. "The Poetics Of Coding"

At your proposal to use a "theme" for adding special functionality sounds promising and strange in the same time.

After thinking about your proposal I discover that the way to use a parent theme as "plugin" comes very close to the way I am using the plugins within themes now.

Some questions:

• Is the config file and the pix folder with the icons enough for your icon parent theme? No other folders or files would be needed?
• What happens with routines in lib.php? Can they be used by child themes?
• Can custom renderers be used in child themes when they are defined and activated in parent themes?
• Can parent themes and child themes use all defined custom renderer methods no matter in which theme in the parent theme chain it is saved?
• Can child themes add methods to existing custom renderers defined and activated in parent themes?
• In which 'plugin' theme the possibly used construct method "function __construct( moodle_page $page, $target )" would be used? Must be in the first one? It can't be used twice, right?
• Is there a speed issue when I add lets say 12 parent themes for 12 different enhancements?

I wrote I find using themes as plugins "strange" because the word theme does not fit with the task of a plugin. A theme is and does much more than a special feature plugin. But this is a communication/terminology and not a development aspect.

Thanks Sam for your detailed explanations.

I didn't want to add additional places to search files. My proposal would be to set the theme folder as base and start each file with a path within the theme folder. In the moment each file type has a different fixed base folder:

• CSS includes now look like 'stylefile' :: after the change they can look like 'styles/stylefile' or 'myfolder/css/stylefile'
• JavaScript includes now look like 'myjs' :: after the change they can look like 'javascript/myjs' or 'myfolder/js/myjs'
• Image includes now look like '[[pix:theme|image1]]' or '[[pix:theme|subfolder/image2]]' :: after the change they can look like '[[pix:theme|pix/image1]]' or '[[pix:theme|notpixbutmyfolder/img/image2]]'

This solution demands a bit more typing for theme designers, no additional speed issues and the convenience to use a flexible folder structure which fits the theme needs.

And I think overriding in child themes still works.

And when I understand Moodle caching right file search is only done when a file is not cached. In normal production mode Moodle delivers the compacted files from the cache. This way the place where the files are originally saved does not matter at all.

Patrick - or anybody else - do you agree or disagree with my proposal?

Sam, if you may have some time can you please check and hopefully investigate into the topics I described.

Thanks a lot for your support and the fast reactions on last tracker issues I reported.