-
Notifications
You must be signed in to change notification settings - Fork 52
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
Add config option to set presets #85
Conversation
macchina can now read from a config Linux ~/.config/macchina/macchina.toml check dirs-rs repo for windows and linux Will warn if config is invalid. Can use `--export-config` to export the configuration options from the commandline
We're missing |
Oh I just removed a few of stuff from the config just to show that the config can work without all the config options already set. |
Oh great! This also made me realize that Xinitrc is setting itself in one of the environment variables that tell us which DE you're running, I'll add a new exception for Xinitrc ASAP. |
Oh don't worry about that. I have a bit of a quirky setup which makes This is the package if you are curious xinit-xsession |
No worries, we still have to account for the quirkiness of some setups, if you look around libmacchina you'll notice certain operations and exceptions that seem weird at first, but they were added because I noticed weird output on some people's machines. EDIT: I added the exception, haven't published the release yet. |
I think the next step for the config file is to allow for custom theming, the way we can go about is to initialize a placeholder theme in separator_glyph = "->"
bar_glyph = "o"
// The opening bar delimiter
bar_delimiter_open = "("
// The closing bar delimiter
bar_delimiter_close = ")" And if we're really ambitious we can allow for custom abbreviations, here's a little example: window_manager_string = "WM"
desktop_environment_string = "DE"
... The key naming choice is up for debate, I'm not sure This will most likely break the preset theme that the user specified in their config, so we have to prioritize either the custom theme, or the preset theme. |
Ah okay so I'll have to look into dividing the config into theme Something like [config]
palette = true
no_color = false
no_separator = false
no_bar_delimiter = false
no_title = true
no_ascii = true
no_box = true
bar = true
random_color = false
random_sep_color = false
short_uptime = false
short_shell = true
theme = 'Boron'
custom_ascii = '/home/fs0c131y/.config/ascii/archlinux.ascii' and [theme]
name = 'MyTheme'
window_manager_string = 'WM' Edit: Hmmm it seems that the toml spec cannot have multiple keys with same name so we will have to split the themes into seperate files. |
Separate files is definitely a better idea. |
SInce you're using EDIT: This concerns libmacchina actually, forgot to mention that. |
Okay so I was looking into serializing themes from a file and I have a few design related questions.
|
The single binary route is probably the best option, is it possible to split up themes into separate toml files and still be able to use them as if they were built-in? (most likely not)
I guess so, the intent behind |
Okay so I'm going to implement it as such
|
Sounds good! EDIT: I'd like to mention that although this feature isn't breaking per se, it still is significant that it warrants a jump in the versioning of the program, so when bumping the version number, it should be v0.8.0. |
Okay so I was implementing the custom themes and I think I have to restructure the themes module quite a bit to make both inbuilt and custom themes work at the same Also since the theme argument used to be an enum I'll need to change it to a string to work with custom values. Also this will break auto generated autocomplete for --themes argument, (since we don't know all the variants anymore) but a custom one can be written. Edit: |
We can do this without removing the enum, when matching the
How so? I feel like the only change that needs to happen is a placeholder theme that is filled with the values found in a given
Um, I think so? Key names are considered an But I'm sure you can bypass this process if custom key names are provided in the config. |
#[structopt(
short = "t",
long = "theme",
default_value = "Hydrogen",
possible_values = & theme::Themes::variants(),
case_insensitive = true,
help = "Specify the theme"
)]
pub theme: Option<theme::Themes>, Theme argument directly take enum values only and AFAIK we can't make new enum variant's at runtime with custom theme names.
This is mostly because most of the getter setter functions are redundant since all of them are basically the same.
I'll look into it after I have completed the rest of the theming. |
That is true, I'm sort of getting rusty at writing Rust code since most of my time has been taken up by PHP, and so I keep forgetting these details.
I did notice this a while back, you're absolutely right.
Sounds good :)
So a custom theme is not a EDIT: Totally off-topic, but, I noticed you were using |
Yes I was thinking something along the lines of macchina --list-themes
Hydrogen ( Inbuilt )
Lithium ( Inbuilt )
Proton
Carbon for listing themes and the themes themselves will simply be a toml file in |
I'm all up for this! It looks to me like the configuration system is tightly joined together and it's pretty dope! |
Haha, It's probably gonna take a while to be honest, but I'll keep you posted. |
Huh It seems that rust doesn't have fields in traits so we still need to do the getter/setter madness until the rfc is merged. |
Oops, forgot to tell you about that lol. I went through a similar situation yesterday, but I felt as if fields in a trait is not really the purpose of traits. Can you link me the RFC so I can get an understanding of the reasoning behind why Rust doesn't let you do this by default and why people want to see it get merged? (other than removing redundancy) |
This is a basic POC implementation. Needs a lot of cleanup and fixing.
There's one thing we might want to address before merging, that is the conflict between hide and show_only within the configuration file. Is |
Is I mean it would work but I think it should be done in a separate function like |
Or possibly directly inside of |
Alrighty, I could take care of it if you'd like. |
Sure ! I also have some more changes locally I need to commit. |
Great :) |
Fixed naming and paths. Added some docs.
I'll include a custom theme |
Sure! |
Added example theme in theme/Carbon.json Themes support true color but config file doesn't
A few notes.
|
Thanks for the clarification, I'll make sure to include this when I update the READMEs. |
Looks great but I think you forgot to push the commit :). |
Yeah, just cleaning up a bit. |
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 good !
Terrific work by the way! 🚀 |
Haha, thanks ! :) |
Fixes #83