ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

[Proposal] - ChiliProject Themes - an upgrade?

Added by Eric Davis at 2011-02-14 01:57 am

Right now ChiliProject themes consist of some custom css and images (and with commit 523febf9c1b31991fed52fe5878bec3153f8aafb, Javascript). I wanted to start a discussion about how we should handle themes from here on out.

  • 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)
  • Should we look into something like the theme_support plugin?

Personally I think we can do some really great things if we can standardize the themes. Especially if we can make them easier to build for non Rails developers. Thoughts? Any other ideas I haven't thought of?

(Fell free to brainstorm and dream a bit, I expect these changes won't start until around 2.0 which is 6 months away right now).

Eric Davis


Replies (4)

RE: ChiliProject Themes - an upgrade? - Added by Felix Schäfer at 2011-02-14 07:24 am

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?

RE: ChiliProject Themes - an upgrade? - Added by Eric Davis at 2011-02-14 11:14 pm

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

RE: ChiliProject Themes - an upgrade? - Added by Henrik Ammer at 2011-03-02 09:33 pm

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.

RE: ChiliProject Themes - an upgrade? - Added by Eric Davis at 2011-03-14 09:47 pm

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

(1-4/4)