Latest GTK 3.20 update breaks gtk-3.0 themes

[troyengel]

mate-themes-3.20.5

I reported this downstream in Arch just a bit ago:

https://bugs.archlinux.org/task/48893

Any of the themes - such as TraditionalOk - that have a gtk-3.0 element are broken with input control highlighting and coloring when used with MATE gtk2 desktop (cannot comment on the mate-gtk3 effort). Loss of all color in text input, combo boxes, URL bar and other things like that in all native GTK3 apps like Firefox and NetworkManager.

Renaming the gtk-3.0 subdir on a theme allows it to fall back to Adwaita and at least function again for usability, there are lot of errors in the .xession-errors file about deprecated items in the CSS files. Downstream recommended creating an issue here as these these have to be converted/upgraded to 3.20 format?

(apologies on the vaguery - I don't "do" theme stuff, just a user of them)

[raveit65]

Maybe you don't know it, firefox gtk3 i pretty broken in fedora too, not a theme issue.
Firefox use any style class which can be used by a theme.
Those guys don't want that frefox can be fixed or adjust by a theme, so you have to live with their problems.
And i don't see any issue with current nm-applet in fedora f24.
Btw. which gtk+3 version use archlinux?
mate-themes-3.20.5 is made for gtk+3.20.2.
Using an older version can cause issues.

[raveit65]

Maybe you don't know it, firefox gtk3 i pretty broken in fedora too, not a theme issue.
Firefox use any style class which can be used by a theme.
Those guys don't want that frefox can be fixed or adjust by a theme, so you have to live with their problems.
And i don't see any issue with current nm-applet in fedora f24.
Btw. which gtk+3 version use archlinux?
mate-themes-3.20.5 is made for gtk+3.20.2.
Using an older version can cause issues.

[troyengel]

I follow what you're saying, but as a long time Fedora user the two really don't equate due to the way the vendors package - Arch is more true to upstream (default/unpatched) and Fedora patches a lot of things. There are bugs in either distro that are specific to that vendor (as well as Ubuntu, SUSE, etc. - all the same problem).

Great question though - Arch just updated to GTK3 3.20.2 over the weekend which is why this all just showed up this morning when I updated one machine. :) https://www.archlinux.org/packages/extra/x86_64/gtk3/ Many other packages were updated (recompiled, etc.) to support this release on Arch, everything from Chromium to Firefox to NetworkManager (basically anything using 'icu') and other random stuff. This makes it hard to just downgrade a single package to test each item (i.e. if I downgrade Firefox then icu comes along, which has 12 other packages to downgrade, etc. - big dependency chain)

Firefox is my biggest vector - the inability to see what text is highlighted is a deal killer. On this laptop I'm on now (not updated yet) the GTK3 is 3.18.9 and all the exact same themes and highlights work just fine (as usual, etc.).

[troyengel]

I follow what you're saying, but as a long time Fedora user the two really don't equate due to the way the vendors package - Arch is more true to upstream (default/unpatched) and Fedora patches a lot of things. There are bugs in either distro that are specific to that vendor (as well as Ubuntu, SUSE, etc. - all the same problem).

Great question though - Arch just updated to GTK3 3.20.2 over the weekend which is why this all just showed up this morning when I updated one machine. :) https://www.archlinux.org/packages/extra/x86_64/gtk3/ Many other packages were updated (recompiled, etc.) to support this release on Arch, everything from Chromium to Firefox to NetworkManager (basically anything using 'icu') and other random stuff. This makes it hard to just downgrade a single package to test each item (i.e. if I downgrade Firefox then icu comes along, which has 12 other packages to downgrade, etc. - big dependency chain)

Firefox is my biggest vector - the inability to see what text is highlighted is a deal killer. On this laptop I'm on now (not updated yet) the GTK3 is 3.18.9 and all the exact same themes and highlights work just fine (as usual, etc.).

[raveit65]

You can't compare gtk+3.18.x with 3.20.x, everything has changed but no branching to gtk4.
See. https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/
I really suggest to file out a report against firefox.
It is impossible to do a specific styling for firefox because those devs don't want that.
So, if general styling in themes does not work , i can't do anything.
Btw. you will see the same issue with adwaita from gtk+.

[raveit65]

You can't compare gtk+3.18.x with 3.20.x, everything has changed but no branching to gtk4.
See. https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/
I really suggest to file out a report against firefox.
It is impossible to do a specific styling for firefox because those devs don't want that.
So, if general styling in themes does not work , i can't do anything.
Btw. you will see the same issue with adwaita from gtk+.

[City-busz]

At least the text highlighting in Firefox works fine with Adwaita, ContrastHighInverse, HightContrast, HightContrastInverse, Numix and win32, but doesn't work with BlackMATE, Blue-Submarine, BlueMenta, Green-Submarine, Menta, Raleigh, TraditionalGreen and TraditionalOk themes.

So I believe that it's a problem with the themes, not with Firefox.

[City-busz]

At least the text highlighting in Firefox works fine with Adwaita, ContrastHighInverse, HightContrast, HightContrastInverse, Numix and win32, but doesn't work with BlackMATE, Blue-Submarine, BlueMenta, Green-Submarine, Menta, Raleigh, TraditionalGreen and TraditionalOk themes.

