GTK GUIs: ugly in RHEL7 Gnome Shell

[matthewrmshin]

Colour scheme has gone very strange in Gnome Shell, with grey padding appearing in places in a white background.

[wxtim]

I didn’t solve the problem. I didn’t prove that it has no solution.

Thanks to @oliver-sanders for help. 👍

Items considered:

1. System settings

The colour sections @matthewrmshin refers to appeared to be changeable by changing the Gnome 3 theme. The same issue occurs with the “dark” theme, although it looks a great deal less ugly. The same issue did not occur in the high contrast theme, but an error message:

Gtk-WARNING **: Unable to locate theme engine in module_path: "hcengine",

appeared. I stuck this into a well known search engine and found this...

The modifications found on this page Also seemed promising, so on the off chance I tried

gsettings set org.gnome.desktop.interface gtk-theme 'gnome'
rose edit

Seem to fix the problem by reverting the appearance to that of the previous version, although I think that all settings are modified.

Looking to set this hard inside the software might provide a possible solution, although some users might prefer the buggy 'Adwaita' theme to the correct but very old-fashioned 'gnome' theme.

I also tried copying the Adwaita theme files from /usr/share/themes to ~/.themes. By changing the line

# Foreground/background
gtk-color-scheme = "fg_color:#2e3436\nbg_color:#e8e8e7"
# to
gtk-color-scheme = "fg_color:#2e3436\nbg_color:pink"
# then
gtk-color-scheme = "fg_color:#2e3436\nbg_color:white"

I was able to (with the first change) identify that the background colour of the window and the undesirable grey boxes is coming from the same place. I was able to fix the issue with the second change. Unfortunately both these changes had undesirable side effects:

1. The title bar buttons ceased to render
2. The tweak tool became largely transparent(!)

2. Checked GTK versions

Obvious, but… - Both 2.0

3. Grepping through the code in detail.

Grepped through the codebase for ‘grey’ and ‘gray’. Found a number of references, and tried changing these (to orange). Managed to create some very ugly GUIs, but none of the variables changed the boxes in question.

Grepped for plausible colour descriptors in HMTL #RRGGBB and (R., G., B.) and similar formats. I found a few references, but I changing these values didn’t fix anything. Perhaps this is unsurprising – it’s more likely to be something not hardcoded that is causing this problem.

4. Modifed set_sensitive() method

The docstrings for this method made reference to widgets being grayed [sic] out. I played with this but was unable to change effects.

5. Considering where colour values are used

At Oliver’s suggestion looked at gtk.STATE_?? and tried changing the ?? from INSENSITIVE or ACTIVE to NORMAL. This did not appear to have the desired effect. I also looked at changing the values for the second part of the tuple which appeared to contain GTK color objects of some sort. I found that some were set to gtk.Style().bg[0], and thinking that these might be getting system colours I tried changing the index. This did not appear to have any effect. Further, I attempted to use python -c "import gtk; print(gtk.Style().bg[0])" after changing system colours to see if that was where this value came from. This appears to be borne out by the documentation

6. Attempting to trace the working of the software

When rose edit is called the following occurs

1. Argparse looks for any additional arguments
2. A number of safeguards are run
3. A spawn_window function is called
4. A MainController instance is created
5. A number of gtk widgets are created by this, including the ‘page’ which is created by code in page.py.

I investigated the tab-bar example, and found that it contained a number of widgets: label_box, a gtk.Hbox event_box a gtk.EventBox

I tried looking for ways to hard code the colour of these objects but wasn’t able to, although I did change the border size, so I was able to confirm that I was likely to be fiddling with the correct widgets. One StackExchange answer (gtk version unclear) suggested that label_box does not have a colour.

7. A thought about the new GUI:

Can we agree a standard spelling for words that vary by dialect. I prefer 'colour' to 'color', but I prefer 'color' to inconsistent usage. Could we consider adding one or the other to the equivelent of pylintrc's bad-names variable for future projects?

[wxtim]

@hjoliver added a load of fixes in https://github.com/cylc/cylc/pull/2842/files to make the Cylc gui play better with underlying themes. I think making similar changes to Rose may help.

[hjoliver]

For the record, my cylc GUI fixes in cylc/cylc#2842 are just:

• remove some in-app color setting in the log viewer windows, which were overriding the GTK theme.
• force the graph view to use the theme background color, because graphviz sets a white canvas by default.

So these probably won't be of much use to the Rose GUIs.