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

Add config option to set presets #85

Merged
merged 16 commits into from
May 17, 2021
Merged

Conversation

uttarayan21
Copy link
Member

@uttarayan21 uttarayan21 commented May 8, 2021

Fixes #83
example

example-config

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

grtcdr commented May 8, 2021

We're missing color and separator_color

@uttarayan21
Copy link
Member Author

uttarayan21 commented May 8, 2021

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.

@grtcdr
Copy link
Member

grtcdr commented May 8, 2021

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.

@uttarayan21
Copy link
Member Author

uttarayan21 commented May 8, 2021

Oh don't worry about that. I have a bit of a quirky setup which makes Xinitrc show up as an item in lightdm's DM selection menu.
So that's why macchina thinks Xinitrc is my dm.

This is the package if you are curious xinit-xsession

@grtcdr
Copy link
Member

grtcdr commented May 8, 2021

Oh don't worry about that. I have a bit of a quirky setup which makes Xinitrc show up as an item in lightdm's DM selection menu.
So that's why macchina thinks Xinitrc is my dm.

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.

@grtcdr
Copy link
Member

grtcdr commented May 8, 2021

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 theme.rs whose fields will take the values of say:

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 window_manager_string is that great of a name.

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.

@uttarayan21
Copy link
Member Author

uttarayan21 commented May 8, 2021

Ah okay so I'll have to look into dividing the config into theme sections files.

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
Mytheme.toml

[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.

@grtcdr
Copy link
Member

grtcdr commented May 8, 2021

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.

@grtcdr
Copy link
Member

grtcdr commented May 8, 2021

SInce you're using dirs to retrieve the config directory, I'll remove the home dependency which is being used to get the home directory to count local packages for certain package managers and use dirs instead.

EDIT: This concerns libmacchina actually, forgot to mention that.

@uttarayan21
Copy link
Member Author

Okay so I was looking into serializing themes from a file and I have a few design related questions.

  • Should we keep the hydrogen, lithium and the other themes in the theme.rs or should we seperate them into Hydrogen.toml and similar files ?
    IMO It should be able to perform just as a single binary so I'd keep at least a default theme in it.
  • Should we keep the theme.rs as is and make a separate module for parsing themes ?

@grtcdr
Copy link
Member

grtcdr commented May 9, 2021

Okay so I was looking into serializing themes from a file and I have a few design related questions.

* Should we keep the hydrogen, lithium and the other themes in the theme.rs or should we seperate them into Hydrogen.toml and similar files ?
  IMO It should be able to perform just as a single binary so I'd keep at least a default theme in it.

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)

* Should we keep the theme.rs as is and make a separate module for parsing themes ?

I guess so, the intent behind theme.rs is to provide a basic trait that different themes can implement to create new built-in themes, so a theme toml parser should be done outside of theme.rs as it feels more like an extension to the theming capabilities.

@uttarayan21
Copy link
Member Author

Okay so I'm going to implement it as such

  1. Check theme name from config.
  2. If theme matches inbuilt themes then display that.
  3. else try to parse a file in dirs::data_dir()/macchina/themes/ folder.
  4. If everything else fails, default to the hydrogen theme.

@grtcdr
Copy link
Member

grtcdr commented May 10, 2021

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.

@uttarayan21
Copy link
Member Author

uttarayan21 commented May 10, 2021

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:
Also a question about ReadoutKey.get_common_name(), should it also be theme-able ?

@grtcdr
Copy link
Member

grtcdr commented May 10, 2021

Also since the theme argument used to be an enum I'll need to change it to a string to work with custom values.

We can do this without removing the enum, when matching the --theme argument, if the argument isn't one of the default themes, then we can assume the argument is a path to a file.

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

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 theme.toml, but then again, I may be missing something.

Also a question about ReadoutKey.get_common_name(), should it also be theme-able ?

Um, I think so?

Key names are considered an AbbreviationType and should go through get_common_name(), so get_common_name() should be responsible for custom key names too.

But I'm sure you can bypass this process if custom key names are provided in the config.

@uttarayan21
Copy link
Member Author

We can do this without removing the enum, when matching the --theme argument, if the argument isn't one of the default themes, then we can assume the argument is a path to a file.

    #[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.
And matching against the enum variants is done automatically by structopt/clap so we can't add additional logic there.

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 theme.toml, but then again, I may be missing something.

This is mostly because most of the getter setter functions are redundant since all of them are basically the same.
So I was thinking about a maybe default implementation and overwrite it when necessary.
Also the new fucntion needs to be removed from the trait to a standard impl since CustomTheme cannot have a new function since we need a name for the theme to be provided.

But I'm sure you can bypass this process if custom key names are provided in the config.

I'll look into it after I have completed the rest of the theming.

@grtcdr
Copy link
Member

grtcdr commented May 10, 2021

Theme argument directly take enum values only and AFAIK we can't make new enum variant's at runtime with custom theme names.
And matching against the enum variants is done automatically by structopt/clap so we can't add additional logic there.

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.

