Allow viewing of the changelog from the WebUI

[ExtremeFiretop]

Allow viewing of the changelog from the WebUI

[ExtremeFiretop]

@Martinski4GitHub

Please review and test whenever you get a chance! :)

I changed the "Approve Changelog" button for a "Latest Changelog button" and then moved the approval into a checkbox below.. I think it looks pretty good and adds the additional functionality of the CLI: main menu --> Log Options (lo) --> Changelog (cl)

No Changelog to approve: (Grayed out)

Changelog to approve; default blocked:

Clicking the new checkbox:

Approved Changelog:

Clicking on Latest Changelog:

[ExtremeFiretop]

@Martinski4GitHub

Was just poking at one last little "bug" I noticed, all good now!
Please test whenever your ready :)

[Martinski4GitHub]

Good to go!!! And Approved!!!

[Martinski4GitHub]

@Martinski4GitHub

Was just poking at one last little "bug" I noticed, all good now! Please test whenever your ready :)

I like how the 3 buttons now have symmetry with the checkboxes below them.
The WebGUI is looking better & better with more functionality. I'd say this new version will be "ready to ship" very soon!! LOL!!

[ExtremeFiretop]

@Martinski4GitHub
Was just poking at one last little "bug" I noticed, all good now! Please test whenever your ready :)

I like how the 3 buttons now have symmetry with the checkboxes below them. The WebGUI is looking better & better with more functionality. I'd say this new version will be "ready to ship" very soon!! LOL!!

Literally my thought as well.

You know I like symmetry, i've fought for it in the past hehehe. I saw a button without a checkbox and it gave me an itch, I figured what can I add a checkbox for.

The logical choice was change the order so the approve was now a checkbox and the button was to view/fetch the log for manual review before approval. And unlike spdMerlin, I actually have been following how this works under the hood since the beginning so I have more confidence in making changes 😜

I'm happy you like the additional changes! I'll make a post to advise of the new PRs to be tested today! :)

[ExtremeFiretop]

Done. Posted :)

[ExtremeFiretop]

Oh no... You've made me think about looks again. I have more itches to scratch now....

Why is the Changelog Approval not under the Firmware Status section? And the F/W Update Check not under the Settings Status Section?

I think it would look better if we reversed it.

[ExtremeFiretop]

Symmetry-oh-symmetry. What would I do without u... 🎵🎶

[ExtremeFiretop]

vs:

[Martinski4GitHub]

vs:

I do actually think that those settings are currently in the correct place (i.e. their original position). The "F/W Update Check" is in the section with all the other settings related to F/W version & update info:

F/W Variant Detected
F/W Version Installed
F/W Update Available
Estimated Update Time
Last Notification Date

And the "Changelog Approval" was above the "Changelog Check" settings.

IOW, related items were together. Switching those settings around just for the sake of "symmetry" does not make sense to me. But then again, my design philosophy & perspective from years of s/w dev (doing front end & back end development) is always that "form follows function" NOT the other way around. IOW, function (i.e. the intended purpose, the operational significance) is always more important than form (i.e. looks, aesthetics).

In this particular case, keeping related items/settings together seems more important, IMO, than any symmetry one can perceive as "looking better" simply for its own sake.

My 2 cents.

[ExtremeFiretop]

vs:

I do actually think that those settings are currently in the correct place (i.e. their original position). The "F/W Update Check" is in the section with all the other settings related to F/W version & update info:

F/W Variant Detected F/W Version Installed F/W Update Available Estimated Update Time Last Notification Date

And the "Changelog Approval" was above the "Changelog Check" settings.

IOW, related items were together. Switching those settings around just for the sake of "symmetry" does not make sense to me. But then again, my design philosophy & perspective from years of s/w dev (doing front end & back end development) is always that "form follows function" NOT the other way around. IOW, function (i.e. the intended purpose, the operational significance) is always more important than form (i.e. looks, aesthetics).

In this particular case, keeping related items/settings together seems more important, IMO, than any symmetry one can perceive as "looking better" simply for its own sake.

My 2 cents.

In my eyes, the F/W Update Check is a setting, so it should go under settings. With a "Disabled" and "Enabled" value and nothing else. Like everything else In that section.

While the Changelog Approval, is a flashing process/detail and specific to only specific firmware versions, so it should go with the firmware status information.