So I believe that it's a problem with the themes, not with Firefox.

[troyengel]

Googling at "how to convert" a theme from 3.18 to 3.20, I see that the 1.14 release of MATE has a line item that specifically says "Full GTK 3.20 support in all MATE themes.". As this was only 3 days ago, we don't yet have packages ready to test (in Arch) but maybe this is what's wrong.

http://mate-desktop.com/blog/2016-04-08-mate-1-14-released/

Maybe this will be fixed once the 1.14 packages are available for testing by our distros...

[troyengel]

Googling at "how to convert" a theme from 3.18 to 3.20, I see that the 1.14 release of MATE has a line item that specifically says "Full GTK 3.20 support in all MATE themes.". As this was only 3 days ago, we don't yet have packages ready to test (in Arch) but maybe this is what's wrong.

http://mate-desktop.com/blog/2016-04-08-mate-1-14-released/

Maybe this will be fixed once the 1.14 packages are available for testing by our distros...

[raveit65]

confirmed!
.....now i need to find out which setting did fix that in Adwaita, because this was broken in earlier versions.

[raveit65]

confirmed!
.....now i need to find out which setting did fix that in Adwaita, because this was broken in earlier versions.

[raveit65]

Googling at "how to convert" a theme from 3.18 to 3.20,

I spend more than 700hours the last months to port our themes to gtk+-3.20
Looks like you know it better :)

I see that the 1.14 release of MATE has a line item that specifically says "Full GTK 3.20 support in all MATE themes."

I don't think that gtk+3.20 is stable. You will see more breakages before 3.20.10 ;)

[raveit65]

Googling at "how to convert" a theme from 3.18 to 3.20,

I spend more than 700hours the last months to port our themes to gtk+-3.20
Looks like you know it better :)

I see that the 1.14 release of MATE has a line item that specifically says "Full GTK 3.20 support in all MATE themes."

I don't think that gtk+3.20 is stable. You will see more breakages before 3.20.10 ;)

[JSkier21]

Another Arch user, also having several issues with the gtk 3 update.

The Mate themes worked perfectly in 3.19, in 3.20 a lot of highlighted and displayed text is either transparent, white, or washed out in the background depending on the Mate theme used. I imagine a lot of this has to do with finding the changes and fully updating your themes with this major gtk3 release. Sounds very daunting, thank you @raveit65 for your work on this, it is greatly appreciated.

