Theme doesn't honor color scheme about gnome-breeze HOT 60 OPEN

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 .

from gnome-breeze.

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.

from gnome-breeze.

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.

from gnome-breeze.

Awesome!

from gnome-breeze.

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

from gnome-breeze.

@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.

from gnome-breeze.

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 :'(

from gnome-breeze.

@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.

from gnome-breeze.

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.

from gnome-breeze.

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.

from gnome-breeze.

@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.

from gnome-breeze.

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:

from gnome-breeze.

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.

from gnome-breeze.

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.

from gnome-breeze.

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

from gnome-breeze.

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

from gnome-breeze.

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?)

from gnome-breeze.

@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.

from gnome-breeze.

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

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

from gnome-breeze.

@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.

from gnome-breeze.

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, …

from gnome-breeze.

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.

from gnome-breeze.

yes, of course! XDG is important.

from gnome-breeze.

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())

from gnome-breeze.

@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.

from gnome-breeze.

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.

from gnome-breeze.

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

from gnome-breeze.

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)

from gnome-breeze.

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

from gnome-breeze.

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

WontonSoup.colors.txt

from gnome-breeze.

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.

from gnome-breeze.

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.

from gnome-breeze.

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

from gnome-breeze.

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.

from gnome-breeze.

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

from gnome-breeze.

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

from gnome-breeze.

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.

from gnome-breeze.

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

from gnome-breeze.

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

from gnome-breeze.

@schmerl, we were talking about this branch.

from gnome-breeze.

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

from gnome-breeze.

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)?

from gnome-breeze.

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

from gnome-breeze.

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.

from gnome-breeze.

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 [email protected]
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
#8 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AD9_AJ1xhV7KyGvSZFnZ3H4yCfJfoIRhks5qMxW9gaJpZM4E562U
.

from gnome-breeze.

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

from gnome-breeze.

@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.

from gnome-breeze.

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

from gnome-breeze.

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.

from gnome-breeze.

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?

from gnome-breeze.

Try following what I wrote here: #8 (comment)

I didn't need to specify the .colors file, after picking the right colors for your KDE environment, it uses that merged colors file to generate. Remember that the context of this is so that it can be run every time someone selects a new color scheme.

from gnome-breeze.

There is no more build_theme.sh, and default produces same result actually. I just specified explicit color file to be sure.

Also, your method makes a symlink, but repo contains 3.20 in addition to 3.0. And running the script regenerates only 3.0 theme, so just symlinking can cause confusion. I just deploy it explicitly, and it places gtk-3.0 in the theme dir.

from gnome-breeze.

@shmerl well since this is git, i can tell you that f10b6f3 works as I described still. You can always check that out and go about your day unless you're just testing around

from gnome-breeze.

Well, yes, I can revert to older revision. I was more interested in whether the latest code in the branch is broken for others too, or I'm doing something wrong.

from gnome-breeze.

Yes, that's the revision which works for me (just tested it): f10b6f3

The next one: 432fae4 introduced a regression already.

from gnome-breeze.

@shmerl I've been on a holiday, I won't have much time this week. I will look into it next week.
@xenithorb I know you probably mean well but suggesting someone should revert back to stable versions when he is reporting about problems is not a good thing. Reporting bugs is the most important thing about testing. Bug reports are realy important thing when it comes to fixing problems

from gnome-breeze.

I felt slightly responsible for announcing (on this ticket, in my excitement) that it was working at some point, thus I wanted to provide that commit because my local repo was still checked out to it (as I'm still using it). I didn't know if it was marked somewhere else as being a working commit hash, if it was tagged, etc.

from gnome-breeze.

Don't worry, I always appreciate everyone who is contributing. Just wanted to make sure @shmerl knows his bug reports are appreciated

from gnome-breeze.

hi. what’s the state?

the official version of this repo (https://quickgit.kde.org/?p=breeze-gtk.git) doesn’t have the scripts, only the data.

so is this repo still the upstream? and does someone still plan to autobuild the color theme adapted version?

from gnome-breeze.

The script breeze-gtk-color on most recent kdeglobals fails with:

Traceback (most recent call last):
  File "./breeze-gtk-colors", line 725, in <module>
    border_color            = Color(kde_globals,'WindowBackgroundNormal','WindowForegroundNormal', 0.75)
  File "./breeze-gtk-colors", line 26, in __init__
    self.dis = self._color_effect(self._intensity_effect(self.rgb,'Disabled'),'Disabled')
  File "./breeze-gtk-colors", line 71, in _intensity_effect
    amount = float(self.colordict[state + 'IntensityAmount'])
ValueError: could not convert string to float:

and later

Traceback (most recent call last):
  File "./breeze-gtk-colors", line 725, in <module>
    border_color            = Color(kde_globals,'WindowBackgroundNormal','WindowForegroundNormal', 0.75)
  File "./breeze-gtk-colors", line 26, in __init__
    self.dis = self._color_effect(self._intensity_effect(self.rgb,'Disabled'),'Disabled')
  File "./breeze-gtk-colors", line 71, in _intensity_effect
    amount = float(self.colordict[state + 'IntensityAmount'])
ValueError: could not convert string to float:

and later

Traceback (most recent call last):
  File "./breeze-gtk-colors", line 725, in <module>
    border_color            = Color(kde_globals,'WindowBackgroundNormal','WindowForegroundNormal', 0.75)
  File "./breeze-gtk-colors", line 26, in __init__
    self.dis = self._color_effect(self._intensity_effect(self.rgb,'Disabled'),'Disabled')
  File "./breeze-gtk-colors", line 86, in _color_effect
    effect = int(self.colordict[state + 'ColorEffect'])
ValueError: invalid literal for int() with base 10: ''

This is due to the following in kdeglobals

[ColorEffects:Disabled]
Color=
ColorAmount=
ColorEffect=
ContrastAmount=
ContrastEffect=
IntensityAmount=
IntensityEffect=

If you set them all to 0 the script works again.

from gnome-breeze.