Also the Changelog approval has other values other than "Enabled" and "Disabled" and is better suited with the other "TBD" values, and can go to "Approved" or "Blocked" which feels odd in the other section.

[Martinski4GitHub]

vs:

I do actually think that those settings are currently in the correct place (i.e. their original position). The "F/W Update Check" is in the section with all the other settings related to F/W version & update info:
F/W Variant Detected F/W Version Installed F/W Update Available Estimated Update Time Last Notification Date
And the "Changelog Approval" was above the "Changelog Check" settings.
IOW, related items were together. Switching those settings around just for the sake of "symmetry" does not make sense to me. But then again, my design philosophy & perspective from years of s/w dev (doing front end & back end development) is always that "form follows function" NOT the other way around. IOW, function (i.e. the intended purpose, the operational significance) is always more important than form (i.e. looks, aesthetics).
In this particular case, keeping related items/settings together seems more important, IMO, than any symmetry one can perceive as "looking better" simply for its own sake.
My 2 cents.

In my eyes, the F/W Update Check is a setting, so it should go under settings. With a "Disabled" and "Enabled" value and nothing else. Like everything else In that section.

While the Changelog Approval, is a flashing process/detail and specific to only specific firmware versions, so it should go with the firmware status information.

Also the Changelog approval has other values other than "Enabled" and "Disabled" and is better suited with the other "TBD" values, and can go to "Approved" or "Blocked" which feels odd in the other section.

Well, both are settings, just a different type of settings. In any case, it looks like we'll have to agree to disagree on this one. And ultimately, it's not a big deal and I'm already too tired tonight to continue to argue the minor points of UI design philosophy & functionality.

[ExtremeFiretop]

vs:

I do actually think that those settings are currently in the correct place (i.e. their original position). The "F/W Update Check" is in the section with all the other settings related to F/W version & update info:
F/W Variant Detected F/W Version Installed F/W Update Available Estimated Update Time Last Notification Date
And the "Changelog Approval" was above the "Changelog Check" settings.
IOW, related items were together. Switching those settings around just for the sake of "symmetry" does not make sense to me. But then again, my design philosophy & perspective from years of s/w dev (doing front end & back end development) is always that "form follows function" NOT the other way around. IOW, function (i.e. the intended purpose, the operational significance) is always more important than form (i.e. looks, aesthetics).
In this particular case, keeping related items/settings together seems more important, IMO, than any symmetry one can perceive as "looking better" simply for its own sake.
My 2 cents.

In my eyes, the F/W Update Check is a setting, so it should go under settings. With a "Disabled" and "Enabled" value and nothing else. Like everything else In that section.
While the Changelog Approval, is a flashing process/detail and specific to only specific firmware versions, so it should go with the firmware status information.
Also the Changelog approval has other values other than "Enabled" and "Disabled" and is better suited with the other "TBD" values, and can go to "Approved" or "Blocked" which feels odd in the other section.

Well, both are settings, just a different type of settings. In any case, it looks like we'll have to agree to disagree on this one. And ultimately, it's not a big deal and I'm already too tired tonight to continue to argue the minor points of UI design philosophy & functionality.

No worries. Have a goodnight bud!

Basically automatically your eyes on a new firmware update are gonna go to the Firmware Status section, why?

To get the details around the firmware version, the time of expected run time, and if there's a block in place for that version, that's ideally where it should go to see that information right away I would think. On top of the fact that it matches the other values in the section, and looks nicer 😉

[ExtremeFiretop]

Another way to look at it is this.

Every other setting in the setting section, is a setting the user controls and won't change without user control...

While other values in the firmware status section is dynamic and can change without user action, aka, going from TBD to Blocked. And then from Approved back to TBD.

[Martinski4GitHub]

Another way to look at it is this.

Every other setting in the setting section, is a setting the user controls and won't change without user control...

While other values in the firmware status section is dynamic and can change without user action, aka, going from TBD to Blocked. And then from Approved back to TBD.

Yeah, from that perspective they are settings of the same "type" and can go together.
We could argue back and forth about the merits of doing it one way vs another, but again I'm too tired tonight for further discussion. The PR is already merged and it's a done deal so there's nothing to worry about. Either way would work just fine for the end user, IMO.