How can I color a wxButton or wxToggleButton?

[Carl Godkin]

Hi,

We have some places in our code where we color wxToggleButton objects with wxWindow::SetBackgroundColour(). 

This has worked fine for years on Windows and on RHEL versions up through RHEL6, but the same executable does not show any color on RHEL7.

We build and run wxWidgets 3.1.0 with GTK 2.24, but wxWidgets 3.0.2 showed the same behavior.  Checking "Ctrl + Alt + Middle" confirms that it really is GTK 2.24 in both cases.

I realize that wxWindow::SetBackgroundColour() says in its docs that it might not actually work on all platforms and versions, so I tried an alternative approach:  Since wxToggleButton is dervied from wxAnyButton, I used SetBitmap with a solid colored bitmap.  Again, this worked fine on RHEL6 but not on RHEL7.  (I also tried wxBitmapToggleButton with the bitmap but it's the same story.)

This is easy to duplicate by adding the line

  m_toggle->SetBackgroundColour (*wxRED);

after the wxToggleButton construction at line 448 of toggle.cpp in the widgets sample.   (For that matter, I just noticed that SetBackgroundColour() has the same problem a regular old wxButton as well.)

Looking at the "ldd" output of the "widgets" sample, we are apparently getting the same versions of libgtk and all of its dependencies.  Trying a variety of X servers (local, remote,...) always shows this same behavior difference between RHEL6 and RHEL7.

Is there something I'm missing?  Is there any way to reliably color a wxToggleButton?

Thanks very much,

carl

[Vadim Zeitlin]

On Wed, 21 Dec 2016 07:39:38 -0800 Carl Godkin wrote:

CG> This is easy to duplicate by adding the line
CG>
CG> m_toggle->SetBackgroundColour (*wxRED);
CG>
CG> after the wxToggleButton construction at line 448 of toggle.cpp in the
CG> widgets sample.

It also has "Set background" in its "Widget" menu which can be used to
test this without any modifications to the code.

CG> Looking at the "ldd" output of the "widgets" sample, we are apparently
CG> getting the same versions of libgtk and all of its dependencies. Trying a
CG> variety of X servers (local, remote,...) always shows this same behavior
CG> difference between RHEL6 and RHEL7.
CG>
CG> Is there something I'm missing? Is there any way to reliably color a
CG> wxToggleButton?

This is supposed to work under wxGTK and does work for me with the latest
master and GTK+ 2.24.25 under Debian. I guess it could be theme-dependent,
do you know which theme do you use? If it's really due to a theme override,
there is probably nothing you can do about it though.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Carl Godkin]

On Wed, Dec 21, 2016 at 7:57 AM, Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Wed, 21 Dec 2016 07:39:38 -0800 Carl Godkin wrote:

CG> This is easy to duplicate by adding the line
CG>
CG>   m_toggle->SetBackgroundColour (*wxRED);
CG>
CG> after the wxToggleButton construction at line 448 of toggle.cpp in the
CG> widgets sample.

 It also has "Set background" in its "Widget" menu which can be used to
test this without any modifications to the code.

Oh, sorry.  I never noticed that before.  Thanks.

 

CG> Looking at the "ldd" output of the "widgets" sample, we are apparently
CG> getting the same versions of libgtk and all of its dependencies.  Trying a
CG> variety of X servers (local, remote,...) always shows this same behavior
CG> difference between RHEL6 and RHEL7.
CG>
CG> Is there something I'm missing?  Is there any way to reliably color a
CG> wxToggleButton?

 This is supposed to work under wxGTK and does work for me with the latest
master and GTK+ 2.24.25 under Debian. I guess it could be theme-dependent,
do you know which theme do you use? If it's really due to a theme override,
there is probably nothing you can do about it though.

Themes!!!  Of course.  You're correct.   On our RHEL7 systems, the defaul theme is "Adwaita."  When I changed the GTK+ theme to either of the other choices, then the button coloring started to work again.

Thanks very much.  RHEL7 seems pretty strange so far to us and stuff like this doesn't help.

carl

[kmcc...@gmail.com]

On Wednesday, December 21, 2016 at 8:47:44 AM UTC-8, CGodkin wrote:

 

Themes!!!  Of course.  You're correct.   On our RHEL7 systems, the defaul theme is "Adwaita."  When I changed the GTK+ theme to either of the other choices, then the button coloring started to work again.

Thanks very much.  RHEL7 seems pretty strange so far to us and stuff like this doesn't help.

I'll follow up, in case this helps out anyone else, to mention that we have found a local work-around for this issue that works at least with wxGTK built against GTK+ version 2 libraries.  That workaround is to add some calls in our code to the gtk_rc_parse_string() function, which can be used to supplement or even override the various gtkrc files that GTK libraries read by default.

(As this function evidently modifies global state of GTK+ libraries, it presumably must be called only while the application is still known to be in a single-threaded region.)

Point the first, this can be used to force buttons not to be rendered using the "pixmap" engine provided by the Adwaita theme (or other themes that might explicitly set button images) as follows, thereby letting our calls to SetBackgroundColour() be effective.

