GNOME Bugzilla – Bug 655030
Let the users to create his own color schemes
Last modified: 2021-06-10 20:15:33 UTC
Hi! I don't know, and I can't find it in bugzilla, if this was submitted. In gnome terminal profiles you can choose the colors palette, and there are some builtin schemes for this, but you can't add new schemes, you can only select a custom scheme that you must create manually, but you can save it to reuse it later. My proposal is to let the users in some way, for example via gconf/gsettings, to add new schemes, so they can save their custom palettes. Regards.
Valid. The inability to create and save custom color schemes results in hackish scripts for those who want to change these to something predefined (see the excellent https://github.com/sigurdga/gnome-terminal-colors-solarized color scheme) A "{Save;Load} color scheme" button in gnome-terminal's profile preferences dialog would be useful for this. The loadable file format could just be an ini-style config file containing Gsettings key/values pairs (restricted to those affecting gnome-terminal's color scheme)
Adding http://www.sharms.org/blog/2012/08/gnome-terminal-color-schemes/ for reference. These color schemes are very useful. Loading them through a simple "Load" button would be great, rather than relying on a script. Thanks
Created attachment 266056 [details] [review] Add Solarized color scheme nodiscc: Solarized is indeed getting quite popular. I'm attaching a patch that adds this scheme to the built-in ones.
Hi all, @egmont thanks for adding solarized. I have put together a hackish script that converts .Xresources/.Xdefaults color schemes to gnome-terminal compatible schemes, see https://github.com/nodiscc/scriptz/blob/master/utility/conversion/xresources-to-gconf.sh. There are a lot of nice color schemes out there, for example at http://dotshare.it/category/terms/colors/. Here is a list I curated myself: https://github.com/nodiscc/rxtx-linux/tree/master/build/config/includes.chroot/usr/share/rxtx/xdefaults. I no longer use gnome-terminal and won't take time to add patches, so I'm just leaving this here for reference. There's an utility to preview color schemes at https://github.com/clavery/xresources-html-tester cheers
@nodiscc Thanks for the additional input. The bug will remain open for the save-load feature, as it was originally requested. I don't want to add dozens of other color schemes. Solarized seems to be very popular and widely adopted nowadays rather than someone's one-off favorite. But other users can find your scripts useful.
Thanks for adding the Solarized palette. It was always a pita to do a manually. The Solarized palette doesn't seem to have a matching text and background colour build-in scheme, however. To get the Light Solarized scheme, selecting "black on light yellow" is closest, but it leaves you with a much higher contrast compared to e.g. Solarized in gedit. It would be good to have a matching text/background scheme available for Solarized as well.
Age: Thanks for your comment. I was wondering about this too (long after adding the palette) but then forgot about this. I'm not an expert on Solarized, but it seems to me that there should be two fg/bg schemes: "Solarized light" (bg: base3, fg: base03) and "Solarized dark" (bg: base03, fg: base3). Could you please confirm this?
Oops, I was wrong. Solarized light: bg: base3, fg: base00 Solarized dark: bg: base03, fg: base0 as per http://ethanschoonover.com/solarized#usage-development
Created attachment 274729 [details] [review] Add Solarized fg/bg
Comment on attachment 274729 [details] [review] Add Solarized fg/bg Committed. I intentionally didn't update the help in gnome-3-12 to reduce the chance of missing (fuzzy) translations in the stable branch.
(In reply to comment #8) > Oops, I was wrong. > Solarized light: bg: base3, fg: base00 > Solarized dark: bg: base03, fg: base0 > as per http://ethanschoonover.com/solarized#usage-development You are correct, those are the settings I set manually now as well. I also set the bold text colour to base01 for light, which should be base1 for dark.
As for bold text color, please see bug 728600.
Any chance that this will ever be fixed? Seems like something that lots of people have worked around the limitation with scripts, but that just seems wrong from a usability point of view. The problem with relying on Custom is that as soon as you want to 'try' any other scheme, you lose anything that Custom contained. Really would be good to be able to save/load these Custom themes.
I'm personally not planning to work on this. However, I'd be up for a design discussion, and maybe patches would be accepted. Christian? :-) I'm thinking of something along these lines: It would be great if there was a format and location to store terminal emulator color schemes that are independent of the emulator. For that, some cooperation between certain popular and actively maintained terminal emulators (e.g. tilix, xfce4-terminal, konsole, kitty, terminology) would be desired. The file could be an .ini (or .desktop) file, going something like [Terminal Color Scheme] Name=Solarized Dark Name[de]=Solarized Dunkel Background=#002b36 Foreground=... Color0=#073642 Color1=... ... There would be two locations, one system-wide and one per-user, confirming to XDG. And there could of course be ones built-in to the binary, as they are now. This approach would provide the easiest means of receiving color scheme definitions from others, and color scheme creators could even provide terminal emulator agnostic rpm/deb/whatever packages which you could just yum/apt/whatever install, and Linux distributions could even start shipping them. When you click on a certain button labeled Export or so, gnome-terminal would ask you for a skin name, derive the filename from that (e.g. special chars removed) and store the file with that name, obviously under the per-user directory. When you switch away from the Custom theme, gnome-terminal would warn you and offer to export. Since gnome-terminal stores all of its configuration in gsettings, I think it would copy the palette there. Upon opening the prefs dialog it would scan through the color scheme files to see which one matches the current values and show that name, falling back to Custom. This is what gnome-terminal does (khmm, intents to do: bug 774619) currently anyways. Other terminal emulators might choose to just store a pointer to the color scheme file in their settings, and even unconditionally always save the color scheme in a file without asking the user (the name could e.g. be derived from the profile name). As per comment 11 and the second part of bug 728600, we'd need to think more how to handle on the UI that certain themes would want to define more entries (e.g. fg/bg, bold color, cursor color, maybe even color16..color255) while others would want to define fewer (e.g. just the basic 16 colors). The color scheme editor of konsole allows you to pick 30 colors (normal, bright and faint for each of fg, bg and color0..7). This might be an overkill, e.g. VTE computes the faint one from the normal using a hardcoded algorithm. Plus, bright foreground only exists for legacy compatibility issue (the confusion around bold vs. bright), and I have no clue how bright background could ever be accessed. It also offers options of "random light background", "transparency" and "bg image". I guess this list should be continued with "bg image transformation" (tile, center, stretch to fill, stretch keeping aspect ratio etc.). For the latter ones, color scheme definitions could ship their preferred background images which would be taken from the same directory if referred to using a relative path. Sure not all terminal emulators would use all of these possibilities, but it would be great to have a consistent definition for the keys across terminal emulators. Does this direction sound feasible?
No objections here; sounds good to me :-)
Just as an additional data point, Tilix is using the approach outlined by Egmont and I have found it works very well.
One thing just occurred to me at https://bugzilla.gnome.org/show_bug.cgi?id=762247 which is the KDE counterpart of bug 774794: The "bold also means bright for legacy colors" setting (yet to be implemented) should also be shipped by the themes by default. E.g. Solarized requires this to be turned off, while for "legacy" themes it should be enabled.
(In reply to Egmont Koblinger from comment #14) > The file could be an .ini (or .desktop) file, going something like Turns out this is pretty much what konsole does. (The exact format of their .ini files, introducing a new section for each color, is insane though.)
The format isn't very nice I agree, but using it may outweight inventing yet another format [https://xkcd.com/927/]. Other choices: iTerm2's (plist XML), OSX terminal (plist, even worse than iTerm2 with base64 encoded data (!)), emacs (elisp), GIMP (text based), Putty (windows regedit), xfce4-terminal (simple ini file, perhaps more what you were looking for?). (Research based on https://github.com/altercation/solarized ).
(In reply to Christian Persch from comment #19) > xfce4-terminal (simple ini file, perhaps more what you were looking for?) This one squeezes all the colors into a single entry: ColorPalette=#073642;#dc322f;#859900;#b58900;... whereas konsole goes like [Color0] Color=0,0,0 [Color1] Color=178,24,24 Is everyone out of their minds??? Or is it just me thinking that the only sane choice is [Some header] Color0=... Color1=... ... ? :) > https://xkcd.com/927/ yeah, yeah, I know...
On a somewhat more serious note, another reason I wouldn't want to adopt konsole's format is that color indices 8-15 are named in the file as Color0Intense .. Color7Intense. Given our (well, at least my firm) opinion about the right direction out of the bold/bright (let alone faint) mess (see e.g. bug 762247, bug 791596), and also in the spirit of 256-color escape sequences, this is incorrect and they should be called Color8 .. Color15 instead. Of course this could be solved by some fallback mechanism from one keyword to the other. (And by the way a color scheme should be able to define entries all the way up to Color255.) Unfortunately konsole's development is quite inactive nowadays, xfce4-terminal is maintained actively. I'm wondering how much these folks would be up to designing a common format together (or adopt to what I design, haha).
(In reply to Egmont Koblinger from comment #20) > > xfce4-terminal (simple ini file, perhaps more what you were looking for?) > > This one squeezes all the colors into a single entry: > > ColorPalette=#073642;#dc322f;#859900;#b58900;... > > whereas konsole goes like > > [Color0] > Color=0,0,0 > > [Color1] > Color=178,24,24 > > Is everyone out of their minds??? Or is it just me thinking that the only > sane choice is > > [Some header] > Color0=... > Color1=... > ... Not just you :-) I also think that's what the format should look like.
So, konsole's reason for going with this syntax is probably this excerpt from their DarkPastels.colorscheme: [Color0] Color=63,63,63 [Color0Intense] Bold=true Color=112,144,128 [Foreground] Color=220,220,204 [ForegroundIntense] Bold=true Color=220,220,204 but (according to previously linked bugs) I believe this approach is wrong. They seem to have the philosophy that boldness is an (optional legacy) by-product of SGR 1 intense color, which approach cannot work as soon as you have more than 16 colors (and is already questionable when you introduce colors 8-15 using SGR 90-97). I believe the right philosophy is that intense color is an (optional legacy) by-product of SGR 1 bold. I couldn't seem to find any difference in boldness with this vs. other colorschemes in konsole, so either this "Bold=" option is broken, or defaults to true anyway. I see no reason for this to be a per-color entry rather than a global quirk, and I see no reason for a color slot to be able to define anything else than the color.
And Bold key is ignored since a long time ago, see [https://cgit.kde.org/konsole.git/commit/?id=61a8fd147dd4ed037d953b2982d12ed085d39baf] for [https://bugs.kde.org/show_bug.cgi?id=168300].
Tilix uses a json file for color schemes as shown in the link below. https://gnunn1.github.io/tilix-web/manual/themes/
> Tilix uses a json file for color schemes There's no json parser in standard c++ / glib, so it's out of question for us. IMO the ini file is more user friendly anyway.
(In reply to Egmont Koblinger from comment #26) > There's no json parser in standard c++ / glib, so it's out of question for > us. Yes, that's exactly why I would also prefer a keyfile based file format.
I've been thinking on this for a while, and (unfortunately) at this point I wouldn't want to change gnome-terminal's behavior. Easy and convenient saving/loading of custom color schemes is a rare feature request. Most people seem to be satisfied with the very few palettes we offer by default, and don't even request for more hardcoded ones (even though e.g. VTE-based Guake ships more than a hundred). Workarounds such as saving/loading dconf, or OSC 4/10/11 for redefining the colors, do exist. My biggest point is that I cannot see how such color definition files could work and result in a better overall user experience than our current UX. All-in-one color schemes (palette + foreground + background + other properties) would be useful for the relatively rare case of Solarized and possibly similar ones, but would be harmful for the other ones where the 16 palette colors and the rest (fg, bg) can be picked independently from each other, and that's what users would presumably want to retain. We should most definitely not go for a solution that improves a less frequent use case while degrades (or breaks) a more frequent one. It's unclear to me how a mixture of full and partial color schemes (some defining 16 palette entries only, some defining fg+bg pairs only, some all) could be presented on the UI and could result in a better overall user experience than our current one. What we could easily do, as long as the color schemes are built-in, is to warn the user on certain hardwired conditions (e.g. "For Solarized palette it's recommended that you pick one of the Solarized background and foreground colors", or "For Solarized it's recommended to disabled showing bold text in bright colors"). It's a hack I know, an ugly but low-hanging one. I'd love to move forward in non-hackish ways if we saw a design that's clearly superior to our current one (especially on the UX side), unfortunately I can't see one now.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7117.