Add custom color schemes

[sebastianlay]

This thing fixes #418.

The implementation is based on the recommendations by @danrabbit in the corresponding issue:

• Doesn't require hunting around in a preferences dialog. We can add a ( + ) add the end of the list of color options in the popover we have currently. This could then throw a dialog that specifically and only manages the stored color schemes.
• Includes a preview so we can see what the resulting color scheme actually looks like
  This is not actually needed since the selected theme is applied immediately to the opened console.
• Labels the color selectors (of which it looks like only Tilix tries to do this)
• If we're really smart, we can do some color contrast checking and warn about color schemes that would be illegible. At the very least we should do this between the background and foreground color and make sure it passes the base A level

Additionally this implementation is completely backwards compatible in that it only manipulates the already existing settings and also recognizes the existing default configurations. This has the added benefit that third-party tools and scripts also continue to work.

This also includes an excessive number of predefined themes (194 to be exact) which were all taken from https://github.com/Mayccoll/Gogh/ and the color contrast check uses the code from https://github.com/danrabbit/harvey/

Open questions / calls for improvements:

• The ComboBox for for choosing a theme is pretty long and it can take a while to find the desired theme. Is there a better suited widget that allows keyboard navigation an/or search and/or autocompletion?
• The already existing color buttons modify the window theme and the console theme at the same time. Should it stay this way since there is now a way to set these two themes independently of each other?
• The data structure to hold the predefined themes in the Themes.vala is currently an ArrayList. I am pretty new to Vala so my question is whether there is a better data structure for this (something like a dictionary in C#, ideally with a find method) and a better way to initialize this (again something like collection initializers in C#)?

Screenshots:

The fourth button in the color menu that opens the color preference dialog:

The open color preference dialog with a default theme (and good contrast):

A theme selected that has poor contrast:

[danirabbit]

Hey thanks for working on this! This is looking really good and it's definitely a highly requested feature so I appreciate you tackling it.

I left some inline comments with some minor code cleanups and copy changes alignment etc.

I agree that the long combobox here is pretty unweildy. Perhaps instead of trying to include as many styles as we can find, it would be better to have some kind of import mechanism and stick with the same 3 default styles for now. Perhaps in the interest of getting this feature merged more quickly, we should reduce the scope of this branch to only supporting a single custom style and we can expand in later follow-up branches

I think a major interaction issue we have here is that if you ever switch away to another style, your custom style gets wiped. This seems like it would be pretty frustrating for someone who switches between styles. I imagine we should probably persist custom styles in gsettings. Maybe with a "styles" child schema, even if we only support saving one custom style for now

Yes I think we want to maintain the behavior of a style also setting the window chrome to dark or light. The quick style switcher should make it really easy to alternate between styles without having to fiddle with individual settings every time

[sebastianlay]

Hey! Thanks a lot for your review. I implemented almost all of your suggestions, see my comments above.

I agree that the long combobox here is pretty unweildy. Perhaps instead of trying to include as many styles as we can find, it would be better to have some kind of import mechanism and stick with the same 3 default styles for now. Perhaps in the interest of getting this feature merged more quickly, we should reduce the scope of this branch to only supporting a single custom style and we can expand in later follow-up branches

I would really like to include at least some predefined styles. I am pretty sure that many people would like to customize their terminal at least a little bit. On the other hand I assume that not all of these people (myself included) would put in the effort to enter an existing style color by color or even create a completely custom style from the ground up. Maybe reducing the number of styles to the 10-20 most popular (by some measure) styles would be a good compromise?

I think a major interaction issue we have here is that if you ever switch away to another style, your custom style gets wiped. This seems like it would be pretty frustrating for someone who switches between styles. I imagine we should probably persist custom styles in gsettings. Maybe with a "styles" child schema, even if we only support saving one custom style for now

Yeah, I am a bit torn about that. My thinking was that most people are not creating styles from the ground up and instead start with one of the existing styles and apply some minor tweaks to their liking. The way it is currently implemented allows that while also allowing the creation of a completely new style. I am not sure how we would allow both use cases if we would save the custom style. I am open to ideas!

[danirabbit]

@sebastianlay Hey sorry it took a while to follow up with a review here! This is looking really good. I think we can probably just try to get something in and iterate on it as we go.

I would really like to include at least some predefined styles

At the very least we need to make sure we actually have permission to redistribute any inluded styles. It doesn't look like the Gogh repo contains any licensing information and several of these styles do not have a license, so they should be removed unless you'd like to contact the authors and ask them to publish a license. There are also several styles included that don't pass the contrast check, so I imagine we should remove those as well.

[sebastianlay]

@danrabbit Hey, you are right. I trimmed the list down to 24 styles (including our three default and the one custom) and checked the licenses for the remaining ones:

• 3024 | https://github.com/idleberg/3024.tmTheme | Public Domain
• Dracula | https://github.com/dracula/dracula-theme | MIT
• Gruvbox | https://github.com/morhetz/gruvbox | MIT
• Monokai | https://github.com/stephenway/monokai.terminal | MIT
• Nord | https://github.com/arcticicestudio/nord | MIT
• Solarized | https://github.com/altercation/solarized | MIT
• Spacegray | https://github.com/kkga/spacegray | MIT
• Summerfruit | https://github.com/cscorley/base16-summerfruit-scheme | MIT
• Tomorrow | https://github.com/chriskempson/tomorrow-theme | MIT

If I understand it correctly, the MIT license should be compatible with the LGPL from this repo here, right? I am just not sure what the right place for the above list would be. Some sort of CREDITS file?

[Conan-Kudo]

For vendoring third-party styles into this codebase, a reference to the style, the commit it came from, and a copy of the license needs to be included for each vendored style.

You probably will want to make those styles able to be read from configuration files that are installed into somewhere in /usr/share so that the appropriate documentation can be included along with the style configurations.

[Conan-Kudo]

To give a bit more detail of how I suggest doing this:

• Break out the theme configurations into something like /usr/share/io.elementary.terminal/themes/<theme>/ directory
• In that directory, a theme.toml and LICENSE file would be present.
• The theme.toml file would include the actual style configuration and fields indicating where it was sourced from if it comes from somewhere else.
• The LICENSE file would be a verbatim copy of the license text from the original source. If the style is unique to this codebase, then this file can be omitted and the theme.toml can indicate that it's an original theme.

[danirabbit]

Hey @sebastianlay, since this seems to have gotten a bit stuck on the licensing bit would you be interested in merging a version of this without the color schemes so we can get this feature in and then bring back some pre-loaded color schemes in a future branch?

[sebastianlay]

Hey @sebastianlay, since this seems to have gotten a bit stuck on the licensing bit would you be interested in merging a version of this without the color schemes so we can get this feature in and then bring back some pre-loaded color schemes in a future branch?

That sounds like a good idea. I will give the suggestions by @Conan-Kudo a shot and if it takes me too long I will reduce the merge request to the custom color scheme.

[sebastianlay]

Okay, I will close this in favor of #552