It is currently December 14th, 2018, 8:23 pm

Plugin for HWiNFO

Share your custom plugins and applications to enhance Rainmeter.
stangowner
Posts: 39
Joined: October 6th, 2012, 12:27 pm

Re: Plugin for HWiNFO

stangowner » February 5th, 2018, 7:39 pm

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).
User avatar
jsmorley
Developer
Posts: 18494
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin for HWiNFO

jsmorley » February 5th, 2018, 7:46 pm

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).
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.

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...
User avatar
raiguard
Posts: 493
Joined: June 25th, 2015, 7:02 pm
Location: The Sky, USA

Re: Plugin for HWiNFO

raiguard » February 5th, 2018, 7:49 pm

jsmorley 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.
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-HWiNFO
”We are pretty sure that r2922 resolves the regression in resolution caused by a reversion to a revision.” - jsmorley, 2017
stangowner
Posts: 39
Joined: October 6th, 2012, 12:27 pm

Re: Plugin for HWiNFO

stangowner » February 5th, 2018, 7:51 pm

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.
User avatar
raiguard
Posts: 493
Joined: June 25th, 2015, 7:02 pm
Location: The Sky, USA

Re: Plugin for HWiNFO

raiguard » February 5th, 2018, 7:55 pm

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
User avatar
jsmorley
Developer
Posts: 18494
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin for HWiNFO

jsmorley » February 5th, 2018, 7:58 pm

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.
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.

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.
User avatar
jsmorley
Developer
Posts: 18494
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin for HWiNFO

jsmorley » February 5th, 2018, 8:00 pm

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.
That sounds promising...
stangowner
Posts: 39
Joined: October 6th, 2012, 12:27 pm

Re: Plugin for HWiNFO

stangowner » February 5th, 2018, 8:03 pm

It does, although a bit complicated given the variations. Let me think about it for a few.
User avatar
jsmorley
Developer
Posts: 18494
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin for HWiNFO

jsmorley » February 5th, 2018, 8:07 pm

stangowner wrote:It does, although a bit complicated given the variations. Let me think about it for a few.
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.

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.
User avatar
raiguard
Posts: 493
Joined: June 25th, 2015, 7:02 pm
Location: The Sky, USA

Re: Plugin for HWiNFO

raiguard » February 6th, 2018, 2:50 am

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:

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
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):

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"
		}
	]
}
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.
”We are pretty sure that r2922 resolves the regression in resolution caused by a reversion to a revision.” - jsmorley, 2017