[FEAT] Color options based on the desktop wallpaper (or a custom list) #390

Closed
opened 2026-01-05 14:50:18 +01:00 by adam · 5 comments
Owner

Originally created by @CtByte on GitHub (May 23, 2024).

Is your feature request related to a problem? Please describe.
Since there are more and more visual additions to komorebi (such as the borders, stackbar, gui and the upcoming bar), the user has the option to pick colors to customize them.

I am not so keen on picking my colors, and in general, these ui elements look their best with matching colors to the desktop wallpaper.
This means that whenever my desktop wallpaper changes (slideshow), the colors I picked can look out of place.


Describe the solution you'd like
Generate a set of colors based on the desktop wallpaper.

I am working on a solution that does just that. I find the desktop wallpaper and auto-generate a list of colors based on their occurence.
I would be thrilled to have this included in the project as I alluded to my relationship with colors.

I am new to Rust, but my understanding is that there is a way to implement different ways to specify colors.

Currently RGB and Hex formats are supported. I propose a new way that can pick from a list of colors as well (naming is to be decided).

  "active_window_border_colours": {
    "single": "#cba6f7",
    "stack": {
      "r": 255,
      "g": 165,
      "b": 66,
    },
    "monocle": {
      "wallpaper_color_index": 2
    }
  },

I think it would also be nice to have a list of custom colors defined in the config that can be set in one of the 3 ways.

It would make theming a bit nicer to manage (the colors could also be named, instead of using the index. I am not sure).

  "colors": [
    "#cba6f7",
    {
      "r": 255,
      "g": 165,
      "b": 66,
    },
    {
      "wallpaper_color_index": 2
    }
  ],
  "active_window_border_colours": {
    "single": { "colors": 0 },
    "stack": { "colors": 1 },
    "monocle": { "colors": 2 }
  },

I imagine the gui to list these colors in some way (can be edited using a color picker).

I have something like this so far:

Screenshot 2024-05-23 082539

Describe alternatives you've considered
I pick the default colors, perhaps matching the windows ui instead.


Additional context
As I mentioned, my solution is a work-in-progress, but I wanted to know if this would be something that piqued anyone's interest.

Originally created by @CtByte on GitHub (May 23, 2024). **Is your feature request related to a problem? Please describe.** Since there are more and more visual additions to komorebi (such as the borders, stackbar, gui and the upcoming bar), the user has the option to pick colors to customize them. I am not so keen on picking my colors, and in general, these ui elements look their best with matching colors to the desktop wallpaper. This means that whenever my desktop wallpaper changes (slideshow), the colors I picked can look out of place. --- **Describe the solution you'd like** Generate a set of colors based on the desktop wallpaper. I am working on a solution that does just that. I find the desktop wallpaper and auto-generate a list of colors based on their occurence. I would be thrilled to have this included in the project as I alluded to my relationship with colors. I am new to Rust, but my understanding is that there is a way to implement different ways to specify colors. Currently RGB and Hex formats are supported. I propose a new way that can pick from a list of colors as well (naming is to be decided). ``` "active_window_border_colours": { "single": "#cba6f7", "stack": { "r": 255, "g": 165, "b": 66, }, "monocle": { "wallpaper_color_index": 2 } }, ``` I think it would also be nice to have a list of custom colors defined in the config that can be set in one of the 3 ways. It would make theming a bit nicer to manage (the colors could also be named, instead of using the index. I am not sure). ``` "colors": [ "#cba6f7", { "r": 255, "g": 165, "b": 66, }, { "wallpaper_color_index": 2 } ], "active_window_border_colours": { "single": { "colors": 0 }, "stack": { "colors": 1 }, "monocle": { "colors": 2 } }, ``` I imagine the `gui` to list these colors in some way (can be edited using a color picker). I have something like this so far: <img width="1213" alt="Screenshot 2024-05-23 082539" src="https://github.com/LGUG2Z/komorebi/assets/165908630/9332185f-c4f3-4b3c-ad16-4c507d06bfe9"> --- **Describe alternatives you've considered** I pick the default colors, perhaps matching the windows ui instead. --- **Additional context** As I mentioned, my solution is a work-in-progress, but I wanted to know if this would be something that piqued anyone's interest.
adam added the enhancement label 2026-01-05 14:50:18 +01:00
adam closed this issue 2026-01-05 14:50:18 +01:00
Author
Owner

@LGUG2Z commented on GitHub (May 23, 2024):

My thoughts initially went to pywal which was used to automatically generate colourschemes from wallpapers for Linux users.

Given that changing backgrounds can be quite dynamic I think that instead of trying to keep this in a static configuration file it makes more sense to do this on the fly, either:

  • With a process that listens for wallpaper changes and then applies the top N matching colours
  • A command which does that same that can be called from a hotkey
  • Or in the case of a gui, send either komorebic commands or raw SocketMessages via komorebi_client to change the different colour values when a colour is selected
