Include symbols in Theme

[cylewitruk]

The symbols are constants atm, but I can see where it could be useful to be able to override some of the symbols, for example replacing the hollow-green-diamond with a green-check-mark.

If all of the symbols should be replaceable is a topic for discussion, but I think at least "state" symbols are a valid use-case.

Thoughts?

[fadeevab]

Constants are easier and smaller to compile into a binary. They are used in many places. On the other hand, trait methods provide better customization; however, they are much more expensive at runtime.

To me, changing symbols to be trait functions seems like a bit of overkill.

I would gather more feedback from the community about whether this feature is highly anticipated.

[cylewitruk]

Just a side-thought, but we could do away with dynamic dispatch all-together, which really isn't needed, with something like:

pub struct CliClackTheme<THEME = DefaultTheme> 
where 
	THEME: Theme 
{
    theme: THEME,
}

impl Default for CliClackTheme<DefaultTheme> {
    fn default() -> Self {
        Self {
            theme: DefaultTheme,
        }
    }
}

pub struct DefaultTheme;
impl Theme for DefaultTheme {}

pub(crate) static THEME: Lazy<RwLock<CliClackTheme>> = Lazy::new(|| RwLock::new(CliClackTheme::default()));

Where a user providing customization would then, like today, provide their own impl of Theme, just that it would need to be wrapped by the CliClackTheme.

Or better yet, a set_theme(theme: impl Theme) { .. set static theme to a wrapped CliClackTheme }

Then this hangs together with #40 and even with this issue, where the constants could be provided as part of a CharMap struct (or something) -- then everything can be compiler-optimized.

[cylewitruk]

I'm surprised that Rust doesn't provide a better solution for this kind of problem, since the type should be known at compile-time :/

[fadeevab]

@cylewitruk Basically, it boils down to the fact that the theme can be changed at runtime at any point of code execution. It means dynamic dispatch only.

[cylewitruk]

Yeah, that use-case makes sense for a TUI app but less for a CLI, imo..

[fadeevab]

@cylewitruk Also, it seems there is no way to inject some behavior from the outer code into the crate/lib at compilation time... Only maybe if some macros! unfolds the whole cliclack directly into the customer's code :)

[cylewitruk]

@cylewitruk Also, it seems there is no way to inject some behavior from the outer code into the crate/lib at compilation time... Only maybe if some macros! unfolds the whole cliclack directly into the customer's code :)

Haha I toyed with that idea too, with an init!-like macro, but I agree that's no good solution 🙁

I thought maybe THEME could be defined using a macro in user code so that the types were compile-time, but then there's no way for cliclack to know how to reach it 😔