It is currently January 27th, 2021, 12:43 am
Plugin for HWiNFO
-
- Posts: 41
- Joined: October 6th, 2012, 12:27 pm
Re: Plugin for HWiNFO
Yup, the whole reason this was brought up in the first place. And how the demo skin is layed out too. I imagine this support is a pain for skin devs distributing and needing to support (and receive negative feedback cause it doesn't work).
-
- Developer
- Posts: 21470
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Plugin for HWiNFO
Yeah, although I think the net result is some reluctance to include a "sensors" skin in the stuff they distribute. If they do, then they have to clearly document (not trivial) exactly how each user needs to change things to work with their system.stangowner wrote:Yup, the whole reason this was brought up in the first place. And how the demo skin is layed out too. I imagine this support is a pain for skin devs distributing and needing to support (and receive negative feedback cause it doesn't work).
I'm still not convinced there is much that can be done about it. To really have an impact on ease-of-use, I personally think that there would need to be some standard set of sensors defined that are pretty much on all machines. They all have a CPU right? Then reverse the process for that subset of the sensors. Allow for it to be asked for by a standard "name" like CPUCore0Temp or whatever, and the plugin itself "figures out" what sensor that is and how to access it. If that were possible, that might work for, I don't know, 80% of common computer systems, while still allowing a full-blown definition using the current approach for sensors that aren't as common.
I think as long as the user has to define the sensor and its components by hexadecimal numbers that specifically point to the sensor, this just has to be complicated. I'm not really complaining, It might just be how it is...
-
- Posts: 669
- Joined: June 25th, 2015, 7:02 pm
- Location: The Sky, USA
Re: Plugin for HWiNFO
This is exactly the suggestion I made on the HWiNFO forums. Martin shot down the idea immediately. https://www.hwinfo.com/forum/Thread-Is-there-no-easier-way-to-get-the-information-from-HWiNFOjsmorley wrote:Yeah, although I think the net result is some reluctance to include a "sensors" skin in the stuff they distribute. If they do, then they have to clearly document (not trivial) exactly how each user needs to change things to work with their system.
I'm still not convinced there is much that can be done about it. To really have an impact on ease-of-use, I personally think that there would need to be some standard set of sensors defined that are pretty much on all machines. They all have a CPU right? Then reverse the process for that subset of the sensors. Allow for it to be asked for by a standard "name" like CPUCore0Temp or whatever, and the plugin itself "figures out" what sensor that is and how to access it. If that were possible, that might work for, I don't know, 80% of common computer systems, while still allowing a full-blown definition using the current approach for sensors that aren't as common.
”We are pretty sure that r2922 resolves the regression in resolution caused by a reversion to a revision.” - jsmorley, 2017
-
- Posts: 41
- Joined: October 6th, 2012, 12:27 pm
Re: Plugin for HWiNFO
Yup. I'm discussing with Martin now. But we had this discussion a few years ago. You may be right, that it is what it is. Even a small standard list of reading is not trivial once you add users to the equation....haha.
-
- Posts: 669
- Joined: June 25th, 2015, 7:02 pm
- Location: The Sky, USA
Re: Plugin for HWiNFO
I think that Martin’s alternate solution has some merit. It would be possible to create an interface where you choose the variable(s), then choose the sensor and entry from the SMV list. The program would then write the correct values to the .INC file based on the user’s selection.
”We are pretty sure that r2922 resolves the regression in resolution caused by a reversion to a revision.” - jsmorley, 2017
-
- Developer
- Posts: 21470
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Plugin for HWiNFO
Well having a way to "output" a complete list of sensor identification numbers to a .inc file that can be opened and browsed through to "copy and paste" needed information might be marginally easier than having the user open the SharedMemoryViewer app and copy and paste from that I suppose. It does kinda remove one "step" for the user if the skin can designed to create the .inc file the first time it is run or on demand, and then pop open the .inc file in a text editor or something.stangowner wrote:Yup. I'm discussing with Martin now. But we had this discussion a few years ago. You may be right, that it is what it is. Even a small standard list of reading is not trivial once you add users to the equation....haha.
It's all just nibbling around the edges of a process that is going to be painful, especially for a new user, and I doubt much can be done.
-
- Developer
- Posts: 21470
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Plugin for HWiNFO
That sounds promising...raiguard wrote:I think that Martin’s alternate solution has some merit. It would be possible to create an interface where you choose the variable(s), then choose the sensor and entry from the SMV list. The program would then write the correct values to the .INC file based on the user’s selection.
-
- Posts: 41
- Joined: October 6th, 2012, 12:27 pm
Re: Plugin for HWiNFO
It does, although a bit complicated given the variations. Let me think about it for a few.
-
- Developer
- Posts: 21470
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Plugin for HWiNFO
Seems like they would have to select a sensor and an instance and an entry, and say "create this one". It could write all the values needed for a given measure as variables.stangowner wrote:It does, although a bit complicated given the variations. Let me think about it for a few.
I would think at a minimum they would need to select, and it would need to write, values for:
HWiNFOSensorID
HWiNFOSensorInstance
HWiNFOEntryID
Presumably this would address the "duplicate names" issue I saw before... You get the value for the one you ask for.
-
- Posts: 669
- Joined: June 25th, 2015, 7:02 pm
- Location: The Sky, USA
Re: Plugin for HWiNFO
I think I have a solution that will be slightly more of a pain for skin authors, but significantly easier for the average user.
The SMV interface will expand to include a list. Skin authors will use a file in the same directory as the SMV, called something like "HWiNFOConfig.json" (JSON is the only format I can think of that will do the job, but it doesn't necessarily need to be JSON). In this file, the author will create a table structured like so:
Each "page" will be a different skin (ie. CPU Meter, GPU Meter, etc.). Within each page will be various groups or standalone entries. Each "entry" corresponds to a measure or set of variables that will be set, defined in the "entry details" portion of the file. The entry details will act like a !WriteKeyValue, in that you specify a section
To use the tool, you pick an entry (such as "Core 0 Temperature" under the "CPU Temperatures" group) from the list. It will show the currently bound entry in the SMV list portion. You can click an edit button, and choose a different entry from the list. When you click save, it will write the details of that entry as specified in the entry details to the file.
Here is a small example (pardon my formatting - I'm not too well-versed in how to write JSON files):
Each entry will have a label name, and the section that it will write to (whether that be variables or a measure). The next arguments are all the parameters from the SMV window.
The purpose of the external table is to let skin authors tailor the SMV configuration to their own skins as desired. This way, users will be able to simply go down the list and be sure all of the values are tied to the correct entries in the SMV table.
The only thing I haven't figured out it is where/how to tell the program which file it needs to write to. You can't use Rainmeter variables, so perhaps it would be a relative path from the root config path?
I hope I explained that adequately, if not I apologize. I also have no knowledge whatsoever in writing Windows programs (my only programming experience is with Rainmeter and a year of Java in Computer Science class), so I don't know the limitations of the software.
The SMV interface will expand to include a list. Skin authors will use a file in the same directory as the SMV, called something like "HWiNFOConfig.json" (JSON is the only format I can think of that will do the job, but it doesn't necessarily need to be JSON). In this file, the author will create a table structured like so:
Code: Select all
Page
Group
Entry
Entry details
Entry
Entry details
Entry
Entry details
Group
Entry
Entry details
Entry
Entry details
Entry
Entry details
Page
Entry
Entry details
Entry
Entry details
Entry
Entry details
To use the tool, you pick an entry (such as "Core 0 Temperature" under the "CPU Temperatures" group) from the list. It will show the currently bound entry in the SMV list portion. You can click an edit button, and choose a different entry from the list. When you click save, it will write the details of that entry as specified in the entry details to the file.
Here is a small example (pardon my formatting - I'm not too well-versed in how to write JSON files):
Code: Select all
{
"CPU Meter": [
{
"Core Temperatures": [
{
"name": "Core 0 Temperature",
"writesection": "[Variables]",
"HWiNFOSensorId": "HWiNFO-Host0-CPU0-DTS-SensorId",
"HWiNFOSensorInstance": "HWiNFO-Host0-CPU0-DTS-SensorInstance",
"HWiNFOEntryId": "HWiNFO-Host0-CPU0-DTS-Core0Temp"
},
{
"name": "Core 1 Temperature",
"writesection": "[Variables]",
"HWiNFOSensorId": "HWiNFO-Host0-CPU0-DTS-SensorId",
"HWiNFOSensorInstance": "HWiNFO-Host0-CPU0-DTS-SensorInstance",
"HWiNFOEntryId": "HWiNFO-Host0-CPU0-DTS-Core1Temp"
}
]
},
{
"name": "CPU Package Temperature"
"writesection": "[Variables]",
"HWiNFOSensorId": "HWiNFO-Host0-CPU0-DTS-SensorId",
"HWiNFOSensorInstance": "HWiNFO-Host0-CPU0-DTS-SensorInstance",
"HWiNFOEntryId": "HWiNFO-Host0-CPU0-DTS-PackageTemp"
}
]
}
The purpose of the external table is to let skin authors tailor the SMV configuration to their own skins as desired. This way, users will be able to simply go down the list and be sure all of the values are tied to the correct entries in the SMV table.
The only thing I haven't figured out it is where/how to tell the program which file it needs to write to. You can't use Rainmeter variables, so perhaps it would be a relative path from the root config path?
I hope I explained that adequately, if not I apologize. I also have no knowledge whatsoever in writing Windows programs (my only programming experience is with Rainmeter and a year of Java in Computer Science class), so I don't know the limitations of the software.
”We are pretty sure that r2922 resolves the regression in resolution caused by a reversion to a revision.” - jsmorley, 2017