Update for gtk-3.20 compatibility

[magnific0]

I have started updating this theme to make it compatible with gtk version 3.20.

This contribution is far from complete. However, it is far more workable than previously.

Perhaps this can be merged into a working branch. Alternatively, others can contribute by authoring requests to my gtk320 branch. I'll accept any such requests blindly, such that the discussion can remain here.

I am absolutely not capable of finishing this project as my knowledge of theming and css is rather limited. I hope the start I have provided gives other an incentive to continue this effort.

[ghost]

Nice- thank you for the effort to start bringing it into shape. I think we may want to keep the 3.18 and lower theme in its own directory for the time being instead of scrapping it since some distros may continue to ship GTK 3.18 when the next Plasma release is out.

It's a good start, though, so I'll see what I can do about merging it into a new branch this weekend.

[magnific0]

@scionicspectre, that would be amazing.

In the mean time, I have made several additional targeted fixes, including the scroll bars and text selection highlighting. At this point the usability of the theme has been restored (for me) and I won't be able to spend much more time on it.

[ghost]

No worries, and thanks again for the contribution.

[flying-sheep]

want nao :stuck_out_tongue_winking_eye:

until then i found a PKGBUILD for arch users.

[ghost]

@Martchus Thanks. I've been crazily busy as always, so it's good people are willing to step up and help out. :)

[Martchus]

I've provided the mentioned PKGBUILD. But it is just a workaround, till the changes are merged here.

@magnific0: Thanks for the contribution. It still has some glitches, but the overall impression is good. Very annoying that GTK breaks its API all the time.

[flying-sheep]

thanks @Martchus!

and everybody involved, for that matter!

[ghost]

Thanks Martchus (changed my comment to reflect your contribution). The nice thing is that this will be the last time the theming API breaks in practical terms. In fact, it was broken in order to bring internal consistency for all future GTK 3 versions, so I should be grateful as soon as I can tackle it.

[flying-sheep]

is it really necessary to have separate branches? the last commit was in november, so the update frequency doesn’t seem high enough that two branches need to be maintained parallelly. gnome 3.18 users can just continue to use the last 3.18-compatible release, right?

[magnific0]

Who said we needed two branches.

Next to all the git tools we have for seperating two versions (branches & tags), gtk also allows to superate versions in different folders. I suggest this is the way to go.

[flying-sheep]

ooh, that’s cool

[ghost]

@flying-sheep I fully intend to merge my remaining local patches to the 3.18 version and put them in separate directories when we move entirely to 3.20+. There's only a separate branch for now because I'm a busy dude and no one else is available to do this at the moment. :\

If anyone is motivated to take on the port I will fully support their efforts.

[magnific0]

Hi all, I fixed two more GUI elements, I think we should merge this theme in a gtk-3.20 folder, like this project has: https://github.com/shimmerproject/Numix

If you want I can update the pull request with the updated folder name.

[ghost]

@magnific0 Will do, once I've applied a couple final patches to the 3.18 theme and placed it into its own folder. We need to keep the pre-existing theme since some distros will ship with older versions of GTK when the next Plasma release comes out (and the theme works decently well with 3.16 in the worst case). As such, we should probably hold off on the updated folder name until we've done that.

[ghost]

I renamed the folders and merged your initial patch, @magnific0 . This should prevent us from stepping on any toes for the old theme. :)

[Psykar]

Shouldn't it be gtk-3.0 and gtk-3.20 ? Currently with gtk-3.18 and gtk-3.20 won't anyone on pre 3.18 not get a gtk3 theme at all?

[ghost]

@Psykar The only other version the 3.18 theme works with is 3.16, so I'm not certain it's necessary. The big issue here is that, if we leave it as gtk-3.0, that will be the folder GTK 3.22 looks for if we haven't renamed anything by then.

If anything, I would think the 3.20+ theme should be in gtk-3.0 and a 3.16 and 3.18 folder should exist separately. But of course, that's duplication with little gain, so your idea is better in the short-term. I'll ask around to see what makes most sense, as theme artists take different approaches.

[Psykar]

My issue as it stands is Cinnamon doesn't recognize there being a gtk3 theme at all for it's selector (but that's possibly a Cinnamon problem, not yours)

Thanks for the work both of you, much more usable now :)

[ghost]

@Psykar Are you using the latest stable version of Cinnamon? Unfortunately, we often have to create workarounds for other people (Chrome, Firefox, LibreOffice), so we could probably keep Cinnamon in mind as well. Then again, the theme is primarily meant for KDE Plasma, which is why it doesn't have rounded borders or anything like that for people who disable CSDs.

[Psykar]

@scionicspectre I do have latest Cinnamon (using ArchLinux)

It's definitely due to the 3.0 vs 3.18 issue, currently I can see breeze-gtk but not breeze-dark-gtk, as the dark one doesn't have a 3.0 folder:

 $ diff  /usr/share/themes/Breeze-dark-gtk/ /usr/share/themes/Breeze-gtk                                                                                                               
Common subdirectories: /usr/share/themes/Breeze-dark-gtk/gtk-2.0 and /usr/share/themes/Breeze-gtk/gtk-2.0
Only in /usr/share/themes/Breeze-gtk: gtk-3.0
Common subdirectories: /usr/share/themes/Breeze-dark-gtk/gtk-3.18 and /usr/share/themes/Breeze-gtk/gtk-3.18
Common subdirectories: /usr/share/themes/Breeze-dark-gtk/gtk-3.20 and /usr/share/themes/Breeze-gtk/gtk-3.20

(edit - I made the 3.0 folder by copying the 3.18 folder as a test)

[ghost]

I see. Vertex still appears, probably because it places its individual release folders within the gtk-3.0 directory, which I suppose causes applications to double-check. That might actually be the ideal way to go if it doesn't force us into a weird situation with GTK 3.16 or GTK 3.22.

[Psykar]

@scionicspectre Not actually - they have a compilation process which produces a single gtk-3.0 folder based on the version of gtk you have installed, so somewhat different to what you've got here unfortunately.

The advantage for them is it allows them to have a common directory with things the same across gtk versions, and only patches for each minor version.

[ghost]

@Psykar Ah, good catch. Yeah, I'm afraid that approach might not work for us, but we'll be dynamically generating the theme some day (in order to support KDE color schemes) so the source's naming convention won't matter much at that point.

[flying-sheep]

that day might be sooner than you think since i’d like to work on it

(but don’t anyone bet on it, i tend to forget about side projects)

[Martchus]

@Psykar: The following PKGBUILD allows me to select both variants of the theme under Arch/Cinnamon: https://github.com/Martchus/PKGBUILDs/blob/master/gnome-breeze/git/PKGBUILD

[ghost]

@flying-sheep Before we learned of the changes in GTK from 3.20 onward, we still had quite a bit of polishing to do on the base theme, and now we have another little mountain of work until the 3.20 theme is in shape. We need to get the base theme correct so we can break it out into a dynamically generated theme in a straightforward manner.

As such, color scheme support will have to wait at least until we make the SCSS more modular- otherwise we'd be concurrently editing two code bases and merely hoping to keep them in sync. Once the theme itself is stable we should be able to tackle that, and maybe someday even make the entire theme dynamic by default rather than having one static and one generated.

I can't stop you from looking at the old color-effects branch for ideas on how to do this, but I can guarantee it will need to be modified extensively in the future if you do it now. I don't mean to discourage anyone, but it would be sad to see someone get burnt out on color scheme support that can't be used without refactoring.