FYI, Firefox has a bug for a highlight issue (a little older than gtk3.20 update, sounds like they won't fix): https://bugzilla.mozilla.org/show_bug.cgi?id=1246422

[JSkier21]

Another Arch user, also having several issues with the gtk 3 update.

The Mate themes worked perfectly in 3.19, in 3.20 a lot of highlighted and displayed text is either transparent, white, or washed out in the background depending on the Mate theme used. I imagine a lot of this has to do with finding the changes and fully updating your themes with this major gtk3 release. Sounds very daunting, thank you @raveit65 for your work on this, it is greatly appreciated.

FYI, Firefox has a bug for a highlight issue (a little older than gtk3.20 update, sounds like they won't fix): https://bugzilla.mozilla.org/show_bug.cgi?id=1246422

[lukefromdc]

Are you using Firefox built with GTK3? I don't have that here, Debian does not
build it that way and I've never custom built it. Would not want to use an oddball
firefox due to browser fingerprinting by malicious websites such as those supported
by ads.

I read somewhere that Firefox itself is broken with GTK 3.20 if built with GTK3-
and that in several other distros that has been deemed a stopper against building
it with GTK3. Firefox does not use the normal GTK widgets but custom widgets
much like say, the mate panel widget. Thus, they all need to set css names,
style classes, or css nodes to be themable in GTK 3.20.

On 4/11/2016 at 12:49 PM, "György Balló" notifications@github.com wrote:

At least the text highlighting in Firefox works fine with Adwaita,
ContrastHighInverse, HightContrast, HightContrastInverse, Numix
and win32 but doesn't work with BlackMATE, Blue-Submarine,
BlueMenta, Green-Submarine, Menta, Raleigh, TraditionalGreen and
TraditionalOk themes.

So I believe that it's a problem with the themes, not with Firefox.

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208445021

[lukefromdc]

Are you using Firefox built with GTK3? I don't have that here, Debian does not
build it that way and I've never custom built it. Would not want to use an oddball
firefox due to browser fingerprinting by malicious websites such as those supported
by ads.

I read somewhere that Firefox itself is broken with GTK 3.20 if built with GTK3-
and that in several other distros that has been deemed a stopper against building
it with GTK3. Firefox does not use the normal GTK widgets but custom widgets
much like say, the mate panel widget. Thus, they all need to set css names,
style classes, or css nodes to be themable in GTK 3.20.

On 4/11/2016 at 12:49 PM, "György Balló" notifications@github.com wrote:

At least the text highlighting in Firefox works fine with Adwaita,
ContrastHighInverse, HightContrast, HightContrastInverse, Numix
and win32 but doesn't work with BlackMATE, Blue-Submarine,
BlueMenta, Green-Submarine, Menta, Raleigh, TraditionalGreen and
TraditionalOk themes.

So I believe that it's a problem with the themes, not with Firefox.

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208445021

[lukefromdc]

I do not have Firefox built with GTK 3 and have never built Firefox, so I cannot
test or port BlackMATE right now for Firefox, which uses custom widgets and
does not use the normal GTK widgets.

On 4/11/2016 at 12:49 PM, "György Balló" notifications@github.com wrote:

At least the text highlighting in Firefox works fine with Adwaita,
ContrastHighInverse, HightContrast, HightContrastInverse, Numix
and win32 but doesn't work with BlackMATE, Blue-Submarine,
BlueMenta, Green-Submarine, Menta, Raleigh, TraditionalGreen and
TraditionalOk themes.

So I believe that it's a problem with the themes, not with Firefox.

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208445021

[lukefromdc]

I do not have Firefox built with GTK 3 and have never built Firefox, so I cannot
test or port BlackMATE right now for Firefox, which uses custom widgets and
does not use the normal GTK widgets.

On 4/11/2016 at 12:49 PM, "György Balló" notifications@github.com wrote:

At least the text highlighting in Firefox works fine with Adwaita,
ContrastHighInverse, HightContrast, HightContrastInverse, Numix
and win32 but doesn't work with BlackMATE, Blue-Submarine,
BlueMenta, Green-Submarine, Menta, Raleigh, TraditionalGreen and
TraditionalOk themes.

So I believe that it's a problem with the themes, not with Firefox.

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208445021

[lukefromdc]

According to articles in Phoronix, Firefox in GTK 3.20 cannot be fixed until
Firefox devs port to GTK 3.20, until then Firefox should not use GTK3 in
any distro or custom installation using GTK 3.20.

On 4/11/2016 at 12:11 PM, "Troy Engel" notifications@github.com wrote:

I follow what you're saying, but as a long time Fedora user the
two really don't equate due to the way the vendors package - Arch
is more true to upstream (default/unpatched) and Fedora patches a
lot of things. There are bugs in either distro that are specific
to that vendor (as well as Ubuntu, SUSE, etc. - all the same
problem).

Great question though - Arch just updated to GTK3 3.20.2 over the
weekend which is why this all just showed up this morning when I
updated one machine. :)
https://www.archlinux.org/packages/extra/x86_64/gtk3/ Many other
packages were updated (recompiled, etc.) to support this release
on Arch, everything from Chromium to Firefox to NetworkManager
(basically anything using 'icu') and other random stuff. This
makes it hard to just downgrade a single package to test each item
(i.e. if I downgrade Firefox then icu comes along, which has 12
other packages to downgrade, etc. - big dependency chain)

Firefox is my biggest vector - the inability to see what text is
highlighted is a deal killer. On this laptop I'm on now (not
updated yet) the GTK3 is 3.18.9 and all the exact same themes and
highlights work just fine (as usual, etc.).

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208429585

[lukefromdc]

According to articles in Phoronix, Firefox in GTK 3.20 cannot be fixed until
Firefox devs port to GTK 3.20, until then Firefox should not use GTK3 in
any distro or custom installation using GTK 3.20.

On 4/11/2016 at 12:11 PM, "Troy Engel" notifications@github.com wrote:

I follow what you're saying, but as a long time Fedora user the
two really don't equate due to the way the vendors package - Arch
is more true to upstream (default/unpatched) and Fedora patches a
lot of things. There are bugs in either distro that are specific
to that vendor (as well as Ubuntu, SUSE, etc. - all the same
problem).

Great question though - Arch just updated to GTK3 3.20.2 over the
weekend which is why this all just showed up this morning when I
updated one machine. :)
https://www.archlinux.org/packages/extra/x86_64/gtk3/ Many other
packages were updated (recompiled, etc.) to support this release
on Arch, everything from Chromium to Firefox to NetworkManager
(basically anything using 'icu') and other random stuff. This
makes it hard to just downgrade a single package to test each item
(i.e. if I downgrade Firefox then icu comes along, which has 12
other packages to downgrade, etc. - big dependency chain)

Firefox is my biggest vector - the inability to see what text is
highlighted is a deal killer. On this laptop I'm on now (not
updated yet) the GTK3 is 3.18.9 and all the exact same themes and
highlights work just fine (as usual, etc.).

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208429585

[raveit65]

622092a
This fixes text selection in firefox.
Another issue is menuitem:hover bg color in firefox menus which is caused by this line in Menta themes and other Mate themes.
https://github.com/mate-desktop/mate-themes/blob/master/desktop-themes/BlueMenta/gtk-3.0/gtk-widgets.css#L2731
Removing the transition effect makes the hover bg color visible.
I'm sorry to say that firefox can't handle transition effects, which is not new in gtk+, is a firefox bug and should be reported.
Using a transition effect works well in any other gtk3 application 😄
Ok, guys, if you see more issues please report it here.
But please be specific for every application and use screenshots.
You know, I'm a f....g germ working b.....h and i understand nothing 🎱

[raveit65]

