Topics

GTK L&F and DecoderPro

Svata Dedic
 

Hi,

a colleague has pointed out that DecoderPro has some difficulties with GTK L&F; at least JTextFields and JComboBoxes in GTK L&F do not show the CV variable's status because of https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5043225 and https://bugs.openjdk.java.net/browse/JDK-6531760 - it's an old known bug.

I don't suppose anyone will ever going to fix that in Swing, see comments in 6531760, so if GTK is to be supported for DecoderPro, it should be probably fixed in the application.

Since some operations (write all changed, read all changed) rely on that the user knows (= some indication tells him) what the changes are, just documenting the behaviour in GTK equals to "do not use GTK+ at all". It's a polite way of disabling GTK+ in the L&F selection in JMRI preferences, IMHO.

So first question: *is GTK+ Look and Feel supposed to be still supported by the JMRI family of applications ?*

If not worth the effort, I would recommend to remove it from the Preferences panel.

In case GTK should be supported, I propose to fix the behaviour in JMRI once and for all ;)
I've explored two ways:
0/ I've tried compositing the status color over the original painting. Not satisfactory, as the text was too blended in the status color, or the status color was too light - in both cases contrast of the text was bad.
I don't recommend that.

1/ converting native-painted background color to the swing-provided one. Works, but looks bad as font contours and antialiasing will suffer when converting pixels one-by-one. The text was more or less readable though. Color-converting an area of pixels is costs some cycles, although the user won't probably notice. And I suppose that different controls may need to use slightly different hacks to paint the color

2/ adding a border around the control. This seems good, as it can be used for combo boxes as well as text fields, and do not even require subclassing, so implementation-wise is trivial and can be applied to other controls where GTK+ background overrides the status color.
The drawback is that controls do not have an uniform appearance of the status indication.
Screenshot is attached.

Thanks,
-Svata

Randall Wood <rhwood@...>
 

GTK will remain supported.

JMRI 4.16 introduced a new mechanism for showing state that does not rely on background color, but it has not been implemented in every location where we show state indicators. It is currently used in some NamedBean selectors (to see an example, try adding a new turnout from a Turnout table).

Note that using just color to show state is also, regardless of L&F, means that JMRI is not friendly to color blind or vision impaired users.

Randall

On Sep 29, 2019, at 13:07, Svata Dedic <svatopluk.dedic@...> wrote:

Hi,

a colleague has pointed out that DecoderPro has some difficulties with GTK L&F; at least JTextFields and JComboBoxes in GTK L&F do not show the CV variable's status because of https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5043225 and https://bugs.openjdk.java.net/browse/JDK-6531760 - it's an old known bug.

I don't suppose anyone will ever going to fix that in Swing, see comments in 6531760, so if GTK is to be supported for DecoderPro, it should be probably fixed in the application.

Since some operations (write all changed, read all changed) rely on that the user knows (= some indication tells him) what the changes are, just documenting the behaviour in GTK equals to "do not use GTK+ at all". It's a polite way of disabling GTK+ in the L&F selection in JMRI preferences, IMHO.

So first question: *is GTK+ Look and Feel supposed to be still supported by the JMRI family of applications ?*

If not worth the effort, I would recommend to remove it from the Preferences panel.

In case GTK should be supported, I propose to fix the behaviour in JMRI once and for all ;)
I've explored two ways:
0/ I've tried compositing the status color over the original painting. Not satisfactory, as the text was too blended in the status color, or the status color was too light - in both cases contrast of the text was bad.
I don't recommend that.

1/ converting native-painted background color to the swing-provided one. Works, but looks bad as font contours and antialiasing will suffer when converting pixels one-by-one. The text was more or less readable though. Color-converting an area of pixels is costs some cycles, although the user won't probably notice. And I suppose that different controls may need to use slightly different hacks to paint the color

2/ adding a border around the control. This seems good, as it can be used for combo boxes as well as text fields, and do not even require subclassing, so implementation-wise is trivial and can be applied to other controls where GTK+ background overrides the status color.
The drawback is that controls do not have an uniform appearance of the status indication.
Screenshot is attached.

Thanks,
-Svata



<gtk-status.png>

Svata Dedic
 

Dne 29. 09. 19 v 21:45 Randall Wood via Groups.Io napsal(a):
JMRI 4.16 introduced a new mechanism for showing state that does not rely on background color, but it has not been implemented in every location where we show state indicators. It is currently used in some NamedBean selectors (to see an example, try adding a new turnout from a Turnout table).
Adding a turnout - to where ?

