Custom panel backgrounds no longer drawn in gtk3.19

[lukefromdc]

In gtk3.19 later than about a month ago, user set custom backgrounds are once again broken. If a color or an image background is selected the panel becomes transparent. The .mate-custom-panel-background style class is properly applied but only removes the theme and default backgrounds. If a ~/.config/gtk3-3.0/gtk.css file is created defining a background image or color for .mate-panel-custom-background it is applied on selecting any custom background, and applied properly to panel and panel widgets.

My guess is these functions in panel-background.c are now broken in gtk3.19, I don't know how to fix them:

in function: panel_background_prepare (PanelBackground *background):

gdk_window_set_background_rgba(background->window,
                                            &background->color)  

appears to be broken

in function: set_pixbuf_background (background);

gdk_window_set_background_pattern (background->window, background->composited_pattern) appears to be broken

[raveit65]

I see that too in fedora rawhide :-/

[muktupavels]

That is not problem with gdk_window_setbackground* functions. Simply widget types (PanelWidget, PanelApplet...) are no longer used for style. Probably easiest solution is to do this in *_class_init functions: gtk_widget_class_set_css_name (widget_class, "PanelWidget"); gtk_widget_class_set_css_name (widget_class, "PanelApplet"); ...

[lukefromdc]

I don't see where in the custom panel background setting gtk theme elements are called at all except for the style class .mate-custom-panel-background which is used to turn the panel transparent before applying a custom background.

It looks like direct drawing in GDK, something I know little about.

On 2/6/2016 at 7:39 AM, "Alberts Muktupāvels" notifications@github.com wrote:

That is not problem with gdk_window_setbackground* functions. Simply widget types (PanelWidget, PanelApplet...) are no longer used for style. Probably easiest solution is to do this in *_class_init functions: gtk_widget_class_set_css_name (widget_class, "PanelWidget"); gtk_widget_class_set_css_name (widget_class, "PanelApplet"); ...

---

Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-panel/issues/403#issuecomment- 180753235

[raveit65]

see https://github.com/mate-desktop/mate-panel/tree/dev-background I've added those nodes name, but the issue still exists. I noticed that when using marco with compositor the panel is complete transparent with custom color, and without compositor the panel is simply black. Which points me to a build warning which i never saw with stable gtk+.

mate-panel-applet.c: At top level:
mate-panel-applet.c:1989:6: warning: no previous prototype for '_mate_panel_applet_prepare_css' [-Wmissing-prototypes]
 void _mate_panel_applet_prepare_css (GtkStyleContext *context)
      ^
mate-panel-applet.c: In function 'mate_panel_applet_init':

And in this function i see the the black color definition. https://github.com/mate-desktop/mate-panel/blob/master/libmate-panel-applet/mate-panel-applet.c#L1989

[muktupavels]

Have no idea what you have done here regarding panel style, but gnome-panel works nice with Adwaita. Any other theme will require updating for GTK+ 3.20...

You are saying that you use custom color... Did you set it from panel properties? If yes then: 1) You have color background - type == PANEL_COLOR_BACKGROUND. You add mate-custom-panel-background class in _mate_panel_applet_apply_css. 2) In _mate_panel_applet_prepare_css you change background to fully black transparent color.

So when you have compositor - you see it transparent (because that is what you have requested). Turning compositor off - color remains same. And as we all know then without compositor there can not be any transparency.

[raveit65]

Normal with stable gtk+ i can set a mix of a custom color + an alpha value, ie (85, 85, 87, 0.5) This does not work with gtk+-3.20. I see (0, 0, 0, 0.0) with compositor or without i see (0, 0, 0, 1.0) And this is independent from gtk theme, btw. BlueMenta from mate-themes is full updated for gtk+-3.20 ;) Edit: yes i set the custom-color with mate-panel preferences.

[muktupavels]

How/where are you setting your custom color?

[raveit65]

In mate-panel preferences editor. Here we have 3 settings.

1. use theme bg color 2 .use a custom color + a slider to mix it with an alpha value
2. use a image as background.
3. • 3. does not work, and i see what i described in prevoius comment.

Btw. here are the new panel setting with BlueMenta for 3.20 https://github.com/mate-desktop/mate-themes/blob/master/desktop-themes/BlueMenta/gtk-3.0/mate-applications.css#L372

[muktupavels]

