Skip to content
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

Merged
merged 30 commits into from
May 2, 2021
Merged

X colors #239

merged 30 commits into from
May 2, 2021

Conversation

denismaxim0v
Copy link
Member

that's still a wip

@denismaxim0v denismaxim0v marked this pull request as draft March 26, 2021 14:44
@matu3ba
Copy link
Contributor

matu3ba commented Apr 23, 2021

You can mark it as WIP: or DRAFT: to prevent CI running.

}

pub fn load_palette() -> Palette {
let palette = match Colors::new("xresources") {
Copy link
Member

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 :)

Copy link
Member Author

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

@TheLostLambda
Copy link
Member

By the way @denismaxim0v , how have you felt about the ModeInfo solution? Would it be better to just have a function like get_palette() -> Palette? That way you wouldn't need to write anything to handle it in update(). I've decided to do that for something I should push later today and I think it might be a bit simpler.

In my mind a palette isn't really an Event I suppose, but I'd like to know what you think, as my thinking on this has changed just today.

@denismaxim0v
Copy link
Member Author

By the way @denismaxim0v , how have you felt about the ModeInfo solution? Would it be better to just have a function like get_palette() -> Palette? That way you wouldn't need to write anything to handle it in update(). I've decided to do that for something I should push later today and I think it might be a bit simpler.

In my mind a palette isn't really an Event I suppose, but I'd like to know what you think, as my thinking on this has changed just today.

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?

@denismaxim0v denismaxim0v marked this pull request as ready for review May 1, 2021 12:21
@denismaxim0v denismaxim0v requested a review from imsnif May 1, 2021 12:21
Copy link
Member

@TheLostLambda TheLostLambda left a 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 enums 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
Copy link
Member

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 :)

Copy link
Member Author

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 {
Copy link
Member

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 :)

Copy link
Member Author

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(
Copy link
Member

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,
Copy link
Member

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?

Copy link
Member Author

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

@@ -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));
Copy link
Member

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 :)

Copy link
Member

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)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, bad habits

Default,
Xresources,
}
pub mod colors {
Copy link
Member

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?

Copy link
Member

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 :)

Copy link
Member Author

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

pub orange: (u8, u8, u8),
}

impl Default for Palette {
Copy link
Member

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 :)

@@ -39,3 +39,19 @@ macro_rules! register_plugin {
}
};
}

Copy link
Member

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?

Copy link
Member Author

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?

Copy link
Member

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) 🙂

@@ -7,6 +7,7 @@ description = "A small client-side library for writing Zellij plugins"
license = "MIT"

[dependencies]
ansi_term = "0.12.1"
Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

@TheLostLambda TheLostLambda left a 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! 🙂

@denismaxim0v
Copy link
Member Author

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 😄

@denismaxim0v denismaxim0v merged commit 98d9eac into main May 2, 2021
@h3nill h3nill deleted the x-colors branch May 4, 2021 03:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants