-
-
Notifications
You must be signed in to change notification settings - Fork 280
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 some features for config #749
Conversation
This is interesting to have, since there's an issue where user wants to use it from this location. Will most likely not work on Snap package installation, but regardless it could be feature that could only be used on non Snap installs. I find Also it's description should be updated from Looking at changes, I also don't get how is this any different from approach @shadeyg56 did when he first implemented these changes? I made a comment on Discord, where I could only apply certain changes to auto-cpufreq.conf file by restarting auto-cpufreq daemon with systemd. Also, currently this is what I get when I try to use reload flag, it appears nothing happens and terminal never clears out until I ctrl+c:
How is this supposed to work, as I don't see it in code nor I see it explained anywhere? |
|
Auto install auto-cpufreq.conf with |
Don't really agree with most of the changes here. I don't really see the need for a --config-reload flag, and if there was one, I think it should be the default and not have to be enabled explicitly (especially for every command that uses config) As usual, you seem to remove stuff for seemingly no reason. For example, you removed an entire doc-string in the config class file. This sort of stuff is there for a reason. I'm not trying to be rude, just want to understand your reasoning behind this sort of stuff. Less lines != better code.
Perhaps this is true. In retrospect, the config class probably should've been more like a ConfigManager class that was responsible for managing a single instance of some Config rather than having a Config class that is intended to be used as a singleton that maintains its own state. I did wrestle with the design of this for some time and still never decided on something I really liked
The reason this wasn't done in the first place is because most |
I think I removed the docstring because I found I didn't think of transforming the Config class into a ConfigManager child class, I think it's a great idea. I said |
@Angel-Karasu as it was mentioned in another of your PR's, please create smaller PR's which are easier to review and test. I'm still facing issues from refactor introduced in #695 because there were so many changes which were hard to test individually. Since @shadeyg56 a person who introduced original "config reload" functionality doesn't understand the logic behind these changes (and neither do, my questions above has still not be answered). As I mentioned in "looking for maintainers and contributors" there's bunch of things that could be picked up to make auto-cpufreq better. However, I don't see how these changes will make it better so I'm simply closing this PR. |
$HOME/.config/auto-cpufreq.conf
file--config-reload
option, the user chooses to enable or not the auto-reload when the configuration has been modified/etc/auto-cpufreq.conf
filehas_option
andget_option
functionsget_config
function because it's more cumbersome to call it