IF the tag behaves I can quickly fix that in adwaita, anyway it's an alien lib, I was told (by, uhm, you actually :)) not to stick non GTK+ stuff in adwaita (see floating status bar, to name one), shall we change that policy?

Created attachment 311980 [details]
fixable

the rendering is fixable if applications agree on style classes to set on the tags

... or set their own style classes and provide their own css.

The current issue is caused by the entry background being inherited by the tag and not being reset by the app shipped css ('background-image: none;' should suffice), so I can't really fix this in adwaita without at least a style class, say 'tag', working all over the place (which could be set by libgd, I guess).
I can assume that 'documents-entry-tag' is what apps are using.
ATM Adwaita doesn't provide style for that tag at all.

None of the users of GdTaggedEntry that I've looked at seems to be setting any style class on their tags, currently. Indeed, just having  libgd provide a tag class should be an easy solution.

Oh, I'm wrong. There is a default style class, and it is as you say: documents-entry-tag

So what shall we do? Ask apps to fix their stuff or fix this generally in Adwaita?
That styleclass is pretty ugly anyway, I'd really prefer something generic (say 'tag') in Adwaita, whatever we do would probably require apps to modify their shipped css.
A proper general solution would require some thinkering though, I think everything sporting the GdTaggedEntry at the moment just use a blue tag, since differntly coloured tags actually makes sense we should probably consider that somehow. It would be nice to have libgd hackers opinions also.

not sure what you mean with 'at the moment'. As my screenshot shows, at the moment everything sporting GdTaggedEntry is broken...

There's no such thing as "libgd hackers", really

Anyway, if you want my opinion: Please add some minimal styling to Adwaita so that the default style class looks non-broken. If apps want to use their own style classes, they will have to use their own css.

Apps are already uaing their own styling, that styling is broken though.

So to summarize, I can push their fix in adwaita, but I don't like that much. I'd prefer to directly move the entry tag styling in adwaita doing things properly.

IMO if we move the style to Adwaita, we should have the widget (or the tags feature) in GTK proper.
Until then, my suggestion is to add the CSS snippet directly to every application that needs it.

alright then, you get to fix all the apps... can we at least put a suitable css snipplet in libgd for apps to copy ?

I think you got Cosimo wrong, I'm pretty sure he meant he's going to implement the tag in the the entry in gtk+ properly

that is not an easy thing to do, and not a fix that will give us readable tags in 3.18.1

Lapo, to be clear what I meant is that we should implement the tag in the entry for 3.20, but patch affected apps for 3.18.1.

I just pushed a fix to gnome-documents. This was happening there because since https://git.gnome.org/browse/libgd/commit/?id=7e0dd4b15ea80673f62249ac092763b10fc226ad the entry's context will be reused. Since the entry specifies a background-image, the style should first remove it, or the background color will not be applied: https://git.gnome.org/browse/gnome-documents/commit/?id=178fc7a285f942a7f5a58ba17882de880bf610d6

I will look at other the applications mentioned in comment#0 if they need a similar treatment.

Filed https://bugzilla.gnome.org/show_bug.cgi?id=755600 for gnome-photos and https://bugzilla.gnome.org/show_bug.cgi?id=755601 for gnome-music.
Totem is crashing for me at startup so I could not test there.

I also added an example CSS to libgd to theme the entry.
Since libgd is a library without an initialization method it would be a bit hard to make sure the style is added automatically. I think I'd rather spend that time adding this feature to GtkEntry.

I think this bug could be closed, now that we've determined that there is no bug in GTK.

Yay, thanks Cosimo!