Replies: 1 comment · 1 reply
-
|
The tricky part with this is UI. How would a plugin fancurve be exposed with its parameters? I guess there could be some kind of generic interface to expose parameters and I could build some kind of UI which expose these generic parameters. However, just so you know, you can already do time of day scheduling with task scheduler and 2 configurations in FanControl, as mentioned in the link you provided. Same for application aware switching. It can be done externally by using FanControl CLI to change configs. |
Beta Was this translation helpful? Give feedback.
-
|
Why not just reuse the existing UI as prefabs? Offer the plugin devs a selection of the existing prefabs for UI, like a generic select box with values like a trigger, mix, etc... For example the application aware switching could work just like a trigger, but instead of selecting a temp sensor it would offer a selection of processes or exes....? Idk I am just throwing things at the wall. The CPU/GPU load could be just a normal fancurve in the UI as well, except the axis mean different things. Alternatively just leave the full UI to the plugin dev too. I don't know what you use for UI in the main app, but unless its ancient or something it should have a way to dynamically load elements defined in a DLL, so the dev could just do that too. Again, more of an idea. As for ToD and application aware switching, I know you can do that with the cli, thats how I have my own thing set up right now, but thats quite a bit more complicated and does not survive windows reinstalls and is a pain to bring to other computers. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The current plugin system allows extending FanControl with custom sensors and controls, which is great. However, there's no equivalent extensibility for fan curves.
Several community requests have come up for new curve types:
I get that Rem0o might not want to add a bunch of community wanted curves for no reason. Ergo - plugin.
Let plugins define curves
Just like
IPluginSensorlets plugins provide new data sources, a curve plugin interface (something likeIPluginFanCurve) would let plugins provide new decision logic.A curve plugin would:
I'm already building custom sensor plugins (Specifically for my framework laptop, dunno if it will work yet but... maybe) and would happily build curve plugins for the use cases above if the API existed (Cause the reason I looked into this in the first place is that I personally would want all three mentioned).
In fact, my first idea was to implement it myself until I realized the app is not open source (Because the webpage has a github link I thought it was open source - personal opinion but I kinda don't like the github link there, makes it look OSS even when its not. Doesn't matter at the end of the day).
Beta Was this translation helpful? Give feedback.
All reactions