(As I comment below, I had hoped to be able to target this more precisely using the "widget_class" or "widget" selectors combined with some appropriate calls like gtk_widget_set_name(wxwindow->GetHandle(), "specific_name"), as described at [1], but I couldn't get anything of that nature to work in practice at all.)

[1] http://stackoverflow.com/a/14894222

#ifdef __WXGTK__
  // Docs: https://developer.gnome.org/gtk2/stable/gtk2-Resource-Files.html
  gtk_rc_parse_string(
      "style \"our_button\" {\n"
          // This disables any engines that may be setting button
          // background images:
      "   engine \"\" {}\n"
          // This should disable any other theme settings for button
          // background images:
      "   bg_pixmap[NORMAL] = \"<none>\"\n"
      "   bg_pixmap[ACTIVE] = \"<none>\"\n"
      "   bg_pixmap[PRELIGHT] = \"<none>\"\n"
      "   bg_pixmap[SELECTED] = \"<none>\"\n"
      "   bg_pixmap[INSENSITIVE] = \"<none>\"\n"
      "}\n"

      // Make the above style apply to all GtkButtons and derived classes.
      // In theory there should be a way to target this in a more focused
      // way only at widgets with a specific name, e.g. "Color", and set
      // that name on the desired widgets (or perhaps their parent) with
      // gtk_widget_set_name().  In practice I have not been able to make
      // that work at all.  -- KBM 2016-12-21
      "class \"GtkButton\" style : highest \"our_button\"\n"
      );
#endif

One could, of course, go the extra mile to factor out this string into yet another gtkrc file at for instance /opt/MyApplication/etc/gtkrc, and run gtk_rc_parse_string() on the contents of that file instead of hard-coding the string into the C++, if for some reason one wished to let this be amenable to edits by the local sysadmin.

Point the second, this mechanism can also be used to override the extremely frustrating GTK+ changes of a few years ago that cause menu icons and button icons (on labeled buttons) to be hidden by default, as follows:

  // Make sure button and menu icons are visible.
  gtk_rc_parse_string(
      "gtk-button-images = 1\n"
      "gtk-menu-images = 1\n"
      );

This was quite a nice discovery for us, since a lot of our GUIs rely on menu icons to convey information to users in addition to the menu item text.

I note that this call to gtk_rc_parse_string() probably has to be done in one's override of wxApp::OnInit() in order to be effective.  If it comes before that (e.g. in the constructor of one's wxApp-derived class) it runs the risk that the GTK libraries parse their own gtkrc files *after* this call, thereby possibly undoing our settings of gtk-menu-images=1 etc.

Presumably something similar can be done with wxGTK-using modules where WX was built against GTK+ version 3, as noted at the above stackoverflow link.

This is all very hacky of course so I certainly wouldn't expect anything like this to be added into WX library code!  But maybe it's useful to others who are writing WX-based applications and need fine control over UI details.

--
Kevin B. McCarty
<kmcc...@gmail.com>

[Steve Barnes]

> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
>
> To unsubscribe, send email to wx-users+u...@googlegroups.com
> or visit http://groups.google.com/group/wx-users

While not one of the users, (currently), affected this looks like an
item that could do with being added to the wxWdgets wiki and possibly to
an appropriately named GitHub Gist. That way others may be more likely
to find it in the future.
--
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.

[kmcc...@gmail.com]

On Thursday, December 22, 2016 at 9:43:39 PM UTC-8, Gadget Steve wrote:

On 22/12/2016 21:47, kmcc...@gmail.com wrote:

> This is all very hacky of course so I certainly wouldn't expect anything
> like this to be added into WX library code!  But maybe it's useful to
> others who are writing WX-based applications and need fine control over
> UI details.

While not one of the users, (currently), affected this looks like an
item that could do with being added to the wxWdgets wiki and possibly to
an appropriately named GitHub Gist.  That way others may be more likely
to find it in the future.

 
I guess (without having checked) that I could create myself a wiki account.  Would this information be best to go on the troubleshooting page [1] or the FAQ page [2]?

On the other hand, perhaps this information would reach more people if it were on the "official" FAQ's wxGTK section at [3]?  What do people think?  If someone else wanted to take the initiative and do the work of putting this info somewhere for me, I'd be perfectly fine with that ;-)

[1] https://wiki.wxwidgets.org/Troubleshooting
[2] https://wiki.wxwidgets.org/WxFAQ
[3] http://www.wxwidgets.org/docs/faq/gtk/

[kmcc...@gmail.com]

Replying to myself with an update, in case it helps anyone else out:

On Thursday, December 22, 2016 at 1:47:33 PM UTC-8, kmcc...@gmail.com wrote:

Point the second, this mechanism can also be used to override the extremely frustrating GTK+ changes of a few years ago that cause menu icons and button icons (on labeled buttons) to be hidden by default, as follows:

  // Make sure button and menu icons are visible.
  gtk_rc_parse_string(
      "gtk-button-images = 1\n"
      "gtk-menu-images = 1\n"
      );

As it turned out, this snippet did not work reliably.   (Maybe it didn't work at all and I was fooling myself?)  Instead we had to implement a modification of this code that didn't depend on the RC file parser.  The modification looks like this:

  // Make sure button and menu icons are visible.

  if (auto settings = gtk_settings_get_default ()) {
    // First make sure the relevant types are realized, per example at
    // https://developer.gnome.org/gtk2/stable/GtkSettings.html#GtkSettings.description
    g_type_class_unref (g_type_class_ref (GTK_TYPE_IMAGE_MENU_ITEM));
    g_type_class_unref (g_type_class_ref (GTK_TYPE_BUTTON));

    // Force the visibility settings
    g_object_set (settings, "gtk-menu-images", true, nullptr);
    g_object_set (settings, "gtk-button-images", true, nullptr);
  }

Once again, we've only tried this with wxGTK built against GTK+ version 2, though at a quick glance, it appears that these functions still exist in the GTK+ 3 API.