Prevent unneeded forks

[mikebell]

A lot of the forks for this project are fairly simple ones where a company is looking to add their own logo to the theme.

How about the following:

1. Check if logo exists at ~/.jenkins/userContent/logo.xyz
2. Replace #doony-title with img tags of url

The following code should be helpful since we're already using jQuery.

$.ajax({
    url:'http://localhost:8080/userContent/logo.xyz',
    type:'HEAD',
    error: function()
    {
        //file not exists
    },
    success: function()
    {
        //file exists
    }
});

[talios]

My local (non-github) fork simply changes the color of the top-panel. So maybe as well as the main doony.css - look for/load an optional a doony-override.css could be useful?

[kevinburke]

These are really good ideas. Maybe instead of specifying a bunch of files, look for a doony.json that contains links to a logo, a color for the top bar, etc.

[mikebell]

The json file sounds perfect, I've been maintaining my own personal tweaks in my fork but a central config file would be great.

I don't think a global override should be provided as there's potential for things to get really messed up (hell I actually hate CSS) but the json file gives people enough freedom to change the look without damaging overall usability.

[talios]

Could this be even better handled with the simple-theme plugin - allowing multiple CSS/JS files to be mentioned?

[kevinburke]

@tailos Yeah it could, but then everyone would need to update their Simple Theme dependency to get this to work, for example...

[kevinburke]

On second thought it's probably not good to go over the network to load a config before rendering something as simple as a header bar and logo.

What about a pre-compile step? Do grunt, etc support this kind of workflow?

[mikebell]

I really like the json idea, not everyone will have the tools installed on a jenkins server to pre-compile this stuff (I'm still fudging around to get grunt working).

Pros:

1. No additional tools required on the server to 'build' theme
2. Editable by cli editor of choice (vim ftw)

Cons:

1. Extra loading at runtime (cache browser side?)
2. Limited feature set (arguably by design)

[kevinburke]

Yeah... the idea was you'd install grunt on your development machine, pre-compile, commit the compiled changes, push and then install that on your development server. In theory you should be able to run make install watch and have it just work.

[kevinburke]

If you're having issues feel free to send anything over to me in the compiled files and I can run the compilation step myself.

[mikebell]

Preface - playing devils advocate here!

I'm not a js/ruby developer, I had no idea what grunt was until I saw it here and started googling it. Ideally I don't want to have to install a whole new tool chain just to configure something fairly basic (My tool set is a mixture of vagrant and php apps". Imagine this usecase:

Sysadmin Bob:

Boss: "Hi Bob Jenkins looks like a bag of ass can we do something about it?" Bob: "Sure" quick google of "Make jenkins not look like a bag of ass" Bob: "oooh Doony" Bob: reads install instructions, wut now, not on my server

A json config file is something that everyone regardless of skill level can quickly get up and running.

Maybe I'm over thinking the issue.

[kevinburke]

Hummm... these are good points. I'm not convinced that a JSON file is the way to go, at least one loaded via ajax after document.ready, because it would be so slow to load your logo etc.

The target will always be one JS file and one CSS file. Maybe leave doony.js and doony.css unminified, so people can edit those, and backport any changes to the build sources?

[mikebell]

How do browsers handle 404s in css?

We could expect there to be an image at localhost:8080/blah/logo.png and set sane defaults for size/background colour accordingly. On second thoughts that seems really dirty.

Ultimately I think your right. There should be two levels to using Doony, one is the bog standard it just works out of the box, the second is one where you have to put a bit of extra effort into configuring it. As long as the instructions are clear on how to get setup with the tool chain and configuration then it should be fine.

(I'm starting to think this should be a fork of simple-theme so all this can be bundled into package people can download and install inside Jenkins)

[talios]

On 8/10/2013, at 3:30 AM, Kevin Burke notifications@github.com wrote:

Yeah... the idea was you'd install grunt on your development machine, pre-compile, commit the compiled changes, push and then install that on your development server. In theory you should be able to run make install watch and have it just work.

This thread is about 'preventing forks', but reading this just sounds like continuing forks, with saying things "commit the changes", unless there's some context missing and the idea is to setup a NEW developer repository, that pulls in doony as an UNCHANGED dependency, for customisations, and -that's- the one that gets committed, and deployed to your jenkins server.

I could be missing something tho?

Mark Derricutt — twitter — podcast — blog — google+

[kevinburke]

@talios The thread title is a little misleading... we are trying to figure out the best way for people to add customizations like header color, logo, title without having to fork the project.

[kevinburke]

Some combo of a config file that's not checked in to source, or checked in with sane defaults and git update-index --skip-worktree will probably be the winner here.

[mikebell]

I'm just going to leave this here - http://r2.ayil.co.uk:8080/ ;)

I have the proof of concept working with the logo, I'd be interested to see what people think of the loading speeds. Also the compacted css is really annoying to work with!

[kevinburke]

@mikebell Oh no, ok... I will make a non-minified target for CSS as well.

[kyleconroy]

I think the answer is obvious: There should be an online theme creator for doony. It's just a simple website that takes customizations and does the grunt build on the server. Very similar to how http://stylebootstrap.info/ works for bootstrap customization.

[kevinburke]

@mikebell I added two targets - a minified one and an expanded one, so you should be able to edit the expanded one and get the data you want.

[rushi]

Maybe have an @import at the top of the css file? Like @import url(local.css) and it's upto the developer to put whatever he wants in there with !important so they can customize a lot more.

[kevinburke]

This project is big enough now that a plugin with fields for logo, colors etc. probably makes sense, instead of workarounds for such. Going to close this for now.