@LGUG2Z commented on GitHub (May 23, 2024): My thoughts initially went to [pywal](https://github.com/dylanaraps/pywal) which was used to automatically generate colourschemes from wallpapers for Linux users. Given that changing backgrounds can be quite dynamic I think that instead of trying to keep this in a static configuration file it makes more sense to do this on the fly, either: * With a process that listens for wallpaper changes and then applies the top N matching colours * A command which does that same that can be called from a hotkey * Or in the case of a gui, send either `komorebic` commands or raw `SocketMessage`s via `komorebi_client` to change the different colour values when a colour is selected
Author
Owner

@CtByte commented on GitHub (May 23, 2024):

The one I used is color-thief-rs and a powershell script to load the path to the image that is used as the desktop wallpaper. I know pywal from a youtube video. This guy goes all out to customize Hyprland

What I was thinking about is that the values in the config ("wallpaper_color_index": 2) would just refer to one of the 9 colors that is auto-generated by a background process. The actual RGB values would be saved in the cache or something.

I am not so sure how this would work in Rust just yet (I am more at home in C#)

I think having the colors setting could still be useful for reusing the colors (no need to copy-paste the same one many times).

Maybe my explanation was not that great, but I have the code "ready". I was just wondering if this is something that you would be interested to include in komorebi

@CtByte commented on GitHub (May 23, 2024): The one I used is [color-thief-rs](https://github.com/RazrFalcon/color-thief-rs) and a powershell script to load the path to the image that is used as the desktop wallpaper. I know pywal from a youtube video. This guy goes all out to [customize Hyprland](https://www.youtube.com/watch?v=HMxHUvN6VGo) What I was thinking about is that the values in the config ("wallpaper_color_index": 2) would just refer to one of the 9 colors that is auto-generated by a background process. The actual RGB values would be saved in the cache or something. I am not so sure how this would work in Rust just yet (I am more at home in C#) I think having the `colors` setting could still be useful for reusing the colors (no need to copy-paste the same one many times). Maybe my explanation was not that great, but I have the code "ready". I was just wondering if this is something that you would be interested to include in komorebi
Author
Owner

@CtByte commented on GitHub (May 23, 2024):

After some more thinking, I believe that a fitting solution could be that the gui is used to set the colors, as it will probably be the way to edit the komorebi.json file (including saving the changes at some point).

As you are already using the gui to change the colors with a colorpicker, it would be logical to keep it that way using a SocketMessage.

As for the auto-generated colors from the wallpaper, I can see that as an egui widget instead which would allow you to generate the colors from a picture, whether that is from the desktop wallpaper or an other picture, the user can decide. This new widget and a colorpicker can then be used in the gui to set a color.
(A hotkey would also be nice, but I am not sure how would you preset like the 2nd color generated as the single active window border color. That is what I was thinking with the wallpaper_color_index setting)

In the meantime, I will work on that egui widget and come back to this later.

Thank you for your feedback!

@CtByte commented on GitHub (May 23, 2024): After some more thinking, I believe that a fitting solution could be that the `gui` is used to set the colors, as it will probably be the way to edit the `komorebi.json` file (including saving the changes at some point). As you are already using the gui to change the colors with a colorpicker, it would be logical to keep it that way using a `SocketMessage`. As for the auto-generated colors from the wallpaper, I can see that as an `egui widget` instead which would allow you to generate the colors from a picture, whether that is from the desktop wallpaper or an other picture, the user can decide. This new widget and a colorpicker can then be used in the `gui` to set a color. (A hotkey would also be nice, but I am not sure how would you preset like the 2nd color generated as the single active window border color. That is what I was thinking with the `wallpaper_color_index` setting) In the meantime, I will work on that `egui widget` and come back to this later. Thank you for your feedback!
Author
Owner

@LGUG2Z commented on GitHub (May 23, 2024):

On a general high level I think adding dynamism into a configuration file that is designed to be static is going to be quite messy, because now you have a dependency on something else which and you have to resolve string-y references in JSON values, which JSON is famously not a good fit for.

I think a less granular approach that selecting individual colours from a generated palette will also work for a lot of people; being able to run a command that generates a palette from the current background image and always picks the same N colours in the same N positions for different border/stackbar colours will work pretty well most of the time, and over time the results on different images will become somewhat predictable and create an recognizable aesthetic which is recognizable across different palettes and backgrounds (kind of like how different colours from a palette are picked for syntax highlighting and you intuitively get an idea of what the token is depending on which colour in a generated palette is used for it)

@LGUG2Z commented on GitHub (May 23, 2024): On a general high level I think adding dynamism into a configuration file that is designed to be static is going to be quite messy, because now you have a dependency on something else which and you have to resolve string-y references in JSON values, which JSON is famously not a good fit for. I think a less granular approach that selecting individual colours from a generated palette will also work for a lot of people; being able to run a command that generates a palette from the current background image and always picks the same N colours in the same N positions for different border/stackbar colours will work pretty well _most_ of the time, and over time the results on different images will become somewhat predictable and create an recognizable aesthetic which is recognizable across different palettes and backgrounds (kind of like how different colours from a palette are picked for syntax highlighting and you intuitively get an idea of what the token is depending on which colour in a generated palette is used for it)
Author
Owner

@CtByte commented on GitHub (May 24, 2024):

I agree, I think there will be more input on this from people when the bar is released.

The gui would be the best way to customize Komorebi and keep the JSON config as you said static. It can remember the index of the color from the palette (that can be generated or user specified).

I appreciate your time in answering, let's see what comes up in the future

@CtByte commented on GitHub (May 24, 2024): I agree, I think there will be more input on this from people when the `bar` is released. The `gui` would be the best way to customize Komorebi and keep the JSON config as you said static. It can remember the index of the color from the palette (that can be generated or user specified). I appreciate your time in answering, let's see what comes up in the future
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#390