This is mostly because most of the getter setter functions are redundant since all of them are basically the same.

I did notice this a while back, you're absolutely right.

So I was thinking about a maybe default implementation and overwrite it when necessary.

Sounds good :)

Also the new fucntion needs to be removed from the trait to a standard impl since CustomTheme cannot have a new function since we need a name for the theme to be provided.

So a custom theme is not a Path but is extracted from the entries of the macchina directory within dirs::data_dirs?

EDIT: Totally off-topic, but, I noticed you were using bat, it's awesome!!

@uttarayan21
Copy link
Member Author

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 dirs::data_dirs()/macchina/themes folder.

@grtcdr
Copy link
Member

grtcdr commented May 10, 2021

I'm all up for this!

It looks to me like the configuration system is tightly joined together and it's pretty dope!

@uttarayan21
Copy link
Member Author

Haha, It's probably gonna take a while to be honest, but I'll keep you posted.

@uttarayan21
Copy link
Member Author

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.

@grtcdr
Copy link
Member

grtcdr commented May 10, 2021

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)

@uttarayan21
Copy link
Member Author

@grtcdr
Copy link
Member

grtcdr commented May 11, 2021

Sure,
Here you go.
https://github.com/nikomatsakis/fields-in-traits-rfc/blob/master/0000-fields-in-traits.md
rust-lang/rfcs#1546
https://internals.rust-lang.org/t/fields-in-traits/6933

Thank you so much!

This is a basic POC implementation.
Needs a lot of cleanup and fixing.
@uttarayan21
Copy link
Member Author

uttarayan21 commented May 14, 2021

So I've done a basic implementation of the themes.
Had to restructure a lot of the stuff but custom themes are working now.

macchina
config

@grtcdr
Copy link
Member

grtcdr commented May 16, 2021

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 patch_args the appropriate place to set a condition for their coexistance?

@uttarayan21
Copy link
Member Author

Is patch_args the appropriate place to set a condition for their coexistance?

I mean it would work but I think it should be done in a separate function like check_conflicts.

@uttarayan21
Copy link
Member Author

Or possibly directly inside of from_config and return an error if it has conflicts.

@grtcdr
Copy link
Member

grtcdr commented May 16, 2021

Is patch_args the appropriate place to set a condition for their coexistance?

I mean it would work but I think it should be done in a separate function like check_conflicts.

Alrighty, I could take care of it if you'd like.

@uttarayan21
Copy link
Member Author

Alrighty, I could take care of it if you'd like.

Sure ! I also have some more changes locally I need to commit.

@grtcdr
Copy link
Member

grtcdr commented May 16, 2021

Alrighty, I could take care of it if you'd like.

Sure ! I also have some more changes locally I need to commit.

Great :)

@uttarayan21
Copy link
Member Author

I'll include a custom theme
Give me a second

@grtcdr
Copy link
Member

grtcdr commented May 16, 2021

I'll include a custom theme
Give me a second

Sure!

Added example theme in theme/Carbon.json
Themes support true color but config file doesn't
@uttarayan21
Copy link
Member Author

Screenshot from 2021-05-16 22-18-45

A screenshot of theme I included.

@uttarayan21
Copy link
Member Author

A few notes.

  • theme field should have the exact filename for custom themes without extensions. i.e. for Carbon.json -> "Carbon"
  • Custom themes support truecolor (24-bit) and 256 (8-bit) colors in addition to the 4-bit color pallet.
  • Both theme and config options are case-sensitive.

@grtcdr
Copy link
Member

grtcdr commented May 16, 2021

A few notes.

* `theme` field should have the exact filename for custom themes without extensions. i.e. for `Carbon.json` -> `"Carbon"`

* Custom themes support truecolor (24-bit) and 256 (8-bit) colors in addition to the 4-bit color pallet.

* Both theme and config options are case-sensitive.

Thanks for the clarification, I'll make sure to include this when I update the READMEs.

@grtcdr
Copy link
Member

grtcdr commented May 17, 2021

I managed to make the config conflict check work and also report which keys are conflicting, check it out and tell me if anything needs to be changed.

image

image

@uttarayan21
Copy link
Member Author

Looks great but I think you forgot to push the commit :).

@grtcdr
Copy link
Member

grtcdr commented May 17, 2021

Looks great but I think you forgot to push the commit :).

Yeah, just cleaning up a bit.

Copy link
Member Author

@uttarayan21 uttarayan21 left a comment

Choose a reason for hiding this comment

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

Looks good !

@grtcdr
Copy link
Member

grtcdr commented May 17, 2021

Looks good !

Terrific work by the way! 🚀

@grtcdr grtcdr merged commit fa48b81 into Macchina-CLI:main May 17, 2021
@uttarayan21
Copy link
Member Author

Looks good !

Terrific work by the way! 🚀

Haha, thanks ! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

[Question] About the creation of a configuration file
2 participants