Closed lescx closed 6 months ago
Thank you for bringing this up I have never designed a theme. I may redesign the theme file in a few days.May i ask for your suggestion?
Sure thing. A few suggestions:
A common design pattern is to separate UI elements like menus from the main editor/work UI element. In the case of a file manager, the editor would be your file selection(s).
There is also a design decision to be made about whether or not to use a border. IDEs often allow the use of two different themes based on this concept - bordered and borderless themes.
Menu items and borders have two properties that need separation in design:
Normal text in processes: primary (middle) Border (active): secondary color (brightest) Processes: tertiary color (darkest)
An example of this using my Tmux status bar:
On the left is our "menu". The keyboard shortcuts (1, 2, 3) are the same because they serve all the same purpose. The text marks the current active or inactive window. In tmux you can also implement a "last window" state but I don't use that feature.
Although it is cleaner and perhaps more aesthetically pleasing to use the same background colour for the rest of the terminal, it is good to have a separation in context.
I am against supporting legacy standards until the world freezes over (4 bit, 8 bit colours).
Still, it might be a consideration to support 256 colors for terminals that do not support true color. terminfo
should handle this… terminfo is broken. Helix and Neovim check if the terminal supports true color. Also, there is the $COLORTERM
variable used by some applications (Helix uses it to force 24 bit colors if the terminal doesn't tell it correctly but supports it anyway).
I'm at university right now. I will come back in a few hours and come up with a mock-up for the theming with a JSON.
Oh my god
I really appreciate you typing up such a long list to introduce knowledge about the theme!!
It is common to write config files for in Go written applications in toml
. This would be my first take on how to properly define a theme architecture.
[theme.your-theme]
# Text Colors
text_primary = "" # Default text color
text_secondary = "" # Often less colorful version of primary; e.g. non-active border
text_tertiary = "" # Accent text color for special stuff, e.g. `Processes`, `Clipboard` text
# Background
background = ""
# Borders
border = ""
border_active = ""
# Special Colors
hint = ""
info = ""
warning = ""
error = ""
accent = "" # E.g. default folder color
# Gradient
# The gradient could also be used for the Super Files" in the top left corner after opening `spf`
# or for loading animations when there is a blocking wait going on.
gradient_color_1 = ""
gradient_color_2 = ""
# Cursor
cursor = ""
selection = ""
selection_active = ""
Also, a few things I noticed:
Documents
should be the same color as the other entries in the directory selection but bold.
The icon next to /home/luca/.config/superfile
should be the same as the folder icon in the file browser. No need to specify a new color for this icon.
Clipboard
and Browser 1/4
should be the same tertiary color, no matter if one of them is the active tab or not.
i will update this!
I think the bottom and sidebar border_active
need to be separated separately
selection = ""
selection_active = ""
what is this different
i absolutely love the toml file but i don't think that a json file is any bad. It just needs better naming conventions.
I think a TOML file is easier to use for a config file which gets edited by an end user. A lot of popular applications use TOML (or plain old key = value
which is easy to parse). I don't see that for JSON.
yes it is easy. but json isn't hard too. We can change to toml anytime. I would require a bit of changing packages and code in the src code. But it will be a piece of cake on the user customization side of things
So I think I'm going to change all the config files to toml
, which I think is better.
i also prefer it. I just wanted to say that json doesn't feel that bad. But yeah, toml is nice. I will look forward to it. You can call me to translate the themes
all themes are translated now.
Thank you so much!
I'm still trying to redesign the new theme configuration.
# Border
file_panel_border = "#868686"
sidebar_border = "#868686"
footer_border = "#868686"
modal_border = "#868686"
# Border Active
file_panel_border_active = "#FFF1C5"
sidebar_border_active = "#D79921"
footer_border_active = "#D79921"
modal_border_active = "#868686"
# Background (bg)
full_screen_bg = "#282828"
file_panel_bg = "#282828"
sidebar_bg = "#282828"
footer_bg = "#282828"
modal_bg = "#282828"
# Foreground (fg)
full_screen_fg = "#EBDBB2"
file_panel_fg = "#EBDBB2"
sidebar_fg = "#EBDBB2"
footer_fg = "#EBDBB2"
modal_fg = "#EBDBB2"
# Special Color
cursor = "#8EC07C"
correct = "#8ec07c"
error = "#FF6969"
hint = "#468588"
cancel = "#838383"
warn = "#FF0000"
gradient_color = ["#689d6a", "#fb4934"]
# File Panel Special Items
file_panel_top_directory_icon = "#8EC07C"
file_panel_top_path = "#458588"
file_panel_item_selected_fg = "#D3869B"
file_panel_item_selected_bg = ""
# Sidebar Special Items
sidebar_title = "#CC241D"
sidebar_item_selected_fg = "#E8751A"
sidebar_item_selected_bg = "#282828"
# Modal Special Items
modal_cancel_fg = "#EBDBB2"
modal_cancel_bg = "#6D6D6D"
modal_confirm_fg = "#EBDBB2"
modal_confirm_bg = "#FF4D00"
What do you guys think about this
i like this
I currently work on implementing the ayu themes. I noticed a few shortcomings I would like to bring up:
Better naming convention
When the terminal size is too small for spf (maybe that's also something that could be worked on in the future), the current terminal dimensions that are too small are highlighted in the
terminalTooSmallError
hex color value. There is alsofail
for error messages.I think it might be a good idea to combine color fields into more logical groups like
error
,warning
,gutter
,gutterActive
and so on. It's a tradeoff between configurability and simplicity.Separate icons and text colors
Many text editors and IDEs separate the file and folder icon colors.
Good examples would be
There are also editors and file managers that don't do that:
This would also allow icons based on file type, better tree view and overall better UI and user orientation.