Theme doesn't honor color scheme

[sez11a]

Seems like the Breeze color scheme is hard-coded into the GTK theme. The oxygen-gtk(2)(3) theme honors the color scheme chosen. Can you make the Breeze theme honor the KDE color scheme? See screenshot comparison between Dolphin and VIM.

[ghost]

Breeze is a pixmap theme on the GTK 2 side and uses prerendered images in GTK 3, meaning that it must be hardcoded. Oxygen GTK was using a dynamic theming API that allowed for this kind of integration, but it's being phased out of GTK 3 so we have to rely on something a bit less flexible.

It could be possible to write a separate program that reads KDE's colors, writes them to the relevant svg, gtkrc, and css files, then runs the script to generate the .png files that are finally used by the theme. However, that would take some work and be entirely separate from the theme itself, unlike Oxygen GTK's integrated method that works at runtime.

At the moment, we're really just focusing on getting the theme itself right with these two color schemes, Breeze and Breeze Dark. In the future we could possibly integrate something to generate new color schemes, but I think it will have to wait until this phase is over.

[ghost]

Just a small update for those unaware, dirruk1 has been working on this feature on this branch: https://github.com/dirruk1/gnome-breeze/tree/color-effects

So it may not be impractical to regenerate the theme's colors, after all.

[sez11a]

Awesome!

[msva]

@scionicspectre And is it any issues, preventing from doing dynamic theming API, like it was in oxygen? :)

[ghost]

@msva As previously mentioned, the theming API Oxygen-GTK used is now deprecated in GTK 3, so it's best to use the same precomputed method for both GTK 2 and GTK 3 so they're more alike. I'd rather have 2 ways of handling color schemes across Qt and GTK compared to 3 ways, especially with GTK 2 on its deathbed.

The hope is that the colors can be updated automatically when the theme is changed in System Settings to mimic what we've had previously. Of course, this means some files may have to be stored locally instead of system-wide, since we don't want you putting in your password every time you change colors.

There are still a few (many?) kinks to work out. Chances are we won't see the color effects upstream for a while longer, as we have yet to get the base theme into Plasma.

[msva]

So... As QtCurve contributor (some time ago), as the reader of https://bugzilla.gnome.org/show_bug.cgi?id=735211 , and after some kind of spectations on gtk3 I starting to think, that it is time to boycott gtk3 because of such development policy :'(

[ghost]

@msva We have every intention of supporting users of GTK applications as best we can, despite the political situations that arise. Of course we'd like GTK developers to take visual compatibility as seriously the Qt community has (QGtkStyle, Oxygen GTK, and now Breeze GTK), but I don't think it's fair to punish the developers who make GTK applications or their users for situational shortcomings.

As the original author of Adwaita's GTK 2 theme, which I partially made for the sake of Qt applications in GNOME, I can assert that not all GNOME people feel this was an ideal outcome.

That said, you and every other user have every right to use whatever software you feel comfortable with for technical or philosophical reasons. Personally, I can relate to your sentiment, but I suppose a bug report isn't the best place to discuss the matter.

[ghost]

I would personally be interested in seeing a variation of this theme for the "Wonton Soup" color scheme, as the contrast is a little easier to bear than straight Breeze Dark.

[shmerl]

I'm using Wonton Soup with GTK2 Breeze theme, but I keep "apply colors to non Qt applications" on. And it honors those colors. With GTK3 though it doesn't.

[ghost]

@shmerl That definitely shouldn't be happening. Are you certain you aren't using QtCurve or something similar for GTK 2? We use statically colored bitmaps for many UI elements in GTK 2, and it's actually impossible with the current infrastructure in GTK 3, as well.

We will eventually create a separate program that renders the pixmaps and generates the gtkrc and css files based on kcolors and places it in your /home/.themes folder so it's used instead of the system-wide theme. Currently, a prototype for this exists in the color-effects branch but it will have to be rebased and tweaked a bit before it sees widespread distribution.

[shmerl]

