Closed mmower closed 9 years ago
Not at the moment. I see two separate, but related, things here:
profiles.clj
perhaps.Implementing the first - a user style sheet - would be pretty easy, and would be a nice idea I think.
How about a really simple approach: Look for a "user.css" file in the same folder as the worksheet file and load that as a user style sheet. Would allow for really quick customisation with no configuration.
That could be a nice solution. I wonder about per-project customisation vs. global customisation. I imagine one use case would be a different 'theme' that applied globally, like a dark background for instance. Another would be styling a particular project's worksheets differently. We should make sure the solution supports both of them.
One nice thing about configuring through lein profiles is that it gives a natural way to have system level config augmented/overridden by project level config. It's also worth noting that the implementation would be very cheap as the work of passing lein profile items through to the front end has been done already.
If lein profiles really are so easy then best to go with that since, as you say, it solves the problem of global vs. per-project customisation at a stroke and no use re-inventing the wheel.
Have implemented another way to bring a per-worksheet stylesheet. The stylesheet needs to be placed in a mirror of the path for the worksheet i.e. if worksheet is loaded from ws/sheet1.clj
the stylesheet should be saved at ws/sheet1.css
but in the the resources/public
folder in order to be loaded by the browser. So the full path would be resources/public/ws/sheet1.css
.
I got a little confused with the pull request, think I should have done two on separate branches. This feature is one of the commits in https://github.com/JonyEpsilon/gorilla-repl/pull/155
Again, ignore the changes to the project.clj file as it's for local development only.
The path matching might lead to problems if the namespace starts with any of the routes used by gorilla-repl or potential expansions that hook into the routing mechanism.
This was just a quick fix to allow custom CSS for individual worksheets. It could quite easily be stipulated that the css file must be in the css folder rather than directly in public. Would be a simple modification.
I think I'd prefer not to do it this way @jococo, as I think doing it through the Leiningen profile mechanism is cleaner. That doesn't allow per-worksheet customisation, just global and per-project, but I'm not sure per-worksheet is really a good idea. The only uses I can think of for per-worksheet is to support custom renderers, and I think that would be better served by having an API for renderers to add their own CSS.
The way I see it, it's like web pages. You can have shared stylesheets and localized styles. Both have their uses. For instance, someone may want to create several worksheets in a project and have the same renderers take on a different appearance on each worksheet. This patch doesn't inhibit the use of a per-project user stylesheet, in fact I think it would be most flexible to have both options available. That said, I wont be upset if you decide not to use this. I can keep the feature in my own fork.
When you put it like that, I think I agree with you!
I'm hoping to add some way of accessing resources from the worksheet, to support images in markdown segments (see #161 ). So it might be right to consider this in combination with that. I think the overall styling through a Leiningen profile is also useful (essentially theming), but I agree that this could be worthwhile too.
OK good. Do you want me re-submit my patch with the update enforcing use of the public/css folder?
I guess I'm still undecided on the utility vs. additional complexity of the per-worksheet styles.
Also, implementing #161, to allow the worksheet to load images in Markdown segments highlights that doing this breaks the worksheets in the online viewer. I think custom CSS (both per worksheet, and also the per-project and per-user options) will also suffer this problem.
So, my gut feeling is that we should let the idea bubble around for a bit more, and see how #161 works out, and whether there's a cleaner way to do all of this stuff.
Just a quick thought. Is there any drawback to simply embedding css into the markdown segments directly via html tags? Similarly css can be incepted by clojure renders.
On 22 Sep 2014, at 12:32, Jony Hudson notifications@github.com wrote:
I guess I'm still undecided on the utility vs. additional complexity of the per-worksheet styles.
Also, implementing #161, to allow the worksheet to load images in Markdown segments highlights that doing this breaks the worksheets in the online viewer. I think custom CSS (both per worksheet, and also the per-project and per-user options) will also suffer this problem.
So, my gut feeling is that we should let the idea bubble around for a bit more, and see how #161 works out, and whether there's a cleaner way to do all of this stuff.
— Reply to this email directly or view it on GitHub.
I think @ticking 's suggestion is the right one here, as it keeps the worksheets self-contained, and keeps things simple even though it does limit some possibilities.
Is there a way to customise the CSS used in worksheets?
For example I would like to call out the console text box used for out output.