622092a
This fixes text selection in firefox.
Another issue is menuitem:hover bg color in firefox menus which is caused by this line in Menta themes and other Mate themes.
https://github.com/mate-desktop/mate-themes/blob/master/desktop-themes/BlueMenta/gtk-3.0/gtk-widgets.css#L2731
Removing the transition effect makes the hover bg color visible.
I'm sorry to say that firefox can't handle transition effects, which is not new in gtk+, is a firefox bug and should be reported.
Using a transition effect works well in any other gtk3 application 😄
Ok, guys, if you see more issues please report it here.
But please be specific for every application and use screenshots.
You know, I'm a f....g germ working b.....h and i understand nothing 🎱

[lukefromdc]

You could use a long widget chain to single out Firefox menus, assuming you have
Firefox with GTK3 to test it and that GtkInspector shows enough widgets named
something other than "widget" to single out the final widget. Sorry I can't test this
myself, I have a huge amount of work in securing Firefox as I have it against websites
that try to track users.

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

https://github.com/mate-desktop/mate-
themes/commit/622092aa05f23cdc594a6205b0d93a9937322d18
This fixes text selection in firefox.
Another issue is menuitem:hover bg color in firefox menus which is
caused by this line in Menta themes and other Mate themes.
https://github.com/mate-desktop/mate-themes/blob/master/desktop-
themes/BlueMenta/gtk-3.0/gtk-widgets.css#L2731
Removing the transition effect makes the hover bg color visible.
I'm sorry to say that firefox can't handle transition effects,
which is not new in gtk+, is a firefox bug and should be
reported.
Using a transition effect works well in any other gtk3 application
😄
Ok, guys, if you see more issues please report it here.
But please be specific for every application and use screenshots.
You know I'm a f....k germ b.....h and i understand nothing
🎱

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208592859

[lukefromdc]

You could use a long widget chain to single out Firefox menus, assuming you have
Firefox with GTK3 to test it and that GtkInspector shows enough widgets named
something other than "widget" to single out the final widget. Sorry I can't test this
myself, I have a huge amount of work in securing Firefox as I have it against websites
that try to track users.

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

https://github.com/mate-desktop/mate-
themes/commit/622092aa05f23cdc594a6205b0d93a9937322d18
This fixes text selection in firefox.
Another issue is menuitem:hover bg color in firefox menus which is
caused by this line in Menta themes and other Mate themes.
https://github.com/mate-desktop/mate-themes/blob/master/desktop-
themes/BlueMenta/gtk-3.0/gtk-widgets.css#L2731
Removing the transition effect makes the hover bg color visible.
I'm sorry to say that firefox can't handle transition effects,
which is not new in gtk+, is a firefox bug and should be
reported.
Using a transition effect works well in any other gtk3 application
😄
Ok, guys, if you see more issues please report it here.
But please be specific for every application and use screenshots.
You know I'm a f....k germ b.....h and i understand nothing
🎱

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208592859

[raveit65]

Luke, gtk3-inspector is blocked by firefox and shows only the widget from main window.
So, using a long widget chain is impossible or like a blind fix.

[raveit65]

Luke, gtk3-inspector is blocked by firefox and shows only the widget from main window.
So, using a long widget chain is impossible or like a blind fix.

[lukefromdc]

If Firefox is actively blocking GTK inspector that's beyond wierd. Is there any
reason to believe that's intentional, or is code used by GTK Inspector something
a website could copy and use for an exploit?

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

Luke, gtk3-inspector is blocked by firefox and shows only the
widget from main window.
So, using a long widget chain is impossible or like a blind fix.

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208595253

[lukefromdc]

If Firefox is actively blocking GTK inspector that's beyond wierd. Is there any
reason to believe that's intentional, or is code used by GTK Inspector something
a website could copy and use for an exploit?

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

Luke, gtk3-inspector is blocked by firefox and shows only the
widget from main window.
So, using a long widget chain is impossible or like a blind fix.

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208595253

[raveit65]

I guess firefox devs want to prevent anyone to style their app, or for security reasons.

[raveit65]

I guess firefox devs want to prevent anyone to style their app, or for security reasons.

[lukefromdc]

That makes it impossible to support Firefox. Thus, I suggest either keeping GTK2
for it until they fix it. They will HAVE to fix this sooner or later if they want to
support GTK3 at all, as GTK3.18 will get old fast. BTW, they just decided to remove
a lot of support for 3ed party Firefox themes and have so far been prevented by
community resistance from removing support for many extensions.