You are right, I noticed that scrollbar color doesn't change, but a lot of other elements in Firefox are affected by "apply colors to non Qt applications", including various dialog UI elements.

Here are my settings:

And here are examples with "apply colors to non Qt applications" on and off accordingly:

[ghost]

Odd. In any case, this shouldn't occur- I'm not able to reproduce this in any scenario on multiple distros (Arch, Ubuntu, SuSE), fresh login, fresh user, whatever. That's Firefox or otherwise. It's not an intended usecase as yet and would function very differently when it's an available feature.

I am very curious about your setup, since I can't override the colors with 'Apply colors to non-Qt apps' in any application, except of course for the bug in text highlights which has caused us to turn off that option for the time being.

[shmerl]

My setup is current Debian testing x86_64, KDE Plasma 5.4.2. gtk2-engines-pixbuf is 2.24.28. You can install it in VM to verify (downloadable from here: http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/ just get the first hybrid DVD/USB image and select KDE during installation).

And I use stock (not distro packaged) Mozilla build of Firefox 42, 64 bit.

[ghost]

Cool- thanks for giving me the exact environment, I'll test it soon. Is it only happening in Firefox?

[shmerl]

I just tested with Geany and Pidgin which use GTK2, and they are also partially affected by that setting.

[flying-sheep]

hi, the work on color-themeable SVGs is done, now we “only” need to utilize them. we know that on color theme change, a D-Bus signal is sent to all listening applications.

my idea:

1. reuse system SVGs or include upstream ones by git submodule (i mean the SVGs used for the QML version of the widgets)
2. check if we can use CSS to set the colors in the GTK theme, or have to build SVGs by creating modified versions of the themeable ones with fixed colors.
3. start a daemon which rebuilds either the CSS or the SVGs once a color theme change D-Bus signal is detected
4. send a signal to all GTK applications that makes them redraw (no idea how… StyleContext? style_updated?)

[ghost]

@flying-sheep That's been the plan all along, really. We actually have a branch called color-effects that did most of these things a while back but we need to refactor and polish the main theme before we re-implement this functionality.

We're planning to bundle it all into a single script that generates the theme automatically and places it in ~/.themes, since this is the first place GTK looks for a theme (meaning the user wouldn't be forced to manually change anything). The default Breeze color scheme would remain system-wide, while we might simply remove Breeze-Dark since it could be dynamically created.

One issue we've run into is that, while writing a gtkrc and css file is quick, rendering images from an SVG can take more than a couple seconds, so we'll probably end up rendering the GTK 3 theme before GTK 2. Alternatively, we could cache the bitmaps so previously used color schemes load more quickly, but that could be considered a waste of space.

[flying-sheep]

rendering images from an SVG can take more than a couple seconds

what renderer do you use? inkscape sure is slow to start up…

[ghost]

@flying-sheep Svgwrite with Cairosvg. I don't know why I felt compelled to say 'more than' - it's only a couple seconds. It's not dreadfully slow- it just isn't instantaneous, and it relies on the user's hardware. Still, it's a bit jarring when all your Qt apps change immediately, but what can you do? I suppose there could be some way to optimize it (much) later on.

But yeah, this issue's on the end of our agenda. There's a lot of essential work to do before this can be applied in a practical way.

[flying-sheep]

why can’t GTK use the SVGs directly? my idea was just to replace the theme colors in the SVG and then write the changed SVGs to $XDG_DATA_HOME/themes

and i think alternatives are in imagemagick, librsvg, batik, …

[shmerl]

It's better instead of $HOME/.themes to use $HOME/.local/share/themes (or even more correctly, $XDG_DATA_HOME/themes and when $XDG_DATA_HOME env var isn't set - $HOME/.local/share/themes).

That would be conformant to XDG base directory specification: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Using anything directly in $HOME should be avoided.

[flying-sheep]

yes, of course! XDG is important.

[flying-sheep]

so how do color themes work?

• $XDG_CONFIG_HOME/kdeglobals has the individual colors, as well as the ColorScheme key. is one of those simply a remnant of KDE4 times or are both actively maintained by KDE?
• how to subscribe to updates? A: like ColorSchemeFilter!
• how to trigger updates in GTK applications?

