-
-
Notifications
You must be signed in to change notification settings - Fork 651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
X colors #239
X colors #239
Conversation
You can mark it as |
…re customizable colored elements
src/common/utils/shared.rs
Outdated
} | ||
|
||
pub fn load_palette() -> Palette { | ||
let palette = match Colors::new("xresources") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@denismaxim0v - my guess is that if you move this call to OsApi
and then implement something that returns the defaults for the test fixtures, then the tests should pass.
Let me know if you want more detailed instructions :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, that makes sense, I will have a go at it this week hopefully
By the way @denismaxim0v , how have you felt about the In my mind a palette isn't really an |
I think it could actually be an event if we have some predefined themes the user should be able to switch between them from some menu, like strider but for themes maybe? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome! Works like a charm on my machine and seems easy to use in plugins!
With that being said, I'd like to see if we could move a couple of things out of zellij-tile
. I'm looking to keep it as a very minimalist wrapper library so that it's easy to port to other languages. If I understand correctly, I think all we need is Theme
, PaletteSource
, and Palette
in zellij-tile
.
We could then remove everything but the two enum
s and one struct
.
If you would like to have these things in a library, maybe we could spin off a zellij-tile-extra
or something that's meant to add helpful functionality for Rust plugins in particular. As long as the zellij-tile
library itself is as small and simple as possible.
@@ -41,6 +32,153 @@ impl Display for LinePart { | |||
} | |||
} | |||
|
|||
#[derive(Clone, Copy)] | |||
pub struct ColoredElements { | |||
// slected mode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a typo of selected
here :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
definitely, mb
pub superkey_suffix_separator: Style, | ||
} | ||
|
||
impl ColoredElements { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd personally not bother with the new()
function, since the style fields are already public. I'd directly construct it as:
ColoredElements {
selected_prefix_separator: // Something...
// ...
}
Instead of calling new()
in a similar way :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's fair
// that can be defined in the config perhaps | ||
fn color_elements(palette: Palette) -> ColoredElements { | ||
match palette.source { | ||
PaletteSource::Default => ColoredElements::new( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is where I would just do this thing instead:
ColoredElements {
selected_prefix_separator: // Something...
// ...
}
} | ||
} | ||
|
||
// I really hate this, but I can't come up with a good solution for this, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the default and Xresources are actually themed differently? As opposed to just having a different palette?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was only needed, because I wanted to keep the original default coloring, and as for the Xresources I wanted to make it slightly different, because if mapped as default it looked horrific and vice versa. Also I think that could be moved somewhere else or something similar to be done to color individual elements of Zellij into whatever you want(as in one of the discussions we started on discord), not sure if this is a cool feature or not tho
src/common/mod.rs
Outdated
@@ -267,7 +267,8 @@ pub fn start(mut os_input: Box<dyn OsApi>, opts: CliArgs) { | |||
let send_plugin_instructions = send_plugin_instructions.clone(); | |||
let send_app_instructions = send_app_instructions.clone(); | |||
let max_panes = opts.max_panes; | |||
|
|||
let colors = os_input.load_palette(); | |||
// debug_log_to_file(format!("{:?}", colors)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could probably clean this up :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(The commented line, that is)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, bad habits
zellij-tile/src/data.rs
Outdated
Default, | ||
Xresources, | ||
} | ||
pub mod colors { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, why do we need this when we have palettes? Is this used within plugins?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be for the Default
implementation? See the below comment :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems that it got lucky and survived when I was cleaning stuff up
zellij-tile/src/data.rs
Outdated
pub orange: (u8, u8, u8), | ||
} | ||
|
||
impl Default for Palette { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be done on the Zellij side of things? It's fine to just #[derive(Default)]
in zellij-tile
because plugins are guaranteed to receive a ModeUpdate
when they are loaded. I'd rather this default palette be made in Zellij as opposed to here if possible :)
zellij-tile/src/lib.rs
Outdated
@@ -39,3 +39,19 @@ macro_rules! register_plugin { | |||
} | |||
}; | |||
} | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would these macros be able to live in the status bar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are used in tab-bar too, and anywhere pretty much where you want to color stuff, those would be needed, so I figured maybe here is the best place for them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's fair, but I don't quite think they are essential to the functioning of the API (especially if we are going to have "invisible" plugins soon that don't need a Pane
to run).
How would you feel about spinning out a zellij-tile-extra
library or something like that in the main repo (just like zellij-tile
) that can hold non-critical but potentially quite useful helper functions / macros? Like I said, I'm quite invested in keeping zellij-tile
as slim and minimal as possible, but I'd be happy putting almost anything in a library like zellij-tile-extra
. I think having that additional "utility" library could actually help us clean up the plugins we have so far (eventually) 🙂
zellij-tile/Cargo.toml
Outdated
@@ -7,6 +7,7 @@ description = "A small client-side library for writing Zellij plugins" | |||
license = "MIT" | |||
|
|||
[dependencies] | |||
ansi_term = "0.12.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be removed now that zellij-tile-extra
exists?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are very quick :), yes it can
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Thanks for letting me bully you about when it came to zellij-tile
! I think this is looking great and that you should merge it whenever you're ready! 🙂
Well, I'm pretty much ready. Maybe will wait a bit for others to have a look at it. And we are ready to post on r/unixporn 😄 |
that's still a wip