Mozilla is a nightmare to work with, they have played with things like making Firefox
ad-supported by default (with ad sites in the "new tabs" page unless explictlly turned
off. With each new edition there are more product tie-ins to crapware like Pocket and
more things that phone home. Only the fact that Chrome is their main competitor lets
them get away with this, and in the paid/monetized website world Chrome is kicking their
ass anyway.

I only keep Firefox at all because no other browser supports an equivalent of the combination
of NoScript and Disconnect (with original whitelists removed) plus Canvasblocker to shut down
GPU fingerprinting. I have Firefox's newer functions other than HTML5 video disabled and untold
hours in going over updates with Wireshark to find and block al phone home functions. One had to
be blocked in /etc/hosts as about:config was set up to refuse removing it!

Many times I have had to block Firefox updates until these kinds of issues were shaken out.

The Torbrowser crew has said if they had to start over they would base on Chromium, as there
are fewer and fewer privacy differences and the Chromium code base is probably superior.
As of now, however, Chromium is impossible to secure against fingerprinting, the Tor crew
would have a LOT of work to do, and mistakes in Tor development could get people arrested,
tortured, even executed. Tor development is no game. Thus they have stayed with a Firefox
base and strip out the hazardous stuff.

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

I guess firefox devs want to prevent anyone to style their app, or
for security reasons.

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208595902

[lukefromdc]

That makes it impossible to support Firefox. Thus, I suggest either keeping GTK2
for it until they fix it. They will HAVE to fix this sooner or later if they want to
support GTK3 at all, as GTK3.18 will get old fast. BTW, they just decided to remove
a lot of support for 3ed party Firefox themes and have so far been prevented by
community resistance from removing support for many extensions.

Mozilla is a nightmare to work with, they have played with things like making Firefox
ad-supported by default (with ad sites in the "new tabs" page unless explictlly turned
off. With each new edition there are more product tie-ins to crapware like Pocket and
more things that phone home. Only the fact that Chrome is their main competitor lets
them get away with this, and in the paid/monetized website world Chrome is kicking their
ass anyway.

I only keep Firefox at all because no other browser supports an equivalent of the combination
of NoScript and Disconnect (with original whitelists removed) plus Canvasblocker to shut down
GPU fingerprinting. I have Firefox's newer functions other than HTML5 video disabled and untold
hours in going over updates with Wireshark to find and block al phone home functions. One had to
be blocked in /etc/hosts as about:config was set up to refuse removing it!

Many times I have had to block Firefox updates until these kinds of issues were shaken out.

The Torbrowser crew has said if they had to start over they would base on Chromium, as there
are fewer and fewer privacy differences and the Chromium code base is probably superior.
As of now, however, Chromium is impossible to secure against fingerprinting, the Tor crew
would have a LOT of work to do, and mistakes in Tor development could get people arrested,
tortured, even executed. Tor development is no game. Thus they have stayed with a Firefox
base and strip out the hazardous stuff.

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

I guess firefox devs want to prevent anyone to style their app, or
for security reasons.

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/114#issuecomment-208595902

[raveit65]

text selection fix for all other themes.
485ec36

[raveit65]

text selection fix for all other themes.
485ec36

[rookierks]

I believe I have found two more glitches, but they are not critical as they don't break anything (that I can see). I'm using xfce on arch linux with the latest git of mate-themes. The glitches seem to manifest only when a compositor is running, I've tried both xfce's compositor and compton.

The first glitch is related to nm-applet, when hovering the mouse over the notification area icon, before the tooltip(?) shows up I can see the tooltip quickly alternating with a clone of what I have to the left on the same panel, this happens a few times before it settles down. This happens with all mate themes but it works as expected with adwaita.

The second glitch is related to evince, when the back/forward buttons are activated and the mouse is over an activated button, the tooltip does not show up and the button state/look quickly alternates between the active state and inactive/pressed state. This happens with all mate themes but it works as expected with adwaita.

[rookierks]

I believe I have found two more glitches, but they are not critical as they don't break anything (that I can see). I'm using xfce on arch linux with the latest git of mate-themes. The glitches seem to manifest only when a compositor is running, I've tried both xfce's compositor and compton.

The first glitch is related to nm-applet, when hovering the mouse over the notification area icon, before the tooltip(?) shows up I can see the tooltip quickly alternating with a clone of what I have to the left on the same panel, this happens a few times before it settles down. This happens with all mate themes but it works as expected with adwaita.

The second glitch is related to evince, when the back/forward buttons are activated and the mouse is over an activated button, the tooltip does not show up and the button state/look quickly alternates between the active state and inactive/pressed state. This happens with all mate themes but it works as expected with adwaita.

[raveit65]

I believe I have found two more glitches, but they are not critical as they don't break anything (that I can see). I'm using xfce on arch linux with the latest git of mate-themes. The glitches seem to manifest only when a compositor is running, I've tried both xfce's compositor and compton.

Are both compositor compiled with gtk2 or 3 ?
Because tooltips are using the toolkit which are used by the WM.

Buttons of evince or nm-applet have several states if active, normal/focused ,pre-light and so called focus-hover-active (pressed).
Some themes use a transition effect for buttons for moving between those states for gtk3 applications like evince or nm-applet, but not all themes.
I noticed that the tooltip comes up not until the transition effect is finished, but i see no glitches or artifacts here.
So what you see here is the transition effect and not a bug, assuming you don't see artifacts with you WM.
A clean effect you will see with submarine themes because those themes don't use border images for buttons.
With themes which use border images the effect can sometimes looks a bit strange.
I'm using compiz-0.8.12 or marco with compositor.
Do you see this with traditional themes?
Because they don't use a transition effect for buttons.
Of course this is in mate-session (gtk3) , i do not use or have xfce installed.

[raveit65]

I believe I have found two more glitches, but they are not critical as they don't break anything (that I can see). I'm using xfce on arch linux with the latest git of mate-themes. The glitches seem to manifest only when a compositor is running, I've tried both xfce's compositor and compton.

Are both compositor compiled with gtk2 or 3 ?
Because tooltips are using the toolkit which are used by the WM.

Buttons of evince or nm-applet have several states if active, normal/focused ,pre-light and so called focus-hover-active (pressed).
Some themes use a transition effect for buttons for moving between those states for gtk3 applications like evince or nm-applet, but not all themes.
I noticed that the tooltip comes up not until the transition effect is finished, but i see no glitches or artifacts here.
So what you see here is the transition effect and not a bug, assuming you don't see artifacts with you WM.
A clean effect you will see with submarine themes because those themes don't use border images for buttons.
With themes which use border images the effect can sometimes looks a bit strange.
I'm using compiz-0.8.12 or marco with compositor.
Do you see this with traditional themes?
Because they don't use a transition effect for buttons.
Of course this is in mate-session (gtk3) , i do not use or have xfce installed.

[raveit65]

Btw, evince is not really ready for gtk+-3.20 ;)

[rave@mother ~]$ evince

(evince:2864): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:2864): Gtk-WARNING **: Failed to fetch network locations: Zeitüberschreitung wurde erreicht