/edit: i found out how to trigger updates at least: qApp->setProperty("KDE_COLOR_SCHEME_PATH", action->data())

[ghost]

@flying-sheep Using the SVGs directly in GTK 3 has had performance and image quality problems in the past for whatever reason. Even upstream Adwaita has used bitmaps for each separate DPI level. Thanks for listing off some alternative renderers, I'll check them out.

@shmerl Good point, I'll keep that in mind.

[ghost]

By the way, we're always up for any assistance if you guys are interested in working on the theme, but there are a couple roadblocks at the moment.

We've gotta' merge the latest changes into KDE proper (hopefully focusing on development there and leaving this as a mirror), then we have to refactor the SCSS into a more logical structure, followed by a 3.20 port and then finally re-implement the color-effects support.

Unfortunately, I personally have almost no time to work on the theme aside from explaining the plan in issue reports. :P I really do wish I could dedicate more effort into tweaking and finishing it up, but I'll lend any assistance I can if you want to get involved.

[xenithorb]

Any updates to this? I noticed the new named-colors branch when I went to pull updates....

[xenithorb]

FWIW - I tried the new branch and figured out what you're doing. Nice idea.

Now, I tested it with Breeze.colors, and BreezeDark.colors (from F24 current), and it worked great!

Unfortunately, I tested it with WontonSoup.colors - that is, the one I actually use, and it errored out with the following backtrace:

Traceback (most recent call last):
  File "apply-gtk-colors.py", line 701, in <module>
    border_color            = Color(kde_globals,'WindowBackgroundNormal','WindowForegroundNormal', 0.75)
  File "apply-gtk-colors.py", line 24, in __init__
    self.dis = self._color_effect(self._intensity_effect(self.rgb,'Disabled'),'Disabled')
  File "apply-gtk-colors.py", line 82, in _color_effect
    effect_color = self.colordict[state + 'Color']
KeyError: 'DisabledColor'

(Granted I understand fully that I'm messing with undocumented and unreleased features, I'm just playing around and hopefully contributing a valid test back)

[xenithorb]

The problem appears to be that WontonSoup.colors is missing certain settings that the python script is assuming will be there. It's likely that the absence of these settings means that it reverts that setting to defaults? Thus the script will probably want to pad a default setting in when it is not used, or not error out on missing settings

[xenithorb]

Here's the file so you don't have to go looking for it:

WontonSoup.colors.txt

[dirruk1]

How exactly did you run it? This happens because not all color files have all colors in it. The way it's meant to be used is to move the Breeze folder to /usr/share/themes and then run the apply-gtk-colors.py script. It will then read the colors from .config/kdeglobals wich has all colors in it.

[xenithorb]

So I have had this project in ~/.themes for a while. I simply checked out the new branch, then copied over WontonSoup.colors (mimicing where Breeze.colors is) and then changed the bash script to point to WontonSoup.colors. I then ran the bash script.

[dirruk1]

Okay, thanks for your feedback. The bash script is only used to build the base theme. The idea is to have the default base theme in /usr/share/themes/ so it's used systemwide. The apply-gtk-colors script reads the colors from kdeglobals and creates the theme with the users colors in ~/.themes. This still needs to be fixed though, so I will try to get some defaults in there. Thank's for testing

[shmerl]

