Eric Davis wrote:

• Should we keep our current system where themes are customized CSS/JS/images?
• Should we start converting themes into full plugins (engines) so they can take advantage of those APIs too? (e.g. hooks, custom views, custom routing)

That would have a lot of advantages if done right, and "themes" could then rather be thought of as "mods" as you could potentially extend a few other things other than css/js/images. First thing I can think of: have a theme with different color schemes? Add a configuration page with a select box instead of duplicating everything but the colors in as many themes as you have colors. We'd have to be careful to not "overdo" it though so that making a "theme" would still be as easy as throw in css/js/images in the right folders, edit the init.rb with a title and an author, done.

One more advantage, even if it's a far off one: if/when we have plugin installation from cp, we can reuse it for the themes.

• Should we look into something like the theme_support plugin?

I don't know that one, care to elaborate?

Felix Schäfer wrote:

First thing I can think of: have a theme with different color schemes? Add a configuration page with a select box instead of duplicating everything but the colors in as many themes as you have colors.

That is actually a plugin I wanted to build. Few preset color schemes but with the option to override them to a make custom color scheme (and maybe even share that back with the community).

• Should we look into something like the theme_support plugin?

I don't know that one, care to elaborate?

Looks like it was replaced by themes_for_rails. Basic list of features for a theme:

• images
• JS
• CSS
• views - using ERB or liquid

Realistically it is: what ChiliProject has + view overrides. It would let us throw out our own "custom" code but I think having themes as plugins might be a better long term solution. Especially once more plugins are converted into gems (e.g. gem install chiliproject-red-theme...).

Eric Davis

Since I'm the kind of person who likes to have some things exactly his way or the highway I tend to do a bit of alteration of any product I use. Therefor I could really use to have themes being able to set their own views instead of me hacking away.

And if rubyknowledge is a problem it could use some sort of template system. But that might be a bit to much to add on.

I was thinking about themes the other day. If we convert them into Rails engines, then we can add some methods to the register block to let them add the CSS and Javascript to the head section automatically, like how themes work now. Images and other assets would be copied into public/ already by engines.

 1# Theme could be an alias of Plugin.
 2Redmine::Theme.register :some_theme do
 3  name 'Some Theme'
 4  author 'Eric Davis'
 5  url 'https://projects.littlestreamsoftware.com'
 6  author_url 'http://www.littlestreamsoftware.com'
 7  description 'This is some theme'
 8  version '0.2.0'
 9
10  css 'theme' # Would load assets/stylesheets/theme.css
11  css 'in/path/file' # Would load assets/stylesheets/in/path/file.css
12  javascript 'jquery'
13
14  requires_redmine :version_or_higher => '0.9.0'
15  # ...
16end

Basically these methods would build dynamic hook classes. But the declarations would be easier to document than showing how hooks work, especially for beginners.

Eric Davis