-Svata

Randall Wood <rhwood@...>
 

In PanelPro, go to Tools->Tables->Turnout. Click “Add …”. Observe how, as you edit the name, an icon indicating validation state changes. You don’t need to save the turnout.

In DecoderPro, go to File->Open PanelPro Window, and in the PanelPro window go to ->Tools->Tables->Turnout.

On Sep 29, 2019, at 15:56, Svata Dedic <svatopluk.dedic@...> wrote:

Dne 29. 09. 19 v 21:45 Randall Wood via Groups.Io napsal(a):
JMRI 4.16 introduced a new mechanism for showing state that does not rely on background color, but it has not been implemented in every location where we show state indicators. It is currently used in some NamedBean selectors (to see an example, try adding a new turnout from a Turnout table).
Adding a turnout - to where ?

-Svata



Svata Dedic
 

Apologies; I routinely use master (I suppose 4.17 bleeding edge); I've noticed a validation indicator in the input line for "Hardware Address" (using XPressNet simulator; don't know whether terminology varies when using other connections).

Is it that new thing ?

I've installed 4.16 release, and when I am adding a turnout in 4.16 (or compiled from branch release-4.16.1), I can see
- yellow background in textfield initially
- orange background in textfield for invalid input (non-number)
- default background for valid input.
but only for the "Hardware Address"; no decorations / changes at all for "User Name" field.
There's no "Name" field.
Using Nimbus L&F.

Thanks,
-Svata

Dne 29. 09. 19 v 21:59 Randall Wood via Groups.Io napsal(a):

In PanelPro, go to Tools->Tables->Turnout. Click “Add …”. Observe how, as you edit the name, an icon indicating validation state changes. You don’t need to save the turnout.
In DecoderPro, go to File->Open PanelPro Window, and in the PanelPro window go to ->Tools->Tables->Turnout.

On Sep 29, 2019, at 15:56, Svata Dedic <svatopluk.dedic@...> wrote:

Dne 29. 09. 19 v 21:45 Randall Wood via Groups.Io napsal(a):
JMRI 4.16 introduced a new mechanism for showing state that does not rely on background color, but it has not been implemented in every location where we show state indicators. It is currently used in some NamedBean selectors (to see an example, try adding a new turnout from a Turnout table).
Adding a turnout - to where ?

-Svata



Randall Wood <rhwood@...>
 

Looking through the history, you’re right; it was introduced in 4.17.2, right after 4.16 was released (I got the timelines wrong, because the work predates the 4.16 release, even though it was not in it).

On Sep 29, 2019, at 16:30, Svata Dedic <svatopluk.dedic@...> wrote:

Apologies; I routinely use master (I suppose 4.17 bleeding edge); I've noticed a validation indicator in the input line for "Hardware Address" (using XPressNet simulator; don't know whether terminology varies when using other connections).

Is it that new thing ?

I've installed 4.16 release, and when I am adding a turnout in 4.16 (or compiled from branch release-4.16.1), I can see
- yellow background in textfield initially
- orange background in textfield for invalid input (non-number)
- default background for valid input.
but only for the "Hardware Address"; no decorations / changes at all for "User Name" field.
There's no "Name" field.
Using Nimbus L&F.

Thanks,
-Svata

Dne 29. 09. 19 v 21:59 Randall Wood via Groups.Io napsal(a):
In PanelPro, go to Tools->Tables->Turnout. Click “Add …”. Observe how, as you edit the name, an icon indicating validation state changes. You don’t need to save the turnout.
In DecoderPro, go to File->Open PanelPro Window, and in the PanelPro window go to ->Tools->Tables->Turnout.
On Sep 29, 2019, at 15:56, Svata Dedic <svatopluk.dedic@...> wrote:

Dne 29. 09. 19 v 21:45 Randall Wood via Groups.Io napsal(a):
JMRI 4.16 introduced a new mechanism for showing state that does not rely on background color, but it has not been implemented in every location where we show state indicators. It is currently used in some NamedBean selectors (to see an example, try adding a new turnout from a Turnout table).
Adding a turnout - to where ?

-Svata





Bob Jacobsen
 

Although it’s certainly good to be "friendly to color blind or vision impaired users”, please note that the color values applied as the DecoderPro highlights are known to work for the most common forms of dichromacy and anomalous trichromacy (the various *nopia and *anomaly forms) via their intensity and saturation cues so long as those color values are applied to saturation (i.e. as areas, not lines or fonts). In other words, only a couple people per thousand will have trouble with those.