Are you adding mate-panel-menu-bar class to every widget? You have done something wrong with panel styling in code and/or themes. As gdk_window_set_background_pattern and gdk_window_set_background_rgba does work fine.

I would suggest to use gtk+ inspector to debug css...

[lukefromdc]

mate-panel-menu-bar is not used in setting a custom panel background from the panel properties dialog. In fact, the .mate-custom-panel-background class is used to override the GTK theme so that whatever is drawn by the panel custom background code that is part of mate-panel itself can be shown.

One fix for this would of course be to convert whatever is drawn by the panal-background-c to variables which could be loaded using gtk_css_provider_load_from_data, being careful to use only the style classes and nothing else so it would be valid in all versions of gtk3.

Example: if a color is selected, load the RGB value into a variable, then find some way to get the value contained in that variable into the css provider. For an image, same with the image path. The value of the variable would have to be included in an otherwise prewritten string, I don't know if there's an easy way to so that gtk_css_provider_load_from_data can recognize.

On 2/6/2016 at 11:22 PM, "Alberts Muktupāvels" notifications@github.com wrote:

Are you adding mate-panel-menu-bar class to every widget? You have done something wrong with panel styling in code and/or themes. As gdk_window_set_background_pattern and gdk_window_set_background_rgba does work fine.

I would suggest to use gtk+ inspector to debug css...

---

Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-panel/issues/403#issuecomment- 180944668

[raveit65]

Oh, common...i'm using gtk3-inspector since 3.14.......and what you see here is what gtk3-inspector says :smile: We speaking about mate-panel and not gnome-panel, those are different.

[lukefromdc]