(evince:2960): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3002): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3002): Gtk-WARNING **: Allocating size to EvSidebar 0x562030cc9340 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(evince:3041): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3059): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3083): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3083): Gtk-WARNING **: Allocating size to EvSidebar 0x56231499e340 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(evince:3115): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3115): Gtk-WARNING **: Allocating size to EvSidebar 0x55f304deb340 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

Message Theme parsing error: :56:20 is misleading, this comes from internal evince code.
Our themes don't use '-gtk-key-bindings` ;)

[raveit65]

Btw, evince is not really ready for gtk+-3.20 ;)

[rave@mother ~]$ evince

(evince:2864): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:2864): Gtk-WARNING **: Failed to fetch network locations: Zeitüberschreitung wurde erreicht

(evince:2960): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3002): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3002): Gtk-WARNING **: Allocating size to EvSidebar 0x562030cc9340 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(evince:3041): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3059): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3083): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3083): Gtk-WARNING **: Allocating size to EvSidebar 0x56231499e340 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(evince:3115): Gtk-WARNING **: Theme parsing error: <data>:56:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings'

(evince:3115): Gtk-WARNING **: Allocating size to EvSidebar 0x55f304deb340 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

Message Theme parsing error: :56:20 is misleading, this comes from internal evince code.
Our themes don't use '-gtk-key-bindings` ;)

[rookierks]

Are both compositor compiled with gtk2 or 3 ?
Because tooltips are using the toolkit which are used by the WM.

Good question, if anything I'd say xfce's compositor might be compiled with gtk2 as xfce is still based on gtk2 if I'm not mistaken. Looking through the dependencies of compton I don't see anything related to gtk2 or 3.

Buttons of evince or nm-applet have several states if active, normal/focused ,pre-light and so called focus-hover-active (pressed).
Some themes use a transition effect for buttons for moving between those states for gtk3 applications like evince or nm-applet, but not all themes.

I only see the problem for tooltips. For nm-applet this happens for the tooltip of the notification area icon and tootips while hovering the mouse over over text input fields.

I noticed that the tooltip comes up not until the transition effect is finished, but i see no glitches or artifacts here.
So what you see here is the transition effect and not a bug, assuming you don't see artifacts with you WM.
A clean effect you will see with submarine themes because those themes don't use border images for buttons.
With themes which use border images the effect can sometimes looks a bit strange.

With the -submarine themes evince does not show any problems but there still seems to be an animation when hovering the mouse over a button. With nm-applet I still see the glitch. After looking at it a bit more with themes, it seems to me the glitch clones a rectangle (starting from top left) the same size as tooltip+shadow, maybe this is a compositor bug (kind of doubt it since two different compositors show the problem) or maybe a driver bug.

For the evince glitch it seems dependent on the position of the mouse over the button, see https://github.com/rookierks/images/blob/master/glitch.png

On the top there is a glitch (during the animation?) but the tooltip does show up and the button does not keep jumping, on the bottom the tooltip never comes up and the button keeps jumping.

I'm using compiz-0.8.12 or marco with compositor.
Do you see this with traditional themes?
Because they don't use a transition effect for buttons.
Of course this is in mate-session (gtk3) , i do not use or have xfce installed.

I'll try to see if I can coerce xfce to use marco and see if I still have problems. Regarding the themes I see less glitches (evince ok, nm-applet with glitches) with the -submarine themes, all the others show more glitches.

[rookierks]

Are both compositor compiled with gtk2 or 3 ?
Because tooltips are using the toolkit which are used by the WM.

Good question, if anything I'd say xfce's compositor might be compiled with gtk2 as xfce is still based on gtk2 if I'm not mistaken. Looking through the dependencies of compton I don't see anything related to gtk2 or 3.

Buttons of evince or nm-applet have several states if active, normal/focused ,pre-light and so called focus-hover-active (pressed).
Some themes use a transition effect for buttons for moving between those states for gtk3 applications like evince or nm-applet, but not all themes.

I only see the problem for tooltips. For nm-applet this happens for the tooltip of the notification area icon and tootips while hovering the mouse over over text input fields.