I didn't even realize one is supposed to run some scripts to enable the theme colors. Until now, I simply put themes from git in $HOME/.local/share/themes and that's it (it's better there than in $HOME/.themes, more XDG compliant) since the front page says:

To install only for the current user, copy the files to "~/.themes".

I also use Wonton Soup and noticed that GTK colors aren't really consistent.

[xenithorb]

I understand now, the intention is not to read WontonSoup.colors but rather kdeglobals after the fact that WontonSoup.colors has been applied as a color scheme. Makes sense. I figured out what you were saying when I stepped through the program an realized it was exchanging the value of color_file for what was specified with -i

[xenithorb]

Oh wow that works great! In the end all I needed to do was

cd ~/.themes/gnome-breeze # this repo
bash build_theme.sh
ln -s gnome-breeze/Breeze ../
python apply-gtk-colors.py -f -o .

[shmerl]

@xenithorb: I'm trying to reproduce it fixing the path to $HOME/.local/share/themes. What package did you use for sass?

[shmerl]

OK, I installed ruby-sass and get this when running the script:

Error: wrong number of arguments (10 for 3) for `rgb'
        on line 47 of _global.scss
        from line 1 of gtk316/gtk.scss
  Use --trace for backtrace.
Error: wrong number of arguments (10 for 3) for `rgb'
        on line 47 of _global.scss
        from line 1 of gtk318/gtk.scss
  Use --trace for backtrace.
Error: wrong number of arguments (10 for 3) for `rgb'
        on line 47 of _global.scss
        from line 1 of gtk320/gtk.scss
  Use --trace for backtrace.

[xenithorb]

rubygem-sass-3.4.22-1.fc24.noarch which brought in some stuff, but namely... rubygems-2.5.1-56.fc24.noarch

On Fedora 24

[xenithorb]

Wonton Soup pavucontrol to prove I'm not full of it

[dirruk1]

@schmerl, we were talking about this branch.

[shmerl]

Ah, sorry for confusion. Let me try that one.

[shmerl]

Using that branch, things looks better now. Script worked out of the box. Firefox and Geany have good colors with Wonton Soup (except Firefox navigation / bookmarks toolbar looks a bit too bright I think. "Remove background color" in Classic Theme Restorer makes toolbars look better). I suppose there is no Breeze Dark now, and only single Breeze theme, and just colors are adjusted according the the KDE color scheme?

I guess front page instructions should mention all that for the local installation (once it will be merged I suppose)?

[dirruk1]

We will put up instructions once this is ready, but this is still very much in an experimental stage

[xenithorb]

I noticed that it only works for GTK 3.20

I did not have good results with GTK 3.18 on Fedora 23, tried using one of the commented lines referencing 3.18, but it ultimately wouldn't build. (even after changing some paths and trying to understand what it was doing)

That's ok though, I'm just glad (really, really glad) there's progress, and am excited for F24's release so I can use it on my workstation.

[schmerl]

I'm not sure why I am in this thread. Are you sending it to the right address?

On Fri, Jun 17, 2016 at 5:46 PM Mike Goodwin notifications@github.com wrote:

I noticed that it only works for GTK 3.20

I did not have good results with GTK 3.18 on Fedora 23, tried using one of the commented lines referencing 3.18, but it ultimately wouldn't build. (even after changing some paths and trying to understand what it was doing)

That's ok though, I'm just glad (really, really glad) there's progress, and am excited for F24's release so I can use it on my workstation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dirruk1/gnome-breeze/issues/8#issuecomment-226889276, or mute the thread https://github.com/notifications/unsubscribe/AD9_AJ1xhV7KyGvSZFnZ3H4yCfJfoIRhks5qMxW9gaJpZM4E562U .

[dirruk1]

Yes, it's currently 3.20 only, but I'm working on 3.18. Should be out soon

[Martchus]

@schmerl I guess it was a typo.

@dirruk1 Some instructions would be nice if the script is finished. I suppose it is better to wait till then before including the script in the gnome-breeze-git Arch Linux package.

[dirruk1]

@Martchus, yeah this is really in an early stage. I'll give you a head's up before I merge

[ghost]

Of course, by the time the script is integrated in upstream KDE we'll be running it automatically every time colors are changed in the Colors KCM. We're hoping to make this conditional upon 'Apply colors to non-Qt applications' being checked when a theme named 'Breeze-gtk' is in use.

[shmerl]

I used this (from named colors branch):

./breeze-gtk-colors -i color-schemes/WontonSoup.colors -f -o $HOME/.local/share/themes

It generated assets / theme, but result looks very messed up for me in latest Firefox beta. I reverted back to master Breeze-dark-gtk. Did anyone encounter this?