I just built and installed the dev-background branch and can confirm that simply setting the style class does not change custom backgrounds one bit-still transparent (I'm using compiz so this is with compositing) and nothing drawn for a background once the gtk theme background is removed.

The GTK theme itself can once again set image, color, and color with alpha backgrounds but nothing works from the panel properties dialog's background tab except the system theme's background or in the case of themes like Adwaita that set none, the panel default background which is the theme background color. This is removed with the .mate-custom-panel-background class when a custom background is selected.

On 2/6/2016 at 11:22 PM, "Alberts Muktupāvels" notifications@github.com wrote:

Are you adding mate-panel-menu-bar class to every widget? You have done something wrong with panel styling in code and/or themes. As gdk_window_set_background_pattern and gdk_window_set_background_rgba does work fine.

I would suggest to use gtk+ inspector to debug css...

---

Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-panel/issues/403#issuecomment- 180944668

[muktupavels]

I understand that problem is with mate-panel... That does not change what I did say - functions gdk_window_setbackground* works!

[lukefromdc]

One more thing I just found: adding those widget names makes the panel easier to theme-but does break any theme elements currently usint the default "widget" name. I'll worry about this later for now...

On 2/6/2016 at 11:29 PM, "Wolfgang Ulbrich" notifications@github.com wrote:

Oh, common...i'm using gtk3-inspector since 3.14.......and what you see here is what gtk3-inspector says :smile: We speaking about mate-panel and not gnome-panel, those are
different.

---

Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-panel/issues/403#issuecomment- 180944847

[lukefromdc]

Well, if the function itself works, either its not gettting the right input anymore or it's output is no longer getting drawn to the panel.

On 2/6/2016 at 11:38 PM, "Alberts Muktupāvels" notifications@github.com wrote:

I understand that problem is with mate-panel... That does not change what I did say - functions gdk_window_setbackground* works!

---

Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-panel/issues/403#issuecomment- 180945402

[lukefromdc]

Until now, I've been able to run any MATE app built on any version of GTK3 that I've had around (3.14 and later) on any other version at least after 3.14. This is no longer true for the "dev-background" branch of mate-panel.

The "dev-background" branch introduces the requirement that the panel must be built on gtk3.19/20 if it is to be run on gtk3.20, and must NOT be built on gtk3.19/20 if it is to run on gtk3.18 or earlier. If the panel is built on gtk3.19 from this branch and GTK then reverted to 3.18 and the panel restarted, it errors out with this error(as I expected): symbol lookup error: mate-panel: undefined symbol: gtk_widget_class_set_css_name

Of course, distros don't need to build on one gtk version and run on another, though I will have to publish my debian files both ways just like I did for mate-system-monitor with the gcc5 transition. It may well be that gtk3.20 changes so much that we need to accept that packages built for it won't run on older versions.

[raveit65]

I used GTK_CHECK_VERSION (3, 19, 0) check for those commits. Of course you need to rebuild the panel if you downgrade gtk+ to < 3.19.0. But we can add style classes instead of css names, since it is clear that adding css names does not fix the issue.

[raveit65]

@lukefromdc Could you solve the 'undefined symbol' issue with rebuilding the panel for 3.18? And is using css names Ok for you? I wanna merge the branch.

[lukefromdc]

CSS names are fine, and yes you can build and run this branch with gtk3.18, only building with gtk3.19 and then trying to run it with an older GTK version generates the symbol error. Just tested this, it worked fine thanks to limiting this in the code to gtk3.19 or later builds.

On 2/9/2016 at 3:38 AM, "Wolfgang Ulbrich" notifications@github.com wrote:

@lukefromdc Could you solve the 'undefined symbol' issue with rebuilding the panel for 3.18? And is using css names Ok for you? I wanna merge the branch.

---

Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-panel/issues/403#issuecomment- 181760066

[raveit65]

Ok, fine.....dev-backgrounds is merged

[lukefromdc]

I did some experiments last night, slowed down by the fact that I really don't know much about using cairo. I did find, however, that setting an image background, then forcing cairo to use "NULL" as the image source in the function composite_image_onto_desktop will cause the panel to render black, which is cairo's default according to the documentation. The same occurs if in the functionpanel_background_transform is forcibly set to pass through background->loaded_image while if is allowed to call get_scaled_and_rotated_pixbuf a transparent panel results.

With color backgrounds also not working, whatever doesn't work must be failing in both composite_image_onto_desktop and in composite_color_onto_desktop

yet at least the first one can be forced to turn the panel black, meaning the problem should not be in anything calling these functions or anything still earlier in the sequence.

More experiments on the way, I will attempt to force cairo to do SOMETHING other than black but I have a lot of learning to do about using it first.

[lukefromdc]

No luck with Cairo, I don't know enough about it to identify what broke. I DID however manage to identify the day GTk3.19 got the commit that broke it as being either late Jan 17 or early Jan 18. The commits in question between the "good" and "bad" version were between this pair based on the changlogs in the Debian packages I saved:

2016-01-18 text view: Expose cursor blink control Matthias Clasen 3 -0/+26 2016-01-17 Trivial formatting fix

[raveit65]

Ok, issue was introduced with 3.19.7. With 3.19.6 all works fine. I will use 'git biscet' to find out which commit breaks custom-colors.

[raveit65]

Culprit commit is https://git.gnome.org/browse/gtk+/commit/?id=580ea227a6bb19ad6c6d4766b3a36dbad24583f3 @monsta can you take a look in it please? Maybe this fixable from our side.

[lukefromdc]

I remember that one as possibly having a hand in other issues. I do not know any obvious way to work around this except to get GDK out of the picture entirely and use cairo by itself for this.

Two ways come to mind: first of all, I will experiment with inserting a known good cairo demo (same one I learned to force transparency from) into the code to pop up it's own window when a custom BG is selected. By then trying to feed the pattern to it I hope to find out whether the drawing itself is no longer valid or the pattern is bad. If the former as I suspect, than simply drawing that cairo window UNDER the panel would put the background underneath it, same as if it had been included in the background image. This would only work with compositing, so the panel would have to get onto it too for the noncompositing case.

Other approach is to "clean sheet this" and find a way to import the values stored in gsettings (which works) into a css provider which would become the new .mate-custom-panel-background gtk style. This would work so long as GTK itself works and allow getting rid of a lot of code.

Only thing is, I' ve only been able to import hardcoded strings with no variables or else files into gtk css providers so far.

On 2/18/2016 at 7:42 PM, "Wolfgang Ulbrich" notifications@github.com wrote:

Culprit commit is https://git.gnome.org/browse/gtk+/commit/?id=580ea227a6bb19ad6c6d47 66b3a36dbad24583f3 @monsta can you take a look in it please? Maybe this fixable from our side.

---

Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-panel/issues/403#issuecomment- 185995458

[lukefromdc]

I just found that the still supported gnome-panel 3.18.2 still supports custom backgrounds-and they still work with gtk3.19.10. Takes super-alt-right click to access all the panel config functions in gnome-panel but they do work. Spent some time trying to find the code difference that makes it work with little success. The cairo functions for drawing the background in panel-background.c didn't seem to make a difference, nor did replacing the entire xstuff.c file with the GNOME version, which built and ran find but made no difference.

[lukefromdc]

FINALLY getting some results: A replacing some code in panel-widget.c drew the panel background on the panel but not (yet) the applets. Clock, tray, cpufreq-applet, trash etc transparent but hope to find this soon.

[lukefromdc]

Created this PR after getting backgrounds to mostly work: https://github.com/mate-desktop/mate-panel/pull/411

All themes will work on a fresh start for both system and user backgrounds. Changing theme with a user background or returning to the system background requires a panel restart. Changing themes with the system bg selected works fine. Back where we were a few months ago with gtk3.18 on this...

[raveit65]

https://github.com/mate-desktop/mate-panel/commit/b21ae316e9c500db40129870abb1bd9e0013e950 https://github.com/mate-desktop/mate-panel/commit/0fef6a917e9f60c52d0e4fb5b0d5ef9f8371a5f7 https://github.com/mate-desktop/mate-panel/commit/979e5aacd36f44b095426cd07e50eb77e85b50f2

[raveit65]

I noticed 2 things:

1. Changing back from custom color or custom background to theme background works only for the panel itself, not for the applets. Indeed a panel restart is needed.
2. If custom color is selected changing transparency applies only for the panel itself but not for applets (ie.wnck applets). Here a simple switch to theme bg and back to custom color applies ths right transparency value to the applets.

Maybe the latest 2 commits from g-p are needed to fix this, i will try them.

[lukefromdc]

I just managed with hours of work to manually patch most of those two commits to gnome-panel that move the background handling to the panel toplevel. It fixed the failure to update custom backgrounds on applets at changing themes, but did NOT fix the failure to return to system background to applets when the user returns to the system background. Also, using the GNOME commits brought back the background changing problems in gtk3.18. On top of all else, the resulting files needed further modification to allow a GTK2 build to complete. I was unable to test run that due to runtime libraries not being GTK2 versions, I had only done a test build of mate-desktop beneath it, and at that point could not restart any mate application depending on it.

The applet issue appears to be this: one a custom background has been run, the applet windows have been forcibly set to gtk native windows, as otherwise the custom backgrounds are not drawn. Once that is so, calling dk_window_set_background_pattern(window,NULL); on them turns them transparent and the GTK theme is not drawn. I have not found a way to reverse gdk_window_ensure_native (window); any way of reversing that when returning to the system theme would solve this problem. I have yet to find out how GNOME handled this, as their panel-applet.c file is quite different from mate-panel-applet.c They don't explicltly set the windows as gdk native, not sure what they are doing.

[lukefromdc]

Here is my manually-edited merge of gnome-panel's move of the bg handling to toplevel. Fixes redraw of custom backgrounds when changing themes with gtk3.19, brings back the problems with reverting the panel theme to the system theme in gtk3.18, and will build in gtk2 but no idea how well it will work:

https://github.com/lukefromdc/mate-panel/tree/move-background-handling

Too many changes to put everything behind gtk3.19 build switches

[lukefromdc]

Just did some digging and found out why gnome-panel doesn't have the applet problem: they render the panel background all the way across beneath the applets, while mate-panel is always transparent beneath any instance of PanelPlug. They use "PanelAppletContainer" instead of "PanelPlug" but there are many references to "plug" and "socket" in that file.

Why is our panel transparent underneath the applets? If the panel BG always ran all the way across, we could probably remove background handling from mate-panel-applet.c entirely. I could not find any background handling code in GNOME's panel-applet.c, I don't think they need it. This would be lighter and remove the applet background problems for good no matter what happens with GTK in the future. For the non-compositing case applets could use cairo to always copy the panel BG.

An alternate fix would be to find a way to get a pixmap background from some part of the panel NOT under the applets, then use it to set the background for them as well when the system background is selected.

[muktupavels]

Just did some digging and found out why gnome-panel doesn't have the applet problem:

There is problem, but only with out-of-process applets.

they render the panel background all the way across beneath the applets, while mate-panel is always transparent beneath any instance of PanelPlug. They use "PanelAppletContainer" instead of "PanelPlug" but there are many references to "plug" and "socket" in that file.

I have changed gnome-panel to not use GtkPlug/GtkSocket for in-process applets.

Why is our panel transparent underneath the applets? If the panel BG always ran all the way across, we could probably remove background handling from mate-panel-applet.c entirely. I could not find any background handling code in GNOME's panel-applet.c, I don't think they need it. This would be lighter and remove the applet background problems for good no matter what happens with GTK in the future. For the non-compositing case applets could use cairo to always copy the panel BG.

Won't work... Transparent socket/plug on panel will create a "hole" - you wont see panel background under transparent plug: https://bugzilla.gnome.org/show_bug.cgi?id=762992

An alternate fix would be to find a way to get a pixmap background from some part of the panel NOT under the applets, then use it to set the background for them as well when the system background is selected.

Does not sound correct. Applet has info about full panel pixmap not only about part under applet.

[monsta]

Hi Alberts,

is there any alternative to GtkPlug/GtkSocket for out-of-process applets?

[muktupavels]

is there any alternative to GtkPlug/GtkSocket for out-of-process applets?

I think that no - at least I don't know. Most likely I will stop using out-of-process applets in gnome-panel...

[lukefromdc]

Worst case scenaro if we can't fix this would be a GTK 3.20 only addition to the panel preferences dialog where changes back to the system theme would get a "restart panel to apply" button. For our current code ALL of the panel theme goes away on switching back to the system theme, for my modded version with gnome-panel's change to move background handling to the toplevel, the main panel bg will return to system theme without requiring a restart.

Also, the gnome-panel changes keep custom panel themes from requiring a restart with a change of GTK theme, not sure why that is. They do bring a regression with gtk 3.18- again with panel applets that turn transparent on changing panel backgrounds. I was able to build what I put together with GTK 2 as well but could not test it as I did not have GTK 2 versions of all the runtime dependencies as changing all of them out while using MATE with gtk3 would have easily left me with a lot of repair work. Only mate-desktop had been switched out and that was not enough to actually run it, only build it.

On 3/5/2016 at 8:19 AM, "Alberts Muktupāvels" notifications@github.com wrote:

Just did some digging and found out why gnome-panel doesn't have the applet problem:

There is problem, but only with out-of-process applets.

they render the panel background all the way across beneath the applets, while mate-panel is always transparent beneath any instance of PanelPlug. They use "PanelAppletContainer" instead of "PanelPlug" but there are many references to "plug" and "socket" in that file.

I have changed gnome-panel to not use GtkPlug/GtkSocket for in- process applets.

Why is our panel transparent underneath the applets? If the panel BG always ran all the way across, we could probably remove background handling from mate-panel-applet.c entirely. I could not find any background handling code in GNOME's panel-applet.c, I don't think they need it. This would be lighter and remove the applet background problems for good no matter what happens with GTK in the future. For the non-compositing case applets could use cairo to always copy the panel BG.

Won't work... Transparent socket/plug on panel will create a "hole" - you wont see panel background under transparent plug: https://bugzilla.gnome.org/show_bug.cgi?id=762992

An alternate fix would be to find a way to get a pixmap background from some part of the panel NOT under the applets, then use it to set the background for them as well when the system background is selected.

Does not sound correct. Applet has info about full panel pixmap not only about part under applet.

---

Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-panel/issues/403#issuecomment- 192640947

[lukefromdc]

Here's a thought: what about moving all of the current panel applets in process and ditching the plugs? Presumably all would thus become part of mate-panel's code but we just did that with netspeed. Alternately, I was able to partially fix this last night hacking on nothing more than themes. The code below does not fix the tray but the background mostly showed on everything else. It is correct for a black panel background, I still need to reset window list button bg's for it though:

mate-panel-menu-bar,
PanelToplevel.mate-panel-menu-bar, 
PanelWidget.mate-panel-menu-bar,
.mate-panel-menu-bar #PanelApplet>button,
.mate-panel-menu-bar #PanelApplet box,
.mate-panel-menu-bar #PanelApplet image,
.mate-panel-menu-bar #PanelApplet label{
    background-color:#000000;
    color: white;
}

