Command argument refactoring proposition about fw-fanctrl HOT 4 OPEN

Hmmm I'm not convinced this would be a positive change.
Currently, we have quite a small program and --help gives all the info you need to use it. The args can be read and understood in seconds, since the feature set is minimal. Which is good, and expected for a program whose only job is to deal with fans and temperatures.
This would change with your proposal, with the addition of new niche arguments that won't be used by most people.
All the features added by these new commands can be achieved currently by editing manually the config file. I'd never use CLI to add a new curve (or to change anything that would affect the non-volatile state of the service, aka the config file), so I don't see how this could have a positive impact on user friendliness. I believe that opening a file and making some changes there before reloading a service is pretty typical and accepted.

Basically, I think we should respect these rules:

• Non-volatile changes: config file
• Volatile changes: command line

Other typical arguments against change applies too:

• Don't fix what isn't broken
• Don't change UX/break compatibility if you don't have to

Also, adding these would increase the line count. I feel like it's a nice feature that the script is small, so people can have a look before giving it sudo rights. Anything increasing the size of the script must have serious arguments going for it.

from fw-fanctrl.

Yes, I understand
I plan to add (or create a separate project?) a simple GUI for fan management using this project, hence my suggestion for rule management, but using the config.json for permanent changes is fine too.

The current command line arguments have some problems too, eg. we can ask to reload, change strategy, query current strategy and print the strategy list at the same time.

Refactoring them using subcommands allows us to restrict the user to one and only one command at a time.

With this in mind, we could continue to support the old arguments (without generating help for them, forcing new users to use new ones) and add the new format.

run : direct : run the service. (use reset to reset to the default strategy)

reload : indirect : reload configuration

reset : indirect : reset the current strategy to the default one

pause : direct : pause the service

resume : resume : pause the service

print : direct : print desired information

as for the line count, I plan to separate the script into several well named files/modules to improve readability.

from fw-fanctrl.

I see. It's a bit of a dilemma for me, on one hand I like that this project fits in a single script. On the other hand, you're there, willing to increase the feature set and to commit some good work, at the price of adding complexity and breaking a few things.
I'm a strong partisan of "better is the enemy of good", but also I don't want to discourage you.
So, all things measured, if you're wiling to work on this, please do.
The GUI might live in a different repo, but it would be better that it uses fw-fanctrl under the hood rather than tweaking directly its config file (which means you can add back the arguments about adding/removing a curve)

I invited you on this repo btw, so as to give you collaborator permissions (let me know if you don't want them)

from fw-fanctrl.

I will think a bit more about the file splitting but I keep thinking that separating them would make the project easier to maintain, we will see.

I will also do my best not to break current systems and keep previous arguments as a backup for a while when adding the new ones.

Thank you for your trust in me, feel free to revoke these permissions if you ever need/want to.

from fw-fanctrl.