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

[REQUEST/IDEA] Change the way btop treats its configuration file #637

Open
lvxnull opened this issue Oct 1, 2023 · 3 comments
Open

[REQUEST/IDEA] Change the way btop treats its configuration file #637

lvxnull opened this issue Oct 1, 2023 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@lvxnull
Copy link
Contributor

lvxnull commented Oct 1, 2023

Currently, every time you open or close a window in btop, or change the way processes are sorted, the config gets overwritten. This is unlike any other command line application that I know of. This can be annoying when writing the config manually, or if btop.conf is managed by a dotfile manager like stow or chezmoi.
Instead, I propose addition of an additional file(maybe called btop.state?), which would behave similarly to how the config file works now. The config would instead be used as a config file, e.g created if it doesn't exist but otherwise read only.
Options would be read in this priority:

  1. btop.conf
  2. btop.state
  3. reasonable defaults

To maintain backwards compatibility, I propose addition of a new config option, config_version, which when set to 2, enables this new behavior. New configs created by btop would have config_version = 2, and configs without this value set or with config_version = 1 would keep old behavior. If backwards compatibility with the old config behavior isn't desired, config_version could instead be used to distinguish configs that require migration from the old behavior and new configs.

@cosmojg
Copy link

cosmojg commented Jun 4, 2024

Just wanted to bump this. I was updating my git-versioned dotfiles recently and ran into this issue again. @lvxnull, I noticed you assigned @aristocratos. Are either/both of you already working on a PR for this? If not, would you be interested in one? If so, where should I start?

@lvxnull
Copy link
Contributor Author

lvxnull commented Jun 5, 2024

I remember that what blocked this was our effort to redesign the rest of the configuration code. @aristocratos told us he already had that figured out in the windows version(or something along those lines, i don't remember exactly) and wanted to port it here but it seems that still hasn't happened. I wanted to avoid implementing this on top of the current configuration code but it seems this may be unavoidable now.

@Blacksmoke16
Copy link

I'm probably coming at this from a very naive perspective, but what about a new general[Lock Config] option that defaults to false, but if set to true will make it so btop doesn't persist the changes to the underlying config file?

This would solve my use case at least where I configured things the way I want, saved it to chezmoi, and want to use it as is going forward. It would still allow changing things in an open session, but without affecting my customized default settings. If I wanted to update my defaults I'd have to either do so directly in the file, or set that option to false, make my changes, then go back to true. Which seems reasonable given I don't plan on changing the settings that often.

It would be backwards compatible as well, and possibly easier to implement? 🤷.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants