feat(bw128): add customisable switches edit page, allow editing custom colors #5799
Conversation
…ing custom color.
e09964c to
15701f5
Compare
|
Looking good here. Should it be detecting ... preset? ... colours in more than one place? i.e. Red is detected at both 255,0,0 and 248,0,0, and same for other colours. |
Yes - at the moment. The original version distributed with the GX12 was using 0xF8 (248) color values. I changed this to 255; but kept a check for both. Something that could be removed in the future. |
|
See what @3djc thinks when he wakes up. The firmware that was shipped with hardware was unsupported pre-release / preview, so IMO it is better to "fix" it now, rather than perpetuate a state that won't be used going forward. It is expected that there could be breakages with updates to the officlally supported release firmware, to the point where configuration |
|
Makes sense - I've removed the extra check. I added it in #5776 so that the names shown would not change to 'Custom'. Since you can now see the values it's less of an issue. |
|
I'll merge this now then, and if JC thinks differently we can just revert the last commit or similar. |
|
I think this is overdoing it, and I whished we could go back to colorlcd as well and simplify it. A pick of usual 6 to 8 named color is likely more than enough, especially because color rendering of those led is pretty bad |
|
The option to select from the fixed colors is still there. |
|
This is really the best of both... If you want to use preset colours, just
pick from them. If you want to tweak the colours, you can just adjust them.
Plus no need to keep reading and writing with Companion if you are after a
particular colour/shade, and no need to wait for us to add more (which
probably wouldn't really happen anyway). Really nice being able to just
"live edit" the colours, and more space to make UI more descriptive.
…On Mon, 20 Jan 2025, 5:27 pm philmoz, ***@***.***> wrote:
The option to select from the fixed colors is still there.
—
Reply to this email directly, view it on GitHub
<#5799 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ66KNR3WW7WAIKEHATRML2LSQPRAVCNFSM6AAAAABVNE7HW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBRGYYTINZUGA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
Forgive me if this isn't the right place to ask this but is the plan to add similar support for SA and SD on the GX12? These seem like they would benefit from the same type of configuration of color / toggle type etc.. |
|
Ideally, we would have liked to setup sa/sd as customisable switch,, but there are currently underlying issues that would make it too confusing |
|
Ah ok. Out of curiosity is that a hardware or software issue? The LEDs for those switches are adjustable via lua then? |
At the moment they can't be changed. |
Software issue. Mainly a matter of figuring out how to present configuration options in an intuitive manner. You do have control over whether they as momentary or 2POS switches in nightly firmware though, just not colours. |
|
I loaded the nightly and honestly would have been fine seeing those two
switches in the same place as the other six, just in their own groups. (or
no group at all)
Where is the 2pos vs momentary controlled? (and does the LED toggle with?)
…On Wed, Jan 22, 2025, 7:31 PM Peter Feerick ***@***.***> wrote:
Ah ok. Out of curiosity is that a hardware or software issue? The LEDs for
those switches are adjustable via lua then?
Software issue. Mainly a matter of figuring out how to present in in an
initiative manner.
You do have control over whether they as momentary or 2POS switches in
nightly firmware though, just not colours.
—
Reply to this email directly, view it on GitHub
<#5799 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJBAYXZQQYSHUXHY6GBDL2MBPB5AVCNFSM6AAAAABVNE7HW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYG43TGMJTGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Radio -> Hardware page. |
That would be my preference - setting them per model the same as the other customisable switches. |
|
I somewhat agree, but also think it should also have a global option (i.e. similar to the ADC jitter filter, enabled features, etc) so you don't need to define them on a per model basis if you don't want to (i.e. it would default to a hardware settings value). They probably do need to be seperate to the other six customisable switches due to physical location/ logical grouping as a 6POS, as well as having slightly different settings, but that would probably be all - i.e. doesn't need another screen or anything. Just some sort of separation in the layout. |
|
The issue is one of ordering, a software one. 'things' are presented grouped, switch are no exception. If put part of customisable switches (which would have been my preference), switch order would become SB, SC, SE, SF, SH, SW1..SW6, SA, SD when you scroll through those. That would confuse users. We need somewhat deep software changes to be abale to display in another order. |
|
Yes, as it still needs to be SA, SB, etc... but the important thing that
needs to be known is we are thinking about it. ;)
…On Thu, 23 Jan 2025, 5:41 pm 3djc, ***@***.***> wrote:
The issue is one of ordering, a software one. 'things' are presented
grouped, switch are no exception. If put part of customisable switches,
Switch order would become SB,SC, SD, SE, SF, SH, SW1..SW6, SA, SD. That
would confuse users. We need somewhat deep software changes to be abale to
display in another order.
—
Reply to this email directly, view it on GitHub
<#5799 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ66KP64K6UIPZ4CZ2GYZ32MCMKVAVCNFSM6AAAAABVNE7HW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBZGA3DMMRWG4>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Changes: