Allow user-defined themes

[fonsp]

Perhaps using #6

[fonsp]

See the suggestion in #139

[TheCedarPrince]

Mind if I spend some time on this trying to get this implemented @fonsp ?

[fonsp]

Actually, I was planning on changing the CSS structure to make custom themes a lot easier. The remaining questions are mostly:

• where should the custom theme be stored?
• how should Pluto know about a custom theme (I'm thinking ENV)
• how is it inserted into the DOM?
• what is a theme? just cell output? UI?
• are multiple themes allowed to combine?

And very important:

• will it slow down future UI development?

[TheCedarPrince]

Ah gotcha! My thoughts to your points:

1. I think we shouldn't worry about where custom themes will be stored. I would think the best way to handle it would be to provide in endpoint that allows users to give a path to exactly where their stylesheet is stored. Perhaps we could make a sort of permanent Pluto config file where someone could specify the path to their stylesheet without having to continuously redefine it?

2. Hmmm... Do we want the same resource file for everything Julia related? Or modularize it specific to Pluto per my thought on point 1. I do like this idea a lot however.

3. I think your question about what is a theme is best discussed in conjunction with the question about how it is inserted into the DOM. My thinking is that it could be up to the user -- I don't think that is something we should worry about defining. Plus, I think the open ended nature of what we mean by a theme and the creativity of users could make some very magical things.

4. Hunh. Multi-themes. Again, I think we should leave that to the user to determine. I think it is a good idea but maybe not something we should decide for them.

5. My thinking is that by giving users the ability to create custom themes of any nature, we should not try to conform to themes people are creating. I think we should continue creating the UI as we see fit, but that we should be very clear about any changes that we make which may impact themes.

What do you think? Are you working on a PR right now that I could assist with? Thanks! :smile:

[fonsp]

3 & 4 & 5: I agree!

1: I have an idea! Custom themes (and other addons) must be a URL. People can use GitHub gist or similar to publish and share their themes, and Pluto doesn't need a 🌈🌈 Pluto extensions marketplace 🌈🌈 and you don't need to touch your file system to add themes.

2: Pluto doesn't have a config file and it should stay that way I think, but if all themes are just URLs, it can save those in your browser's local storage (just like your recent notebooks).

_(To develop a theme locally, you would have to put it in /assets while you work on it, or we can add a second dir like /custom_assets that is accessible from the web page, which is .gitignored, i.e. you can add stuff in the folder without worrying about git changes.)_

Another solution is to not do any of this, and make browser extensions the way to customize Pluto. I think that this is the coolest way, were it not that browser extensions are fixed to one browser, and there is some learning curve to creating a super simple one. But maybe there is a browser extension out there that just lets you write custom CSS for specific addressed - that could work. (Or we could make one - a browser extension that does 1 & 2, but for any web domain.)

[fonsp]

This exists! It's called Stylish and works across chrome and firefox and they have a marketplace to share styles publicly.

So here you would write a CSS script, and apply it to localhost (or even a regex that is more specific).

Here it is in action:

[TheCedarPrince]

Hey @fonsp ,

Lots of fantastic thoughts here! I spent some time thinking about this issue further and here is what I concluded:

1. I really like the idea of a simple URL. I think we should go this route! Or even go along with what OhMyZSH did with giving a bunch of pre-bundled themes to the user.

2. I agree with not having an additional config file. However, I could see potentially having one for development work (though, I think this is unrelated to the current issue).

3. In respect to custom assets, I think that is a great idea and we should implement it. I think themes can be more than just styling as they could also be additional functionality.

In respect to 1 and 3, I think this gets back to the bigger discussion about perhaps making some sort of Pluto Organization and have a core website underneath that. I'd love to help with making that a thing at some point soon.

The one problem I do have with the user styles is that if we have them stored in the browser, will CSS changes persist to the export of a PDF? And if so, a bigger discussion is when/if we can make Pluto deployable to a webservice for web based hosting, can themes apply there as well? These thoughts may be beyond the scope of this issue, but they might be important to think about for long term!

[TheCedarPrince]

P.S. Regarding Stylish, does something like that go against Pluto philosophy? It would mean adding an additional step/dependency to worry about. I get the idea, but it makes me anxious having a third party be responsible for our theme idea.

P.P.S. I am ready to work on a PR whenever we can figure out something to do here! :smile:

[fonsp]

There is also a (more?) open source version of Stylish: Stylus. Both Sylish and Stylus can work offline - so it is not a dependency on a third party to remain operational - but it does feel hacky.

The thing is, having any customization is a bit against the up-until-now Pluto philosophy (which is full end-to-end control).

Style changes (no matter the method) make it into the PDF (try it!), but not to .html/web exports.

[fonsp]

Another way would be:

one ENV item: PLUTO_ADDITIONAL_ASSETS which is a (by default empty) array of URLs, that just get added to editor.html when you load it.

The ENV variables are more flexible than you think:

import Pluto; ENV["potato"] = "yes please"; Pluto.run()

or for the purists:

import Pluto; withenv(Pluto.run, "potato" => "yes please")

ENV is already used for some secret config options, so it makes sense to use it for this. All shell systems have built-in ways to store ENV variables permanently.

So this would set a theme for all connected clients. As opposed to the web extension method, which would set the theme just for yourself and the PDF, but for all Pluto sessions. Both have their advantages?

[fonsp]

(I'm thinking of something fun for you to work on!)

[TheCedarPrince]

I think we should pursue the ENV way first as I think that makes the most sense and easiest to implement. What do you wanna do next?

But true, actually, do you think we could discuss the Philosophy of Pluto? I don't really see it on the main README (though from conversations from you, I understand the gist of it) and I feel like having the philosophy be more up front is important for future contributors. Thoughts there?

[fonsp]

Well, Stylus has already been implemented 🙃 You could use it today to write new themes, and any CSS you write there is still usable if we ever change the way they are loaded. (But again - I was planning to change the CSS structure, so writing a theme right now would be counterproductive.)

It's just that I am not motivated to solve this issue soon 😬 Besides a dark mode (which could be built-in and automatically match the system theme), there have been no user requests in this area. (And of course, I am personally quite happy with the default theme.) So any solution that adds a config or makes the project less end-to-end controlled, makes me scared.

Lots of negative sentiment here, but my main point is that there is lots to do that does make me excited, and it is very important to keep the project easy to maintain.

As for outlining the Pluto philosophy - I prefer not to write down my own ideas on this as if they are rules, although I understand that this makes collaboration a little trickier. Discussions are welcome and useful!

[TheCedarPrince]

Ah that makes a lot of sense! Want to go ahead and close this issue for now?

[radonnachie]

I'd love some control over the theme and default layout.

Perhaps what would fit your preferences is an aftermarket script such as jupyter-themes that would just overwrite Pluto's CSS. I'm assuming that that is what jupyter-themes does, although not 100% certain.

As an aftermarket script, it is up to the maintainers of the script to ensure some adherence to Pluto's design intention. So I believe its community members are close at hand.

In a month or two I will probably get back to this idea!