I noticed that the tooltip comes up not until the transition effect is finished, but i see no glitches or artifacts here.
So what you see here is the transition effect and not a bug, assuming you don't see artifacts with you WM.
A clean effect you will see with submarine themes because those themes don't use border images for buttons.
With themes which use border images the effect can sometimes looks a bit strange.

With the -submarine themes evince does not show any problems but there still seems to be an animation when hovering the mouse over a button. With nm-applet I still see the glitch. After looking at it a bit more with themes, it seems to me the glitch clones a rectangle (starting from top left) the same size as tooltip+shadow, maybe this is a compositor bug (kind of doubt it since two different compositors show the problem) or maybe a driver bug.

For the evince glitch it seems dependent on the position of the mouse over the button, see https://github.com/rookierks/images/blob/master/glitch.png

On the top there is a glitch (during the animation?) but the tooltip does show up and the button does not keep jumping, on the bottom the tooltip never comes up and the button keeps jumping.

I'm using compiz-0.8.12 or marco with compositor.
Do you see this with traditional themes?
Because they don't use a transition effect for buttons.
Of course this is in mate-session (gtk3) , i do not use or have xfce installed.

I'll try to see if I can coerce xfce to use marco and see if I still have problems. Regarding the themes I see less glitches (evince ok, nm-applet with glitches) with the -submarine themes, all the others show more glitches.

[rookierks]

Using marco was easier than I thought (if I did it right). I've installed marco (gtk3) from arch's repos and replaced xfwm4 with 'marco --replace', as with xfwm4 I see no glitches if I don't use a compositor, when I use compton I start to see glitches again.

[rookierks]

Using marco was easier than I thought (if I did it right). I've installed marco (gtk3) from arch's repos and replaced xfwm4 with 'marco --replace', as with xfwm4 I see no glitches if I don't use a compositor, when I use compton I start to see glitches again.

[raveit65]

Your screenshot shows the gtk2 tooltip, so this can't be related to gtk+3 changes.
The gtk2 part isn't change since years in our themes.
So, it looks like a driver issue with compositor.

[raveit65]

Your screenshot shows the gtk2 tooltip, so this can't be related to gtk+3 changes.
The gtk2 part isn't change since years in our themes.
So, it looks like a driver issue with compositor.

[raveit65]

Ok, guys firefox issue is fixed, i suggest to ask your distro maintainer to patch mate-themes.
Sorry, i can't release a new version every day for a single fix.
Fix is in fedora https://bodhi.fedoraproject.org/updates/mate-themes-3.20.5-2.fc24

[raveit65]

Ok, guys firefox issue is fixed, i suggest to ask your distro maintainer to patch mate-themes.
Sorry, i can't release a new version every day for a single fix.
Fix is in fedora https://bodhi.fedoraproject.org/updates/mate-themes-3.20.5-2.fc24

[troyengel]

Looking good! The main Firefox seems to be nice now (thanks!), but I notice that my extensions are not styled correctly (but text selection works). If I switch to Clearlooks (has no gtk-3.0) it falls back to Adwaita and draws the correct borders around the buttons and entry fields, but if I use TraditionalOk (with the git commits) I am missing the decorations (?) and radio button outlines and tickmarks. Tailing my .xsession-errors file doesn't produce any meaningful output about the theme, is this something we can fix or is it a Firefox problem?

As I was selecting these small screenshots to upload, I notice that the builtin Firefox file chooser also looks the same (missing proper button outlines and stuff) just like these, so it's not just the addons but internal to FF as well. (I also looked at the File -> Open File.. dialog and a few others, all are missing the button outlines that go with TradtionalOk)

Clearlooks Lastpass dialog:

TraditionalOk-patched Lastpass dialog:

Two other random addons:

[troyengel]

Looking good! The main Firefox seems to be nice now (thanks!), but I notice that my extensions are not styled correctly (but text selection works). If I switch to Clearlooks (has no gtk-3.0) it falls back to Adwaita and draws the correct borders around the buttons and entry fields, but if I use TraditionalOk (with the git commits) I am missing the decorations (?) and radio button outlines and tickmarks. Tailing my .xsession-errors file doesn't produce any meaningful output about the theme, is this something we can fix or is it a Firefox problem?

As I was selecting these small screenshots to upload, I notice that the builtin Firefox file chooser also looks the same (missing proper button outlines and stuff) just like these, so it's not just the addons but internal to FF as well. (I also looked at the File -> Open File.. dialog and a few others, all are missing the button outlines that go with TradtionalOk)

Clearlooks Lastpass dialog:

TraditionalOk-patched Lastpass dialog:

Two other random addons:

[raveit65]

hmm, i have a different results with latest mate-themes.

• dialog open
  

[rave@mother ~]$ rpm -qa firefox
firefox-45.0.1-6.fc24.x86_64

[raveit65]

hmm, i have a different results with latest mate-themes.

• dialog open
  

[rave@mother ~]$ rpm -qa firefox
firefox-45.0.1-6.fc24.x86_64

[rookierks]

Your screenshot shows the gtk2 tooltip, so this can't be related to gtk+3 changes.
The gtk2 part isn't change since years in our themes.
So, it looks like a driver issue with compositor.

I have tried compiz and indeed the artifact problem with nm-applet is not there, so I guess we can file that under driver/compositor bug/problem.

