Color highlighting for changed values does not work on OSX and GTK Look&Feels

[dpharris]

OSX. Changing a choice in a drop-down box does not make the box background yellow. However, on attempting to change again, the drop-down choices are yellow.

BTW -- great job on the changes so far.

[balazsracz]

Could you attach a screenshot of what you mean? (you can copy-paste images via the clipboard into the edit box of github)

unfortunately when you just changed the field, the selection highlighting is still on the field, so you get it with blue (on my UI where all java buttons are blue). However, the downwards arrow gets recolored to orange as desired.

If you click away however and into a different field, the orange background gets visible.

[dpharris]

Here's a screen grab D

…

On Tue, Nov 29, 2016 at 4:02 PM, Balazs Racz ***@***.***> wrote: Could you attach a screenshot of what you mean? unfortunately when you just changed the field, the selection highlighting is still on the field, so you get it with blue (on my UI where all java buttons are blue). However, the downwards arrow gets recolored to orange as desired. If you click away however and into a different field, the orange background gets visible. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAg4SjzGPkVuHfpR2RJnZkKDJljeCFkqks5rDL0HgaJpZM4K_nlw> .

[balazsracz]

I don't see any image.
Please send ti to me in private email.

[balazsracz]

This is what David sent:

@dpharris I'm not sure what's wrong with this picture. It's yellow, because it's edited. What is the behavior you're looking for?

Just to check: could you please go into DecoderPro, and edit or add a new roster entry and see what the behavior of the panels' coloring is (go into a CV sheet and start modifying stuff, it should follow similar coloring as in OpenLCB). Please check that

• is the behavior on your system the same in decoderpro and in the openlcb configuration editor?
• if the same, are they both bad?
• if they are different how are they different? try taking a screenshot for the two different behaviors.

I have tried to test this under linux with the four different user interface mechanisms available. Three of the four worked fine, the fourth put the background color someplace else where it was barely visible; but for that interface the DecoderPro screens were equally broken.

[dpharris]

My concern is that the closed drop-down box field is NOT yellow, so one would only know if one opens each drop-down box. David

…

On Fri, Dec 2, 2016 at 7:52 AM, Balazs Racz ***@***.***> wrote: This is what David sent: [image: image] <https://cloud.githubusercontent.com/assets/3719690/20839981/fa8bb128-b8ae-11e6-9a18-9572ec41d005.png> @dpharris <https://github.com/dpharris> I'm not sure what's wrong with this picture. It's yellow, because it's edited. What is the behavior you're looking for? Just to check: could you please go into DecoderPro, and edit or add a new roster entry and see what the behavior of the panels' coloring is (go into a CV sheet and start modifying stuff, it should follow similar coloring as in OpenLCB). Please check that - is the behavior on your system the same in decoderpro and in the openlcb configuration editor? - if the same, are they both bad? - if they are different how are they different? try taking a screenshot for the two different behaviors. I have tried to test this under linux with the four different user interface mechanisms available. Three of the four worked fine, the fourth put the background color someplace else where it was barely visible; but for that interface the DecoderPro screens were equally broken. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAg4SpJ15RZHdQTpi44FBqcCvHrurUVyks5rED6rgaJpZM4K_nlw> .

[balazsracz]

what does it look like for the decoderpro CV editing dropdowns? is it yellow background or is it not?

[balazsracz]

Could you try the branch https://github.com/openlcb/OpenLCB_Java/tree/bracz-add-colored-border
(I committed binaries for you as well to download and drop into the JMRI lib/ directory)
and tell us whether you like it?

[dpharris]

Ok. This weekend. David

…

On Fri, Dec 2, 2016 at 9:37 AM, Balazs Racz ***@***.***> wrote: Could you try the branch https://github.com/openlcb/ OpenLCB_Java/tree/bracz-add-colored-border (I committed binaries for you as well to download and drop into the JMRI lib/ directory) and tell us whether you like it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAg4SuKT9TyzcF1eQ2vfWwh40MeBFxKgks5rEFdagaJpZM4K_nlw> .

