Allow only foreground or only background in color triggers

[Vadim Peretokin]

Color triggers right now enforce a foreground *and* a background color. If the user changes their default Mudlet background color to a custom one, both triggers that only want the foreground color will fail, and it will be impossible to adjust them to the custom color as well.

[Stephen Lyons (slysven)]

I think I spotted this when I I was prototyping something to create a GUI means to specify more than the the basic 16 ANSI Colours as a Colour Trigger in the editor. When a new row (previously blank) there is created as a colour trigger both the foreground and background colours are set as (our) pseudo-ansi code value 0 which I thought meant "ignored" but actually seems to be the current "default"(?) fore or background colour. Value 1 is "Bright Black" or ANSI SGR code 8(?) and 2 is "Black" or ANSI SGR code 0 all the way up to 16 ==> ANSI SGR code 7 for "White" {the mapping seems a little counter-intuitive to me, but then "hey, I think rain is wet so who am I to say!" [as the late D. Adams might put it]}.

As it stands the current GUI does not provide a means to reset a fore or back ground to that 0 value. I have a revised color_trigger.ui form and supporting revisions elsewhere so that the GUI includes two additional buttons, one to "reset" the colour and the other to switch to a form/dialogue that allows the user to specify the other 216 6x6x6 r,b,g and the 24 grey-scale colours that complete the 256-Color ANSI range.

Does this address this issue - or are you talking about a separate but somewhat related issue in that a colour trigger for our colour code 0 (NOT ANSI Color 0 which is "black") does not produce a colour "Wildcard" type action?

When we test for colour in a trigger are we matching on the "encoded" colour index value or for specific r,g,b - the values for the latter can be duplicated across the three parts of the 256 Colour Extended Range. Indeed I am suspicious of the multipliers used to convert from the 6x6x6 value that a particular (r,b,g)-colour ANSI index {those in range 16-232}) AND the greyscale{233-255} yields - we have used 42 for the former but I think we should be using 51 and 10 for the latter whereas I think 11 is a better choice. Nevertheless ANSI SGR values 0, 17 and 233 all map to black as the Server might send them so do we match on those values (I think we have to) or the black colour that they ought to yield?

[Vadim Peretokin (vperetokin)]

Yes that would address the issuse.

On Mon, Jan 19, 2015 at 6:26 AM, Stephen Lyons <email address hidden>
wrote:

> I think I spotted this when I I was prototyping something to create a
> GUI means to specify more than the the basic 16 ANSI Colours as a Colour
> Trigger in the editor. When a new row (previously blank) there is
> created as a colour trigger both the foreground and background colours
> are set as (our) pseudo-ansi code value 0 which I thought meant
> "ignored" but actually seems to be the current "default"(?) fore or
> background colour. Value 1 is "Bright Black" or ANSI SGR code 8(?) and
> 2 is "Black" or ANSI SGR code 0 all the way up to 16 ==> ANSI SGR code 7
> for "White" {the mapping seems a little counter-intuitive to me, but
> then "hey, I think rain is wet so who am I to say!" [as the late D.
> Adams might put it]}.
>
> As it stands the current GUI does not provide a means to reset a fore or
> back ground to that 0 value. I have a revised color_trigger.ui form and
> supporting revisions elsewhere so that the GUI includes two additional
> buttons, one to "reset" the colour and the other to switch to a
> form/dialogue that allows the user to specify the other 216 6x6x6 r,b,g
> and the 24 grey-scale colours that complete the 256-Color ANSI range.
>
> Does this address this issue - or are you talking about a separate but
> somewhat related issue in that a colour trigger for our colour code 0
> (NOT ANSI Color 0 which is "black") does not produce a colour "Wildcard"
> type action?
>
> When we test for colour in a trigger are we matching on the "encoded"
> colour index value or for specific r,g,b - the values for the latter can
> be duplicated across the three parts of the 256 Colour Extended Range.
> Indeed I am suspicious of the multipliers used to convert from the 6x6x6
> value that a particular (r,b,g)-colour ANSI index {those in range
> 16-232}) AND the greyscale{233-255} yields - we have used 42 for the
> former but I think we should be using 51 and 10 for the latter whereas I
> think 11 is a better choice. Nevertheless ANSI SGR values 0, 17 and 233
> all map to black as the Server might send them so do we match on those
> values (I think we have to) or the black colour that they ought to
> yield?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1143209
>
> Title:
> Allow only foreground or only background in color triggers
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mudlet/+bug/1143209/+subscriptions
>

[Vadim Peretokin (vperetokin)]

Migrating issues to Github, please follow the new discussion here: https://github.com/Mudlet/Mudlet/issues/477

This issue needs to be closed and there is no appropriate status, so will set it to "Opinion" just for migration purposes.