You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
btop.conf
btop.state
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.
The text was updated successfully, but these errors were encountered:
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?
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.
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? 🤷.
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:
btop.conf
btop.state
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 haveconfig_version = 2
, and configs without this value set or withconfig_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.The text was updated successfully, but these errors were encountered: