LibreHardwareMonitor
Needs these fixes [from JayzTwoCentz video]
Here is a list of what he requested in his video:
- [x] #847
- [x] #1395
- [ ] #1400
- [ ] Record indicator when logging to csv file
- [ ] #1398
- [x] #1397
- [ ] Change plot scale (y axis)
I've already started fixing some of those here. Please let me know if you want to take some of them.
Dark mode is already an issue listed in #116. Would assume it's low in priority.
@hcabel I believe he also requested a feature to make a custom defined interval for the scale of a data plot.
.NET 9 may include new APIs for easy dark mode implementation
See https://github.com/dotnet/winforms/issues/7641
@hcabel I believe he also requested a feature to make a custom defined interval for the scale of a data plot.
@SirVingeTheSecond I cannot find it, send me the time code and I'll update the list.
@hcabel I believe he also requested a feature to make a custom defined interval for the scale of a data plot.
@SirVingeTheSecond I cannot find it, send me the time code and I'll update the list.
I think the time code is 12:43 (https://youtu.be/sX2ThUWNXio?t=763), but that is about the Y axis scale
I would suggest to break those bullet points from Jay down into single issues and backlink these here.
Assuming, that I am able to compile this project at my place I could try to tackle "Do not close dropdowns when checking/unchecking options". This can easily be handled by a small dialog instead of the menu structure. Menus always close when you click an item within.
@Ironfist69 @hcabel @tryptichon
Do not close dropdowns when checking/unchecking options Pull Request (1395) Prevent Menu From Closing When Turning On or Off Sensors to Display
Created
"Do not close dropdowns when checking/unchecking options": Wow,, that was fast :-D. Is anybody still interested in a solution that uses a dialog instead of the menu?
@tryptichon I plan on Redoing the menu entirely in another PR as It needs some love :) It will also allow for a lot of flexibility in options. Like log Location etc. Having a whole separate Options Screen with inputs that track to Reg or JSON file locally. Allowing user to maintain settings over time.
Also, Maybe we should turn this into a 1 Click Application or if someone has a license and cert sign the application due to the traction it's getting from famous YouTuber (Just a thought).
@xmikedanielsx Okay. A complete options screen would make a simple "Select Hardware" dialog obsolete, since this should then be part of the options. :) And it's the better solution IMHO anyway.
Some of this stuff incl dark mode could easily be sorted using this open source github/NuGet packed. https://github.com/MaterialDesignInXAML/MaterialDesignInXamlToolkit . I'm using it for 2 of my apps, and it works very well and very easy to set up for an existing .net project. And also in Visual studio, maybe make it into an .msi installer with they deployment project and I do this without any cert also. windows will just promt ppl with a warning.
@xmikedanielsx Okay. A complete options screen would make a simple "Select Hardware" dialog obsolete, since this part should then be part of the options. :) And it's the better solution IMHO anyway.
Yup, AGILE My Friend Agile! .. haha. Quick Fix until Good Fix :)
Some of this stuff incl dark mode could easily be sorted using this open source github/NuGet packed. https://github.com/MaterialDesignInXAML/MaterialDesignInXamlToolkit . I'm using it for 2 of my apps, and it works very well and very easy to set up for an existing .net project.
If standard components were used for the tree view maybe. But it's nested in a bunch of custom components (aga Components). While possible It's a lot of work. Dark Mode is going to suck to do properly. UI will need to be torn apart it feels like.. I already started to take a stab at it and doing it a quick fix route. But it's trouble. Object. AllNodes Object.Nodes etc.. I am concentrating on other things atm so won't be for a little bit until I can focus on this again. But if you want to take it on by all means go for it.
As for the msi installer or ClickOnce application by all means go for it. I mentioned it above as well. Keep in mind, there is no true need for it to be clickonce unless it's going to be maintained and the updates are published on web outside of GitHub for purposes of auto update. If not people will have to keep uninstalling and installing. But if we have anyone that wants to volunteer webspace for it. We can publish all of that to the webspace and enable auto update for the people that want it. I think the current format (after rethinking) makes sense to just be a runtime app.
@xmikedanielsx I would advise against the ClickOnce-methodology from Microsoft. ClickOnce-Applications are heavily coupled with their backend and might behave funky if they're used without a network - which might be a valid use case for this kind of software. Also maintaining ClickOnce-applications is a hassle.
The way I see it we can try to go one of two other routes:
- msi-installer, and the main program checks automatically for updates at the start. That's the way many other projects do it, i.e. HeidiSQL, KeePass and many more.
- The "evil" solution ;) Make the software available from the Windows Store. That's the way KODI does it and would have the advantage of updates being handled automatically every time a release is created. Although I do not have any experience with that route - maybe there are other hurdles I do not see here.
Some of this stuff incl dark mode could easily be sorted using this open source github/NuGet packed. https://github.com/MaterialDesignInXAML/MaterialDesignInXamlToolkit . I'm using it for 2 of my apps, and it works very well and very easy to set up for an existing .net project.
If standard components were used for the tree view maybe. But it's nested in a bunch of custom components (aga Components). While possible It's a lot of work. Dark Mode is going to suck to do properly. UI will need to be torn apart it feels like.. I already started to take a stab at it and doing it a quick fix route. But it's trouble. Object. AllNodes Object.Nodes etc.. I am concentrating on other things atm so won't be for a little bit until I can focus on this again. But if you want to take it on by all means go for it.
As for the msi installer or ClickOnce application by all means go for it. I mentioned it above as well. Keep in mind, there is no true need for it to be clickonce unless it's going to be maintained and the updates are published on web outside of GitHub for purposes of auto update. If not people will have to keep uninstalling and installing. But if we have anyone that wants to volunteer webspace for it. We can publish all of that to the webspace and enable auto update for the people that want it. I think the current format (after rethinking) makes sense to just be a runtime app.
I might take a swing at it. atm im just busy updating and adding a new addition to one of my apps. About the msi install I can see if no website ect, that might not the trouble worth. But my app dont have auto update. ppl just run a new version msi installer and it updates the already installed one. But to say I'm just a self learned C# hobby coder having some fun. I already downloaded the source to look at. If I get somewhere I will def hit you up in here. Great work btw. and Happy coding
@xmikedanielsx I would advise against the ClickOnce-methodology from Microsoft. ClickOnce-Applications are heavily coupled with their backend and might behave funky if they're used without a network - which might be a valid use case for this kind of software. Also maintaining ClickOnce-applications is a hassle.
The way I see it we can try to go one of two other routes:
- msi-installer, and the main program checks automatically for updates at the start. That's the way many other projects do it, i.e. HeidiSQL, KeePass and many more.
- The "evil" solution ;) Make the software available from the Windows Store. That's the way KODI does it and would have the advantage of updates being handled automatically every time a release is created. Although I do not have any experience with that route - maybe there are other hurdles I do not see here.
Yeah as I thought about it more. It makes more sense to be a runtime app or....... as you said (not me .. haha). Microsoft Store.
Sorry was too fast to just use this NuGet packed. I thought the app was made in WPF and not windows forms.
@xmikedanielsx Okay. A complete options screen would make a simple "Select Hardware" dialog obsolete, since this part should then be part of the options. :) And it's the better solution IMHO anyway.
Yup, AGILE My Friend Agile! .. haha. Quick Fix until Good Fix :)
Well then ... throwing my "Quick Fix" into the ring. #1400
@tryptichon .. Well done. Looked at it. Not my favorite implementation as it is completely different from the rest of the menu and how it functions. But it does indeed solve his issue :)
@tryptichon .. Well done. Looked at it. Not my favorite implementation as it is completely different from the rest of the menu and how it functions. But it does indeed solve his issue :)
First steps towards the "Options Screen" you mentioned before. ;)
@xmikedanielsx I should add a keyboard shortcut for this menuitem: "Ctrl-J" ... just for Jay.
.... aaaaand done. 😁
@PhyxionNL - Quite a few outstanding PRs. Need help for QC or QA let the community know we can provide support. Let's keep the project moving ! . Go Devs Go! :)
Here is a list of what he requested in his video:
- [ ] Dark mode (even simple one)
- [x] Do not close dropdowns when checking/unchecking options
- [ ] Shift key to select/unselect multiple sensor
- [ ] Record indicator when logging to csv file
- [ ] Only log out checked sensor
- [x] One csv file per record session (instead of per day)
- [ ] Change plot scale (y axis)
- [x] Auto resize sensor column width
I've already started fixing some of those here. Please let me know if you want to take some of them.
Little tip: If you wanted to keep your checklist up to date, instead of manually writing off the list, reference the issue (or better the applicable PR if present). If GitHub tracks this correctly, once closed the checkbox will be automatically ticked.
i can take on dark mode
Looks like all that's left is just verifying that Dark Mode isn't in a "broken" state via PR #847. Currently I believe what's blocking the PR from being merged is this issue here: https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/pull/847#issuecomment-1831663046 - although I'm unable to replicate this... for now.
What we really need for traction is just QA testing this PR for any Dark Mode requests and try to break it if possible or further suggested improvements if any arise.
Here is a list of what he requested in his video:
- [ ] Dark mode (even simple one)
- [x] Do not close dropdowns when checking/unchecking options
- [ ] Shift key to select/unselect multiple sensor
- [ ] Record indicator when logging to csv file
- [ ] Only log out checked sensor
- [x] One csv file per record session (instead of per day)
- [ ] Change plot scale (y axis)
- [x] Auto resize sensor column width
I've already started fixing some of those here. Please let me know if you want to take some of them.
Little tip: If you wanted to keep your checklist up to date, instead of manually writing off the list, reference the issue (or better the applicable PR if present). If GitHub tracks this correctly, once closed the checkbox will be automatically ticked.
Thanks for the tips, I didn't knew. There is an urgent need for cleaning the issue on this repo, you've pointed out some duplicate, and I reckon properly tagging them is a must. As a contributor do you have any right to do any of that? I would be happy to help but it's the first time I contribute to this repo 😅
Here is a list of what he requested in his video:
- [ ] Dark mode (even simple one)
- [x] Do not close dropdowns when checking/unchecking options
- [ ] Shift key to select/unselect multiple sensor
- [ ] Record indicator when logging to csv file
- [ ] Only log out checked sensor
- [x] One csv file per record session (instead of per day)
- [ ] Change plot scale (y axis)
- [x] Auto resize sensor column width
I've already started fixing some of those here. Please let me know if you want to take some of them.
Little tip: If you wanted to keep your checklist up to date, instead of manually writing off the list, reference the issue (or better the applicable PR if present). If GitHub tracks this correctly, once closed the checkbox will be automatically ticked.
Thanks for the tips, I didn't knew. There is an urgent need for cleaning the issue on this repo, you've pointed out some duplicate, and I reckon properly tagging them is a must. As a contributor do you have any right to do any of that? I would be happy to help but it's the first time I contribute to this repo 😅
Since I'm merely someone who'll contribute via PRs, I don't have maintaining rights. However, I do agree that some tagging could be a bit useful. Via labels could be some use.
That being said, duplicates are bound to happen on any platform - it's a necessary evil that is impossible to avoid. Either by users desperately wanting something that they want to just write out what they want before utilizing the searching skills that they might have to search for duplicates first.
Usually when I maintain repositories (at least recent ones), one of the first few requirements I make users fill out is "What keywords have you used for potential duplicates?" - That way, if the user hasn't done that yet, they get that opportunity to search first, and then either upvote what they want, or offer further suggestions.
At the end of the day, end users who want to search for what's been already asked for will be through terminology that they are familiar with.
Here is a list of what he requested in his video:
- [ ] Dark mode (even simple one)
- [x] Do not close dropdowns when checking/unchecking options
- [ ] Shift key to select/unselect multiple sensor
- [ ] Record indicator when logging to csv file
- [ ] Only log out checked sensor
- [x] One csv file per record session (instead of per day)
- [ ] Change plot scale (y axis)
- [x] Auto resize sensor column width
I've already started fixing some of those here. Please let me know if you want to take some of them.
Little tip: If you wanted to keep your checklist up to date, instead of manually writing off the list, reference the issue (or better the applicable PR if present). If GitHub tracks this correctly, once closed the checkbox will be automatically ticked.
Thanks for the tips, I didn't knew. There is an urgent need for cleaning the issue on this repo, you've pointed out some duplicate, and I reckon properly tagging them is a must. As a contributor do you have any right to do any of that? I would be happy to help but it's the first time I contribute to this repo 😅
Since I'm merely someone who'll contribute via PRs, I don't have maintaining rights. However, I do agree that some tagging could be a bit useful. Via labels could be some use.
That being said, duplicates are bound to happen on any platform - it's a necessary evil that is impossible to avoid. Either by users desperately wanting something that they want to just write out what they want before utilizing the searching skills that they might have to search for duplicates first.
Usually when I maintain repositories (at least recent ones), one of the first few requirements I make users fill out is "What keywords have you used for potential duplicates?" - That way, if the user hasn't done that yet, they get that opportunity to search first, and then either upvote what they want, or offer further suggestions.
At the end of the day, end users who want to search for what's been already asked for will be through terminology that they are familiar with.
100% agree with you. What I meant was that it will be nice to have more people with some right to tag/label and even maybe close some issues. So when a duplicates comes in, we can tag it duplicate, and close it with a message pointing to the original. And just keep the issues clean or at least organized.