Created attachment 329665 [details]
A PNG file taken from version 3.14.2.3

Hey. To introduce myself I'm the guy that updated the gtk2 theme for 3.20 and the current "maintainer" of it.

To explain why this bug happens: gtk2 is old and really inconsistent in rendering widgets, and GtkEntry is the unfortunate one to get a _really_ bad way of rendering, at least style wise.

It consists of two elements: the border and the (inside) fill. I don't remember the details, but basically neither of them can be transparent. If you want rounded corners you have to include some of the fill in the border asset (I tried to do it in another more logical way but it messed up both Qt and widgets inside notebooks quite badly iirc). Also, since we take the look from the gtk3 version of Adwaita we also have a gradient inside the entry so both the border and fill asset include it.

You can take a look at both assets, the border is named entry.png (with variations for different states) and the inside fill is named entry-background.png. They're located under /usr/share/themes/Adwaita/gtk-2.0/assets.

As you can see, entry.png looks like the whole entry, but gtk2 carves a whole into it and fills it with entry-background.png (though this is not the case everywhere, it differs from implementation to implementation).

Therefore, since the whole widget consists of assets, you cannot control the colour without changing them. bg[STATE] or base[STATE] (I forget which is used) play no part here, since neither can be a gradient and had to be replaced by an asset.

To explain why your patch is wrong and you should NOT use it, definitely not in a official distro package:

What you do is you override the 'entry_bg' invocations (or whatever they are called) from line 1189 (where all the entry-related styles reside), replacing the fill asset with null.png.

Now null.png is the most useless asset from the old version. You get the same effect by simply removing the "file=" line. The border line is redundant since the default is {0, 0, 0, 0} (and it also doesn't follow the style of the surrounding file), stretch is useless since you are stretching nothing. The detail line is redundant too I think because FLAT_BOX is only used by entry_bg in the entry.

So, the corrected version which you should still NOT use is:

+  engine "pixmap" {
+
+    image {
+      function = FLAT_BOX
+      state    = NORMAL
+    }
+
+    image {
+      function = FLAT_BOX
+      state    = ACTIVE
+    }
+
+  }
+

But the effect is still as if you removed lines 1223 and 1236 (hm, noticed I made a mistake with blank lines there, will fix). You could also include the disabled state and remove 1230 too.

However, that still isn't the correct way to do it and will produce sever glitches in different applications. The real way would be to edit assets.svg to your liking.

Anyway, I can't mark this as WONTFIX since I'm not a foundation member yet so someone please do. Cheers.

Thanks for taking time to report and debug this however. If you have any questions I'll gladly answer.

(In reply to Juraj Fiala from comment #2)
> However, that still isn't the correct way to do it and will produce sever
> glitches in different applications. The real way would be to edit assets.svg
> to your liking.
> 

That someone provides a wrong patch is not a reason to mark a bug as WONTFIX; there's still a bug that is being reported! The bug is also about an existing application which doesn't work anymore because of changes made in the theme. The behaviour of GTK+2.x should stay the same. Existing GTK+2.x applications should not need to modify their applications so that they're doing something technically more correct. GTK+2.x is in maintenance mode, nobody expects nor should be having to deal with behavioural changes.

> Anyway, I can't mark this as WONTFIX since I'm not a foundation member yet
> so someone please do. Cheers.

Bugzilla permissions aren't linked to foundation membership. I've added permissions for you to change bugs, but read up on maintainership.

(In reply to Olav Vitters from comment #4)
> (In reply to Juraj Fiala from comment #2)
> > However, that still isn't the correct way to do it and will produce sever
> > glitches in different applications. The real way would be to edit assets.svg
> > to your liking.
> > 
> 
> That someone provides a wrong patch is not a reason to mark a bug as
> WONTFIX; there's still a bug that is being reported! The bug is also about
> an existing application which doesn't work anymore because of changes made
> in the theme. The behaviour of GTK+2.x should stay the same. Existing
> GTK+2.x applications should not need to modify their applications so that
> they're doing something technically more correct. GTK+2.x is in maintenance
> mode, nobody expects nor should be having to deal with behavioural changes.
> 

No, there is no way to fix this, not with the current state. The previous theme worked but was broke different things because of that. Editing the SVG won't fix the bug but may be a workaround, that's why I mentioned it.

I can roll back to the state before but I don't see much benefit from it, but if you do I can do it. Keep in mind I have like zero experience and prone to make mistakes, so please be patient with me ;-)

> > Anyway, I can't mark this as WONTFIX since I'm not a foundation member yet
> > so someone please do. Cheers.
> 
> Bugzilla permissions aren't linked to foundation membership. I've added
> permissions for you to change bugs, but read up on maintainership.

Hm, I think someone told me I needed git write access for bugzilla. *shrug*

Thanks though, it'll make things a lot easier. Will read up.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-themes-extra/issues/4.