I don’t have a strong opinion about other forms of cuing, but if you do use colors, please try to stick to the java.awt.Color red.brighter(), yellow, orange and blue forms. If you need color discrimination, don’t pick non-standard color values, and don’t use pink, green, cyan, or magenta.

Bob


On Sep 29, 2019, at 12:45 PM, Randall Wood via Groups.Io <rhwood=mac.com@groups.io> wrote:

Note that using just color to show state is also, regardless of L&F, means that JMRI is not friendly to color blind or vision impaired users.
--
Bob Jacobsen
@BobJacobsen

Svata Dedic
 

Hi,

Dne 29. 09. 19 v 21:45 Randall Wood via Groups.Io napsal(a):
JMRI 4.16 introduced a new mechanism for showing state that does not rely on background color

OK; so if we (both) mean the "Hardware address" input validation, then the API (com.alexandriasoftware.swing.Validation) may be valid for user input states, or perhaps some system health states - but I don't think DecoderPro statuses (jmri.jmrit.symbolicprog.AbstractValue.{UNKNOWN, EDITED, ...}) does not seem to be easily mapped to the enum in Validation result object.

Is the API really meant for this scenario as well ?

BTW is it working somewhere for some not-one-line type of control ? JList or JTable, for example ?

I am particularly "not excited" about potential visual clutter. Giving an indicator in a focused field is good to attract attention. The same for broken/dangerous values that prevent completion of an operation.

But if all fields in the dialog (see my picture) would be accompanied by a 'state' icon next to them - the reult could be visually quite messy. It will surely work for probably everyone, but will be effective for the majority as well ?

So if that is the way to go (is it an approved consistency rule ?), the non-error icon appearance should be (IMHO) driven by an option - will allow anyone to emphasize as needed, but should not break UI for the majority audience.

Dne 29. 09. 19 v 22:42 Bob Jacobsen napsal(a):
Although it’s certainly good to be "friendly to color blind or vision impaired users”, please note that the color values applied as the DecoderPro highlights are known to work for the most common forms of dichromacy and anomalous trichromacy (the various *nopia and *anomaly forms) via their intensity and saturation cues so long as those color values are
Anyway, I wanted to solve GTK+ behaviour. Right now we have GTK+ look and feel, which works for nobody.

The attached picture is a workable workaround for (broken) GTK+ specifically, not affecting other L&Fs. The line border is too subtle to work well for vision-impaired people, I am afraid. The idea was to not break the layout that much, make it work in >= 50% of cases - and there's always possibility to select L&F that performs visually better.

-Svata

Randall Wood <rhwood@...>
 

Some vision impairments require “hi contest” displays that are grey scale with minimal steps between colors or are black and white. In these cases colored borders and background colors are invisible. Since I’ve friends with that inability to use color, I am sensitive to the need to use shape.

On Sep 29, 2019, at 16:42, Bob Jacobsen <@BobJacobsen> wrote:

Although it’s certainly good to be "friendly to color blind or vision impaired users”, please note that the color values applied as the DecoderPro highlights are known to work for the most common forms of dichromacy and anomalous trichromacy (the various *nopia and *anomaly forms) via their intensity and saturation cues so long as those color values are applied to saturation (i.e. as areas, not lines or fonts). In other words, only a couple people per thousand will have trouble with those.

I don’t have a strong opinion about other forms of cuing, but if you do use colors, please try to stick to the java.awt.Color red.brighter(), yellow, orange and blue forms. If you need color discrimination, don’t pick non-standard color values, and don’t use pink, green, cyan, or magenta.

Bob


On Sep 29, 2019, at 12:45 PM, Randall Wood via Groups.Io <rhwood=mac.com@groups.io> wrote:

Note that using just color to show state is also, regardless of L&F, means that JMRI is not friendly to color blind or vision impaired users.
--
Bob Jacobsen
@BobJacobsen





Bob Jacobsen
 

If the goal is to change how the GTK Look and Feel looks, the possible solutions seem to be:

- (my preferred choice) add modifications to the GTK L&F to automatically make the UI elements colorable. Not sure if it’s sufficient to just set them opaque, or it something else is needed. The easiest way to do this would be to distribute a JMRI updated version of the GTK L&F that appears if the GTK L&F is present (we used to do this IIRC for another L&F, but maybe that was a different project)

- change lots and lots of places in JMRI to be L&F specific, adding specific corrections when GTK is in use. That seems like a maintenance and consistency nightmare that’s not worth it.