.mate-custom-panel-background #PanelApplet>button,
.mate-custom-panel-background #PanelApplet box,
.mate-custom-panel-background #PanelApplet image,
.mate-custom-panel-background #PanelApplet label{
    background-color:transparent;
}

The tray background cannot be themed except by theming the plug, for some reason the box cannot have a background set on it. The widget sequence to those xembed icons is na-tray-applet>box>widget and not one of those accepted a background, the box should have but did not. The tray even ignores setting ALL backgrounds in ALL widgets to a color, so long as the panel background has been changed from a user to the theme background-still transparent.

All the others I've tried have boxes, buttons, labels, or images that will accept a themed background that can be applied even after changing panel backgrounds. The CPU frequency applet will need some rework if we go this route, as will the hardware indicator applet. I had to hardcode allocations for these just to get the labels to show last year, they don't quite fill their space and with this issue that shows up.

Gnome panel has a tray that works, we could copy that, fix the other two applets I mentioned, apply the hardcoded background, mate-panel-menu-bar and mate-custom-panel-background classes where necessary for non-MATE themes, fix our themes, and call it a day.

[muktupavels]

Here's a thought: what about moving all of the current panel applets in process and ditching the plugs? Presumably all

Do you realize that mate-panel currently use GtkPlug/GtkSocket also for in-process applets?

