Would it be possible to group the color themes into "light" and "dark"? Either as two columns in the theme selector or as two sections in the list.
Background: Lately I've been getting irritated eyes frequently and was suggested that this may be due to staring at a bright screen for extended periods of time, so (in addition to adjusting the brightness) I decided to give dark themes a try, since I heard they are less harmful for your eyes (not sure how scientific this is, but trying won't hurt...) Problem is, it was hard to compare dark themes by going through the list with arrow keys, because light and dark are interleaved, and whenever I hit a light theme my eyes would readjust and forget if the previous dark theme was better or worse than the next. So I think being able to browse only light or only dark themes would make the choice easier.
(This leaves open the question: "how do you decide if a theme is light or dark automatically?" -- I guess probably looking at the default background and foreground colors, but comparing color brightness is a bit tricky...)
(This leaves open the question: "how do you decide if a theme is light or dark automatically?" -- I guess probably looking at the default background and foreground colors, but comparing color brightness is a bit tricky...)
Yes, that was never resolved in previous discussions.
Even simply adding "-light" and "-dark" to the colour scheme name would be useful, but it needs to be agreed and applied consistently. Then light and dark themes should sort side by side and be obvious which is which. Or adding "dark-" and "light-" to the start of the name will sort them in blocks. So let the :bike: :house: begin ... :grin:
I would also recommend getting your computer glasses checked (makes note for self to do so ...).
Even simply adding "-light" and "-dark" to the colour scheme name would be useful, but it needs to be agreed and applied consistently.
If going that way, there might just as well be a `[theme_info] mood=dark` property... Otherwise, maybe a very simple and naïve test such as "check if `named_styles.default[1]` starts with a number"[^1][^2] could work for unclassified tests (except for some corner cases. It works for every colorscheme in [geany_themes](https://github.com/codebrainz/geany-themes/tree/master/colorschemes) at least.) But I can see how that may end up going down a rabbit hole of corner cases. (Or if it won't cause much trouble, actually compute and compare foreground and background luminance using a simplified R'G'B'→Y formula; but I suspect that's asking for a lot). [^1]: More precisely, check whether it starts with #+number, or if it starts with a letter (named color) and `named_colors[named_styles.default[1]]` starts with #+number. [^2]: Here I am naïvely assuming that a light theme won't use a color with a low R value but high G and B ones, like #9FFFFF.
So let the 🚲 🏠 begin ...
OK, I give up :smile: "Let the ride home begin"? "Let the cycle building begin"?
I would also recommend getting your computer glasses checked (makes note for self to do so ...).
I don't use glasses. Not yet at least. Maybe I should get checked to see if I should...
[theme_info] mood=dark property...
This and the other suggestions involving file contents require all the colour scheme files to be opened and read to get the information before displaying for user selection, probably not going to happen, hence my suggestions that rely only on filename and which can use default alphabetic sort order to group.
🚲 🏠
[bikeshed](https://thedecisionlab.com/biases/bikeshedding) in this case a discussion of what the colour scheme filenames idiom should be :grinning:.
require all the colour scheme files to be opened and read
oh wait, that already happens, shows how long since I opened the colour scheme dialog :grin:
So ok, a setting like `mode=dark` is possible, but needs code changes to support it, using a setting also complicates sorting (which happens by filename).
oh wait, that already happens, shows how long since I opened the colour scheme dialog 😁
Yeah, I was going to say that; the color choosing dialog already shows you the name (not filename) and description of the theme, so I thought that also reading a `mood=` line wouldn't hurt. It's a big and annoying change anyway (all third-party themes would need to be upgraded or risk not being correctly classified), hence why I thought there should be some fallback way to detect the type. (In fact, the main use of `mode=` would be for cases where the fallback way gives false positives.)
So ok, a setting like `mode=dark` is possible, but needs code changes to support it, using a setting also complicates sorting (which happens by filename).
Maybe a checkbox like "Show only: [x] light themes, [x] dark themes" is a better idea in that regard (exclude/hide non-matching themes rather than reordering them). It'd also "gracefully deal" with themes that are neither explicitly light nor dark (they just won't show up when either or both options are selected, rather than needing to put them on a "third category" or having to guess their type).
🚲 🏠
[bikeshed](https://thedecisionlab.com/biases/bikeshedding)
Oooh OK, that was tricky :) Yeah, I agree that relying on a naming scheme is probably not a good idea, and a potential source of disagreement. Plus, it would mostly only work for themes that have a light and a dark version; otherwise I wouldn't expect "light" and "dark" in the name.
a mood= line
What about `mood=grumpy` for me ;-P
As a comparison I looked at the theme app of my desktop (cinnamon) and its much the same as Geany, shows the internal name and description and not the filename, for the the distro provided themes the name matches the filename _name_ and _name_-dark eg `mint-y` and `mint-y-dark`, but for third party themes its like Geany, and most do not seem to distinguish if they are normal or dark.
The problem with filters is that then some colour schemes are hidden, and if random ones are included in both thats confusing and both cases are prone to bug reports.
So I'm leaning more towards sorting not filtering, and that leads back to using the filename as the simple approach. The advantage of using structured filenames is that the current alphabetical sort can be utilised to get a suitable ordering, the only PR is one renaming the files in geany-themes, no programmers needed. And random schemes will always show up, alphabetically.
What about `mood=grumpy` for me ;-P
Dunno; I thought "mood" was a better word for it, as in "vibe" or "atmosphere". (It isn't really a "mode" in that it doesn't affect how the rest of the app operates; just an "artistic style", and I thought that word was fitting.) Could be called `style` or `type`, or simply `dark=true|false`.
_name_ and _name_-dark eg `mint-y` and `mint-y-dark`
Yeah; I guess one workaround could be to search for "dark" in the name, or for each name, see if it has a matching "dark" or "light" counterpart, but I don't think it'd be too reliable.
The problem with filters is that then some colour schemes are hidden
My idea here was to make the unspecified ones show up when neither "light themes" nor "dark themes" were selected (i.e., when not filtering); the default would be to show all themes together. And if you filter by style THEN only show those explicitly marching the style.
So I'm leaning more towards sorting not filtering, and that leads back to using the filename as the simple approach.
I... am not too convinced by the idea of having all themes named `dark-*` and `bright-*`[^1]; feels a bit repetitive and unreliable. But it's true that it'd be a trivial way to group related themes together, without explicitly implying that they're grouped together BECAUSE they're light/dark themes; just an "intentional side effect". And an inexpensive change. I don't know; I think I'd prefer some way to sort by "actual brightness", either explicitly stated in the file or computed from the values, rather than implied from the name. Or that's what I had in mind at least. [^1]: Using "bright" and not "light" so that it collates before "dark".
github-comments@lists.geany.org