GNOME Bugzilla – Bug 702120
theming hooks should be shipped with the source
Last modified: 2019-03-23 20:57:05 UTC
The bug has been reported on https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/1186633 "In gedit 3.8.2 in vanilla GNOME with Adwaita, the find box's background turns red when text is not found. This doesn't happen in Ubuntu with Ambiance. We probably need to add styling information to Ambiance to make this happen." The coloring comes from the theme, the gnome themes use "" GeditViewFrame .gedit-search-slider .not-found { color: @error_fg_color; background-image: none; background-color: @error_bg_color; } GeditViewFrame .gedit-search-slider .not-found:selected { background-color: @theme_selected_bg_color; color: @theme_selected_fg_color; }" Is there anything theme specific in there? The color used is "error_bg_color", that can be defined by the theme but does the snippet needs to be duplicated in every new theme? Would it make sense to just include that css with the software?
well this is theme specific, so each theme should provide its own stuff. IMHO there should be just one theme so drop ambiance ;)
Well, those rules are in adwaita's css, ambience would need to either cut&paste them verbatim (if it defines @error_bg_color etc) or provide an alternative styling if it wants a different look. I agree that the current split of styling between apps and themes is subotimal and at least under-document, but that's probably outside the scope of this bug report :-)
> IMHO there should be just one theme so drop ambiance ;) or maybe we should drop adwaita from distros in favor of the distribution theme if there is only one theme... ;-) > but that's probably outside the scope of this bug report not really, that's rather what's this bug is about, why do you force every theme to duplicate that css where there is nothing specific in it? (the error_bg_color should be defined in the theme but is not really specific to gedit)
well really, we have discussed this a lot of times with gtk+ developers and what they say is to do it at theme level and it really makes sense since it is the theme the one that declares the colors. We are just using some specific classes and then we adjust Adwaita for them since it is the theme I use and Paolo uses. If I was using Ambiance then I would probably care about it. In any case several other apps declare stuff there so I guess Ambiance should try to get some more sync on this case, or once again drop Ambiance and just use Adwaita ;)
> not really, that's rather what's this bug is about, why do you force every > theme to duplicate that css where there is nothing specific in it? We cannot rely on @some_color being defined, that's not how css works and there is no set of colors that are declared as part of the API. What we need to define is a set of conventional css classes that all themes should have, for instance I filed https://bugzilla.gnome.org/show_bug.cgi?id=668432 more than one year ago. Beside gtk at the moment does not allow to define a "cascading" css like you would do on a web page that is merged with the theme css according to css precedence rules, if a css is specified by the app, it wins over everything, which would be even worse for ambience since gedit would end up hardcoding adawaita colors etc. Do not get me wrong, I am not quite happy about the current situation either, but that's what we have and ambience already has a gedit.css in its application specific css files, it is just a matter of updating it for the changes we had in 3.8