implemented custom themes folder prototype

[gchamon]

Following #1766, in this PR I propose a possible implementation for user defined colour schemes.

I placed the following JSON under $HOME/.config/guake/themes/snazzy.json:

{"Snazzy": "#28282a2a3838:#ffff5c5c5757:#5a5af7f78e8d:#f3f3f9f99d9d:#5757c7c6ffff:#ffff6a6ac1c1:#9a9aededfefe:#f1f1f1f1f0f0:#686868686868:#f5f58b8b7f7f:#f3f3f9f99d9d:#f3f3f9f99d9d:#a5a5c7c7ffff:#ddddaaaaffff:#b6b6fffff9f9:#fefefffffefe:#efeff0f0ebeb:#28282a2a3838"}

And I have it under the Appearances menu:

The themes however, won't get loaded untill a full restart. That could be improved, but I think this PR is a successful proof of concept and base for discussion.

Note that:

• multiple themes can be loaded in a single JSON. They are parsed as such and injected in PALETTES using object spread.
• as implemented, user defined schemes take precedence over build-in, allowing for overriding and customization

This also makes saving custom schemes / overriding existing ones over the GUI possible.

[gchamon]

I kind of want to see a button to the side of the themes dropdown that links to the custom themes folder

Good idea. I didn't want at the time to delve into the inner workings of the GUI to instrument the change, but it is only natural that the user should have the ability to change the folder to whatever is the most convenient.

This PR was an invitation for others to comment and evolve the idea of a custom themes folder. Since there is renewed interest in this feature, I can try to expand it and make it more like a production ready code.

Give me until the weekend and I can get back to you!

[Davidy22]

Rebased and copied some text into a starter release notes file for now so we can get a build status, there's some sections in the release notes that may change as things get added to this pr.

EDIT: Alright, build status in, we have deepsource feedback and lint results:

 guake/palettes.py:1067:13: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
guake/palettes.py:1071:16: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
guake/palettes.py:1073:16: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
guake/palettes.py:1075:4: W1201: Use lazy % formatting in logging functions (logging-not-lazy)

[Davidy22]

I did a quick run through to clean up the CI moans, just have the other bits to add to make this a full feature now.

[gchamon]

Thanks @Davidy22, sorry I couldn't work on it during the weekend. I will take a look at this as soon as I can.

[gsemet]

do you think this PR is ready to merge?

[Davidy22]

Still needs documentation on the themes format and themes directory, and maybe some UI additions too before this is ready to merge.

[gchamon]

I want to get to it as soon as I can, this week is a little busy for me

[superjamie]

I don't mean to hijack this PR but the current palette definition is not ideal for customizing.

As you note in your custom definition, the default palettes are stored as 16-bit #rrrrggggbbbb, however it looks like every theme actually just uses the 8-bit color space and the lower byte of each color is discarded.

For example, your first color #28282a2a3838 is actually the same thing as #282a38.

The latter 8-bit #rrggbb web format is much easier for humans to read, which is important for users writing their own theme files.

Guake uses Gdk.RGBA.parse() to get the actual color, which doesn't care if the color format is 8-bit or 12-bit or 16-bit:

https://lazka.github.io/pgi-docs/Gdk-3.0/classes/RGBA.html

So you can make a theme with 8-bit colors like so and it works fine:

    'Solarized Dark': (
        '#073642:#dc322f:#859900:#b58900:#268bd2:'
        '#d33682:#2aa198:#eee8d5:#002b36:#cb4b16:'
        '#586e75:#657b83:#839496:#6c71c4:#93a1a1:'
        '#fdf6e3:#eee8d5:#002b36'
    ),

That's also much easier for text processing of existing themes around the web, all of which are available in 8-bit HTML color format.

If you're still working on this then it would be preferable to document the colors as the 8-bit #rrggbb web colors. You could also make users aware they can use 12-bit or 16-bit color if they want.

It would also be nice to modify the existing palette definitions to all 8-bit color too. That would probably be suitable for a separate PR. I'm happy to look at that if there's interest in it (a few minutes recording a vim macro should do it).

[Davidy22]

If you have a revision that you want to make on an existing open pull request, you can copy the branch that the pull request is made from, add commits on top and create a pull request from your branch. If we merge yours then I'll close this pull request since it'll be redundant with the changes merged via your branch. This pull request has been quiet for a while, still have it open though since it looks nice and just needs a little more finishing.