[dpharris]

Looks like the dropdown is on top of a background yellow rectangle.

[balazsracz]

@dpharris Unfortunately I have no influence on how the given widgeting system interprets the "background color" attribute that I set. So far I've seen at least three different behaviors:

1. the selected field, and the dropdown arrow has the given color instead of white background.
   This happens in the Metal (which is the cross-platform UI) and the Motif toolkit.
2. the background color is completely ignored. This happens under linux with the GTK toolkit.
3. the background color is put "behind" the widget, which only pokes out a few pixels in the rounded corners and is barely visible, as well as the background of the floating dropdown which is useless. This happens on Mac based on your screenshot.

This sucks terribly because there is no way to create a homogenous behavior across different systems. If you go into the JMRI preferences and in the "Display" section you select the cross-platform UI (i think Metal) then your JMRI will look exactly as mine, but unlike native Mac applications. Then you will get the correct behavior.

As a workaround I added a second indication that appears as a yellow rectangle drawn around the entire line. This will appear the same way in all platforms.

My question to you is whether the yellow rectangle around the line is obvious enough for you to recognize this as a changed but unsaved value.

[dpharris]

Balazs -- Sorry that this is painful :-( -- I had thought it was a simple oversight. The non-OSX choices look good, but the OSX looks unchanged. I downloaded from https://github.com/openlcb/OpenLCB_Java/tree/bracz-add-colored-border just the openlcb.jar ... but did not see the rectangle surround code. How do I ensure I am getting the latest and greatest? Thanks David

…

On Sun, Dec 4, 2016 at 8:07 AM, Balazs Racz ***@***.***> wrote: @dpharris <https://github.com/dpharris> Unfortunately I have no influence on how the given widgeting system interprets the "background color" attribute that I set. So far I've seen at least three different behaviors: 1. the selected field, and the dropdown arrow has the given color instead of white background. This happens in the Metal (which is the cross-platform UI) and the Motif toolkit. 2. the background color is completely ignored. This happens under linux with the GTK toolkit. 3. the background color is put "behind" the widget, which only pokes out a few pixels in the rounded corners and is barely visible, as well as the background of the floating dropdown which is useless. This happens on Mac based on your screenshot. This sucks terribly because there is no way to create a homogenous behavior across different systems. If you go into the JMRI preferences and in the "Display" section you select the cross-platform UI (i think Metal) then your JMRI will look exactly as mine, but unlike native Mac applications. Then you will get the correct behavior. As a workaround I added a second indication that appears as a yellow rectangle drawn around the entire line. This will appear the same way in all platforms. My question to you is whether the yellow rectangle around the line is obvious enough for you to recognize this as a changed but unsaved value. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAg4SvWJJvWXDelfY3JtzpsNp7Jld8poks5rEuUmgaJpZM4K_nlw> .

[rhwood]

macOS does not allow the ComboBox background color to change. I recommend against relying on color to convey information--it means that colorblind individuals will not see the information being conveyed by color.

I recommend using icons to indicate state instead of colors.

[balazsracz]

@rhwood : DecoderPro does use colors for state information, right?

[rhwood]

DecoderPro does use colors for state information, right?

Unfortunately DecoderPro does use color exclusively for state information in the decoder programming panes. In other places, it relies on text. (The power button uses text and color, and there may be an area of the code I am not aware of that relies on color exclusively.) I would not rely on DecoderPro, as proud as I am of it, as an example of good implementation of accessible software. That said, your implementation (including not coloring the ComboBoxes in macOS) matches the DecoderPro implementation. If you are concerned about needing to match how JMRI does something in the UI, you might want to consider implementing the widget that is of concern within JMRI, so it becomes a JMRI problem (how do you handle being a library in two different programs that use different mechanisms to indicate state?)