would thus become part of mate-panel's code but we just did that with netspeed. Alternately, I was able to partially fix

netspeed is out-of-process applet... That is what I see looking in mate-applets.

this last night hacking on nothing more than themes. The code below does not fix the tray but the background mostly showed on everything else. It is correct for a black panel background, I still need to reset window list button bg's for it though:

.``` mate-panel-menu-bar, PanelToplevel.mate-panel-menu-bar, PanelWidget.mate-panel-menu-bar, .mate-panel-menu-bar #PanelApplet>button, .mate-panel-menu-bar #PanelApplet box, .mate-panel-menu-bar #PanelApplet image, .mate-panel-menu-bar #PanelApplet label{ background-color:#000000; color: white; }

.mate-custom-panel-background #PanelApplet>button, .mate-custom-panel-background #PanelApplet box, .mate-custom-panel-background #PanelApplet image, .mate-custom-panel-background #PanelApplet label{ background-color:transparent; }

I still don't get why did you put mate-panel-menu-bar class everywhere. Was not better to introduce mate-panel-reset class and use it to remove/reset style - if that is what you are trying to do...

The tray background cannot be themed except by theming the plug, for some reason the box cannot have a background set on it. The widget sequence to those xembed icons is na-tray-applet>box>widget and not one of those accepted a background, the box should have but did not. The tray even ignores setting ALL backgrounds in ALL widgets to a color, so long as the panel background has been changed from a user to the theme background-still transparent.

All the others I've tried have boxes, buttons, labels, or images that will accept a themed background that can be applied even after changing panel backgrounds. The CPU frequency applet will need some rework if we go this route, as will the hardware indicator applet. I had to hardcode allocations for these just to get the labels to show last year, they don't quite fill their space and with this issue that shows up.

Gnome panel has a tray that works, we could copy that, fix the other two applets I mentioned, apply the hardcoded background, mate-panel-menu-bar and mate-custom-panel-background classes where necessary for non-MATE themes, fix our themes, and call it a day.

Most likely it works because in-process applets in gnome-panel does not use GtkPlug/GtkSocket and all applets in gnome-panel are build as in-process - there is no way to build them as out-of-process applet now. Looking at configure.ac in mate-panel applets by default are build as out-of-process applet.

P.S. Last time I tried it was enough to change panel-applet.c code to set background pattern on GdkWindow from GtkPlug. I have not done that for gnome-panel because I was hoping to find better solution...

[lukefromdc]

This is a rough fix, it was a matter of using these two existing classes without changing the panel code we use. They were used to limit the theme setting to when the theme default background is used, as otherwise the background would also be applied over the custom backgrounds. This is because I am theming widgets contained inside the GtkPlugs and not the plugs(windows) themselves, which no longer respond to the GTK theme oncegdk_window_ensure_native (window); has ever been called on them. This is an ugly hack but it worked for everything except the tray and some fine lines around those applets with hardcoded allocations. Doesn't do anything for the tray though.

[lukefromdc]

I'll have to try setting the background pattern on GdkWindow from GtkPlug myself. Did you post any commits or branches I could look at for clues?

[muktupavels]

I'll have to try setting the background pattern on GdkWindow from GtkPlug myself. Did you post any commits or branches I could look at for clues?

No.

[lukefromdc]

I did not find any obvious way to move the background from the plug to it's window but I don't know much about working with GDK. The plug's window is presumably what normally takes the background but can no longer be painted by GTK it seems after it has been forced to gdk native to take the custom background.

[lukefromdc]

I managed to get my branch using the gnome-panel commits moving background handling to the panel toplevel to work very nicely with GTK 3.18. Edit: the GNOME commits moving the panel background handling to the toplevel BREAK custom backgrounds with gtk3.16, thus probably with GTK2 as well. This seems to be strictly for GTK3.18 or later builds.

https://github.com/lukefromdc/mate-panel/tree/move-background-handling

Now working on cleaning up applets other than the tray for the theming workaround method, again revisiting old fixes. Those should be good with any gtk3 version, I just found a fix for an old mess that forced hardcoded applet label and icon widths

[muktupavels]

On Sun, Mar 6, 2016 at 11:45 PM, lukefromdc notifications@github.com wrote:

I did not find any obvious way to move the background from the plug to it's window but I don't know much about working with GDK. The plug's window is presumably what normally takes the background but can no longer be painted by GTK it seems after it has been forced to gdk native to take the custom background.

Why do you use gdk_window_ensure_native?

I have fixed background for out-of-process applets: https://git.gnome.org/browse/gnome-panel/commit/?id=3115f77b536a7c79c7d43ded0591e2b8f45219c4

[lukefromdc]

It was used because it was what made the background render in the panel itself and worked there. In gnome-panel 3.18 it is used in panel-widget and the very similar panel-widget code for mate-panel 1.12 did not use it. Thus in gtk3.19 mate-panel did not render custom backgrounds at all and gnome-panel did. That one line was the difference.

On 3/9/2016 at 11:20 AM, "Alberts Muktupāvels" notifications@github.com wrote:

On Sun, Mar 6, 2016 at 11:45 PM, lukefromdc notifications@github.com wrote:

I did not find any obvious way to move the background from the plug to it's window but I don't know much about working with GDK. The plug's window is presumably what normally takes the background but can no longer be painted by GTK it seems after it has been forced to gdk native to take the custom background.

Why do you use gdk_window_ensure_native?

I have fixed background for out-of-process applets: https://git.gnome.org/browse/gnome- panel/commit/?id=3115f77b536a7c79c7d43ded0591e2b8f45219c4

---

Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-panel/issues/403#issuecomment- 194372093

[lukefromdc]

OK, I'll be able to experiment with the new code from gnome-panel in mate-panel when I get back this evening from an event today.

On 3/9/2016 at 11:20 AM, "Alberts Muktupāvels" notifications@github.com wrote:

On Sun, Mar 6, 2016 at 11:45 PM, lukefromdc notifications@github.com wrote:

I did not find any obvious way to move the background from the plug to it's window but I don't know much about working with GDK. The plug's window is presumably what normally takes the background but can no longer be painted by GTK it seems after it has been forced to gdk native to take the custom background.

Why do you use gdk_window_ensure_native?

I have fixed background for out-of-process applets: https://git.gnome.org/browse/gnome- panel/commit/?id=3115f77b536a7c79c7d43ded0591e2b8f45219c4

---

Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-panel/issues/403#issuecomment- 194372093

[lukefromdc]

I just succeeded in porting the code from gnome-panel to mate-panel and it works. In my branch https://github.com/lukefromdc/mate-panel/tree/move-background-handling which only works on gtk 3.19 and 3.18(not tested yet with this change) it works without any issues.

I then made a new branch https://github.com/lukefromdc/mate-panel/tree/GTK3.20-AppletCustomBgFix

applying the same changes to the code from current master as of 3-9-2016 and it worked again, but made the panel widget turn transparent again on return to the system theme, due to persistance on the panel widget of the mate-custom-panel-background style class until panel restart. I rremoved the apply_css function from panel-widget.c and that issue was fixed, yet the custom background still works as the system one does not get draw even though it shows up in GTK Inspector. I need to try this in GTK 3.18 1nd 3.16, and someone needs to see if the new files or any error on my part broke GTK2 builds.

One problem with the second branch: when and only when a custom panel bg is in use, some applets will crash about half the time on restarting the panel. That needs to be diagnosed but now we have a starting point. No new applet crashes with the system background. On the branch moving the bg handling to the toplvel (first branch) no applet crashes with any background, that's the one I use now.

[monsta]

Ok, I guess https://github.com/mate-desktop/mate-panel/pull/415 should fix it? I see this note there though:

I recommend building the clock, tray, wncklet, and fish in-process as this stops most of the applet crashes on panel startup with a custom background(especially image backgrounds) selected.

[raveit65]

There is one little issue left, but i think it's independent from latest PR. If custom background + and an alpha value is set and you switch the gtk-theme, than not all panel elements are transparent, mostly with bottom panel. I think PanelTopLevel and MatePanelAppletFrameDBus elements are affected.