Changing how DecoderPro windows work in other L&Fs, which has been a success for over 15 years, seems like a disproportionate response. There are thousands of people using those, and they’re happen with how they look and operate.

Nor does it make sense to veto use of the GTK L&F. If people want to use it, that’s up to them. Nobody else is being harmed.

Bob
--
Bob Jacobsen
@BobJacobsen

Randall Wood <rhwood@...>
 

On Sep 29, 2019, at 17:53, Svata Dedic <svatopluk.dedic@...> wrote:

Hi,

Dne 29. 09. 19 v 21:45 Randall Wood via Groups.Io napsal(a):
JMRI 4.16 introduced a new mechanism for showing state that does not rely on background color

OK; so if we (both) mean the "Hardware address" input validation, then the API (com.alexandriasoftware.swing.Validation) may be valid for user input states, or perhaps some system health states - but I don't think DecoderPro statuses (jmri.jmrit.symbolicprog.AbstractValue.{UNKNOWN, EDITED, ...}) does not seem to be easily mapped to the enum in Validation result object.
The 7 states in AbstractValue are shown to users as only 3 states. Since the JInputValidator API supports changing how any of its 6 states are shown (using both icons and colors), it could be used to show the 7 states.

Is the API really meant for this scenario as well ?
Its meant for any scenario where the state of something needs to be shown. It is based on the Red Hat UI states, of which there are only 6 colors for showing different states (there may be more states for something, but they get reduced to these items).

I’m more suggesting the Border in that API be used for showing reading/writing/pending change states, not that the validator be used (a validator would need to be used for other issues, like trying to set an address to 12345).

BTW is it working somewhere for some not-one-line type of control ? JList or JTable, for example ?

I am particularly "not excited" about potential visual clutter. Giving an indicator in a focused field is good to attract attention. The same for broken/dangerous values that prevent completion of an operation.

But if all fields in the dialog (see my picture) would be accompanied by a 'state' icon next to them - the reult could be visually quite messy. It will surely work for probably everyone, but will be effective for the majority as well ?

So if that is the way to go (is it an approved consistency rule ?), the non-error icon appearance should be (IMHO) driven by an option - will allow anyone to emphasize as needed, but should not break UI for the majority audience.

Dne 29. 09. 19 v 22:42 Bob Jacobsen napsal(a):
Although it’s certainly good to be "friendly to color blind or vision impaired users”, please note that the color values applied as the DecoderPro highlights are known to work for the most common forms of dichromacy and anomalous trichromacy (the various *nopia and *anomaly forms) via their intensity and saturation cues so long as those color values are
Anyway, I wanted to solve GTK+ behaviour. Right now we have GTK+ look and feel, which works for nobody.

The attached picture is a workable workaround for (broken) GTK+ specifically, not affecting other L&Fs. The line border is too subtle to work well for vision-impaired people, I am afraid. The idea was to not break the layout that much, make it work in >= 50% of cases - and there's always possibility to select L&F that performs visually better.
GTK (as well as other L&Fs) uses changes in border color and thickness to indicate the current selected or focused control.

-Svata


Svata Dedic
 

Hi,

Dne 30. 09. 19 v 0:17 Bob Jacobsen napsal(a):
- (my preferred choice) add modifications to the GTK L&F to automatically make the UI elements colorable. Not sure if it’s sufficient to just set them opaque, or it something
GTK L&F is delegating much of the painting on the native components: opaque property does not work for that same reason (working with opaque was the first thing I've tried).

I personally would not recommend this path:
- L&F changes needs to be done per-component-type
- reimplemented paint will not respect native L&F customization / settings.
- will affect *all* components of the certain type, potentially making the "normal" one divergent from native UI style without any added benefit
- may need to support various GTK version styles (different distros use different GTKs)
- (less important, as virtually no development is done in Swing) need to re-visit on new release of JDK and/or GTK libraries.

I have rather bad experience with changing L&F delegates, so I don't think I could deliver any good to JMRI in this area.

- change lots and lots of places in JMRI to be L&F specific, adding specific corrections when GTK is in use. That seems like a maintenance and consistency nightmare that’s not
But - to summarize - given the general pushback to the idea, I'll leave the working diff for DecoderPro GTK+ users in my private repository; not my major focus anyway.

Let's have some additional time before someone else picks the defective behaviour on GTK+, hope we won't celebrate another 5 years or so with this bug.

Thank you for your feedback,
-Svata