The glitch with the back/forward buttons on evince (it is build against gtk3 in arch*) also happens with compiz. All I know is it doesn't happen with adwaita or the -submarine themes, but as you have mentioned, evince for gtk3 doesn't seem to be baked properly yet so I guess it isn't worth losing sleep over it.
Scratch that, I've just managed to trigger the same problem with adwaita, but I need to leave the mouse cursor hovering in a different position. Definitely a bug in either gtk3 or evince.

Like I said before, if not using compositing, everything works as expected. My intention was only to report what could be a problem with the themes, after all bugs don't get fixed if they are not reported.

ldd /usr/bin/evince | grep gtk
libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007f76b1d82000)

[rookierks]

Your screenshot shows the gtk2 tooltip, so this can't be related to gtk+3 changes.
The gtk2 part isn't change since years in our themes.
So, it looks like a driver issue with compositor.

I have tried compiz and indeed the artifact problem with nm-applet is not there, so I guess we can file that under driver/compositor bug/problem.

The glitch with the back/forward buttons on evince (it is build against gtk3 in arch*) also happens with compiz. All I know is it doesn't happen with adwaita or the -submarine themes, but as you have mentioned, evince for gtk3 doesn't seem to be baked properly yet so I guess it isn't worth losing sleep over it.
Scratch that, I've just managed to trigger the same problem with adwaita, but I need to leave the mouse cursor hovering in a different position. Definitely a bug in either gtk3 or evince.

Like I said before, if not using compositing, everything works as expected. My intention was only to report what could be a problem with the themes, after all bugs don't get fixed if they are not reported.

ldd /usr/bin/evince | grep gtk
libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007f76b1d82000)

[troyengel]

I can't explain it, but there's some sort of difference with GTK3 itself when running a theme out of /usr/share than from ~/.themes -- my vendor just updated the package with these latest commits, it works when used out of /usr/share but not from my home directory.

I used gtk3-demo and 'export GTK_THEM=foobar' to go back and forth and when I do this with the updated package:

$ export GTK_THEME=TraditionalOk
$ gtk3-demo

...it all works using /usr/share/themes/TraditionalOk. If I copy that to ~/.themes/Fog (and update index.theme to swap names), when I run this:

$ export GTK_THEME=Fog
$ gtk3-demo

...a lot of errors are spit out into the console. Same exact theme, different results -- this smells like a GTK3 bug in how it finds themes, as when I run it in strace I see the /usr/share variant properly opening all the PNG files and when I run it out of my home directory it doesn't load any of those elements (which is why I'm assuming I showed broken dialogs in Addons).

Just leaving this here in case anyone else runs into this oddity.

[troyengel]

I can't explain it, but there's some sort of difference with GTK3 itself when running a theme out of /usr/share than from ~/.themes -- my vendor just updated the package with these latest commits, it works when used out of /usr/share but not from my home directory.

I used gtk3-demo and 'export GTK_THEM=foobar' to go back and forth and when I do this with the updated package:

$ export GTK_THEME=TraditionalOk
$ gtk3-demo

...it all works using /usr/share/themes/TraditionalOk. If I copy that to ~/.themes/Fog (and update index.theme to swap names), when I run this:

$ export GTK_THEME=Fog
$ gtk3-demo

...a lot of errors are spit out into the console. Same exact theme, different results -- this smells like a GTK3 bug in how it finds themes, as when I run it in strace I see the /usr/share variant properly opening all the PNG files and when I run it out of my home directory it doesn't load any of those elements (which is why I'm assuming I showed broken dialogs in Addons).

Just leaving this here in case anyone else runs into this oddity.

[raveit65]

But Fog theme isn't from us.
All those error messages indicates that this themes isn't ported to gtk+-3.20.
As you can see in our git logs we have removed all this deprecated style elements to avoid spamming the terminal and other logs.
Edit:
I guess you have Fog installed in /usr/share/themes/

[raveit65]

But Fog theme isn't from us.
All those error messages indicates that this themes isn't ported to gtk+-3.20.
As you can see in our git logs we have removed all this deprecated style elements to avoid spamming the terminal and other logs.
Edit:
I guess you have Fog installed in /usr/share/themes/

[troyengel]

@raveit65 - language barrier I think with my update, it is not the old Fog - I am saying I copy the new TraditionalOk to a new name Fog (or Test, or whatever - it does not matter) to my ~/.themes/. I chose 'Fog' because it is an old name I know from a long time ago that is not used anymore. :)

[troyengel]

@raveit65 - language barrier I think with my update, it is not the old Fog - I am saying I copy the new TraditionalOk to a new name Fog (or Test, or whatever - it does not matter) to my ~/.themes/. I chose 'Fog' because it is an old name I know from a long time ago that is not used anymore. :)

[raveit65]

I did understand you very well, but if you use 'export GTK_THEME=Fog' and get warnings which aren't from TOK theme, than it looks like that those theme is somewhere installed, maybe /usr/local.....
but maybe i'm wrong........

[raveit65]

I did understand you very well, but if you use 'export GTK_THEME=Fog' and get warnings which aren't from TOK theme, than it looks like that those theme is somewhere installed, maybe /usr/local.....
but maybe i'm wrong........