eudaimon
/
pho-earth-adaptive
4
3
Fork 2
Code Issues Pull Requests 2 Projects Releases Wiki Activity

Fix for arbitrary defaulting behavior #2

Open
ratsrats wants to merge 22 commits from ratsrats/pho-earth-adaptive:master into master
pull from: ratsrats/pho-earth-adaptive:master
merge into: eudaimon:master
Conversation 10 Commits 22 Files Changed 4 +20 -19
ratsrats commented 2021-12-27 13:51:35 +01:00
First-time contributor
Copy Link

I made a fix that restores the theme's adaptive behavior so that the theme won't disregard Plasma color settings. The adaptive behavior has to be enabled via change_theme.sh. There is a chance that the fix may break the GTK4 version as I don't have a GTK4 environment to test on.

I made a fix that restores the theme's adaptive behavior so that the theme won't disregard Plasma color settings. The adaptive behavior has to be enabled via change_theme.sh. There is a chance that the fix may break the GTK4 version as I don't have a GTK4 environment to test on.
ratsrats added 2 commits 2021-12-27 13:51:36 +01:00
0a2ccec2b9 Added option to script for reconfiguring theme to follow Plasma color scheme 
Added option to script for reconfiguring theme to follow Plasma color scheme. Passing "plasma" as file name will replace the default common.css with an edited version tailored to accept colors provided by Plasma
a8fa444833 Added adaptive common CSS file 
Added adaptive and regular common CSS files as resources for use by change_theme.sh. Rather clunky, I know.
ratsrats added 1 commit 2021-12-29 13:43:16 +01:00
ratsrats commented 2021-12-29 13:47:21 +01:00
Author
First-time contributor
Copy Link

I fixed the GTK4 version of the theme so as to not look broken.

I fixed the GTK4 version of the theme so as to not look broken.
eudaimon commented 2022-01-01 15:57:40 +01:00
Owner
Copy Link

Hi, I'm not sure if this pull request is already finished or still a WIP (in which case I won't merge it until it is ready).
I'm not sure about the nature of the changes you are requesting here: I see you've created 2 common.css files, and one of them (the one copied when you indicate 'plasma' on change_theme.sh) that should catch plasma's theme. I don't quite get how does this second css catch it, could you please elaborate on this? Thank you 🙏
Also, I don't think it's a good idea to maintain two css: that's the reason why I created the common.css (instead of always having to modify both gtk4 and gtk3 css separately), it is easy to forget to alter both files the same way when a change affects both.
Anyway, I'd like to thank you for wanting to improve this theme

Hi, I'm not sure if this pull request is already finished or still a WIP (in which case I won't merge it until it is ready). I'm not sure about the nature of the changes you are requesting here: I see you've created 2 common.css files, and one of them (the one copied when you indicate 'plasma' on change_theme.sh) that should catch plasma's theme. I don't quite get how does this second css catch it, could you please elaborate on this? Thank you 🙏 Also, I don't think it's a good idea to maintain two css: that's the reason why I created the common.css (instead of always having to modify both gtk4 and gtk3 css separately), it is easy to forget to alter both files the same way when a change affects both. Anyway, I'd like to thank you for wanting to improve this theme
ratsrats commented 2022-01-01 17:07:17 +01:00
Author
First-time contributor
Copy Link

The adaptive style sheet has all color variables replaced with the ones specified in colors.css. These variables appear to be globally exported as the trick seems to work without importing colors.css. The reason for the second common.css for the GTK4 version is that KDE's theme color overrides are inaccessible to GTK4 due to it being not supported by the Plasma GTK theme configuration module. I'll try putting a symlink to the colors.css file in the color scheme folder to see if the GTK4 version will accept Plasma colors that way, but that would require a considerable amount of preparation on my part as I can't seem to set up a GTK4 environment on my system without breaking either the theme or my applications.

The adaptive style sheet has all color variables replaced with the ones specified in colors.css. These variables appear to be globally exported as the trick seems to work without importing colors.css. The reason for the second common.css for the GTK4 version is that KDE's theme color overrides are inaccessible to GTK4 due to it being not supported by the Plasma GTK theme configuration module. I'll try putting a symlink to the colors.css file in the color scheme folder to see if the GTK4 version will accept Plasma colors that way, but that would require a considerable amount of preparation on my part as I can't seem to set up a GTK4 environment on my system without breaking either the theme or my applications.
ratsrats added 1 commit 2022-01-01 17:49:35 +01:00
ratsrats added 1 commit 2022-01-01 18:47:51 +01:00
cb48a9eb29 Rewrote adaptive mode 
Moved the adaptivity function into a color scheme
ratsrats added 1 commit 2022-01-01 18:48:33 +01:00
3029a83761 Rewrote adaptive mode 
Moved the adaptivity function to a color scheme
ratsrats added 1 commit 2022-01-01 18:49:41 +01:00
ratsrats added 1 commit 2022-01-01 18:50:04 +01:00
ratsrats added 1 commit 2022-01-01 18:51:50 +01:00
a0ca8cfea1 Rewrote adaptive mode 
Moved the adaptivity functions to a color scheme
ratsrats added 1 commit 2022-01-01 18:54:03 +01:00
ratsrats added 1 commit 2022-01-01 18:59:27 +01:00
961787470f Rewrote adaptive mode 
Moved the adaptivity functions to a color scheme, eliminating the need for custom common stylesheets.
ratsrats added 1 commit 2022-01-01 19:07:20 +01:00
ratsrats added 1 commit 2022-01-01 19:08:13 +01:00
94b837cb7e Rewrote adaptive mode 
Moved the adaptivity functions to a color scheme, eliminating the need for custom common stylesheets.
ratsrats commented 2022-01-01 19:18:57 +01:00
Author
First-time contributor
Copy Link

I reworked the adaptivity fix so that it doesn't require hacked common files.

I reworked the adaptivity fix so that it doesn't require hacked common files.
ratsrats changed title from WIP: Fix for arbitrary defaulting behavior to Fix for arbitrary defaulting behavior 2022-01-01 19:19:00 +01:00
ratsrats added 1 commit 2022-01-01 20:51:01 +01:00
bd483ae952 Added workaround for GTK4 version 
Added a workaround that enables adaptive behavior for the GTK4 version
ratsrats added 1 commit 2022-01-01 20:51:40 +01:00
ratsrats added 1 commit 2022-01-01 20:57:19 +01:00
9f87248a28 Added GTK4 preview 
Added preview demonstrating the adaptivity feature on GTK4 version
Color scheme is ArcDusk-dark by yeyushengfan258
ratsrats commented 2022-01-01 21:06:42 +01:00
Author
First-time contributor
Copy Link

I know it's irrelevant to the main issue but the symlink solution turned out to be working for the GTK4 version.

I know it's irrelevant to the main issue but the symlink solution turned out to be working for the GTK4 version. ![](https://git.disroot.org/ratsrats/pho-earth-adaptive/raw/branch/master/previews/adaptivegtk4.png)
eudaimon commented 2022-01-16 13:53:05 +01:00
Owner
Copy Link

Hi ratsrats,

thank you again. I like what you've com up with (linking Plasma's HOME/.config/gtk-3.0/colors.css to this theme's color_themes folder. That certainly allows to solve the fact that GTK4 engine ignores the file $HOME/.config/gtk-4.0/colors.css (which Plasma does put there). Plasma puts exactly the same content in $HOME/.config/gtk-3.0/colors.css and $HOME/.config/gtk-4.0/colors.css.
However I see something strange: your color_themes/adaptive.css thinks Plasma's colors have a name without the _breeze suffix. For example, you have:

@define-color window_fg @theme_fg_color;

But if I look at my HOME/.config/gtk-3.0/colors.css, Plasma defines this color:

@define-color theme_fg_color_breeze #e0dedb;

That is: Plasma adds this suffix so it will only affect (theoretically) their GTK3 Breeze theme. So your entries for color_themes/adaptive.css won't actually get current Plasma's colors. Plasma didn't use this suffix until some time ago, maybe you're working with an older Plasma version? Since I am working with a rolling distro, I always have the latest releases (of plasma, GTK, etc.)

Also your PR has an error for file gtk-4.0/gtk.css: it is OK already, your change breaks it (the directory is gtk-common, not gkt_common).

Now I was wandering what is best for this theme as a default behavior. I say this because I think most people won't try to execute the script to configure it. Different alternatives I see:

  1. Already include a symlink to $HOME/.config/gtk-3.0/colors.css, and import colors from there (with the _breeze suffix). This will make both GTK3 and GTK4 apps use Plasma's colors. These colors need to be imported on top of this pho-earth-adaptive's current color theme, in order to overwrite them. The ugliness of this solution is that if $HOME/.config/gtk-3.0/colors.css does not exist (for a person that does noy use Plasma but wants to use this theme anyway), I guess each GTK app will issue a warning (only visible if you load the app via terminal, usually).
  2. Current behaviour: there is no link to $HOME/.config/gtk-3.0/colors.css. GTK3 apps get current Plasma scheme because they honor $HOME/.config/gtk-3.0/colors.css, if it exists, because gtk-common\common.css overwrites current theme with Plasma's _breeze color definitions. But GTK4 themes don't, as I said. People who don't use Plasma don't get any error, and see pho-earth-adaptive's current color theme. The script allows to create the link and use this color_themes/adaptive.css so then on both GTK3 and GTK4 apps use Plasma's colors (this is what you PR adds).

I'm starting to think the first one is the best, despite the warning issued to non-Plasma users. But it has a problem for an edge case: users who may have many installed DEs, including Plasma, but are currently not using Plasma. If this is the case, they might want this theme to kind of "force" using one of its own color themes and not honor $HOME/.config/gtk-3.0/colors.css. But for this case, I'd suppose these users are advanced, and wouldn't mind executing the script, that would offer the possibility of not overwriting current theme with Plasma's colors.

So I guess this will be my next move:

  • create a .css which first imports current theme and then overwrites it with Plasma's (which is more or less what gtk-common\common.css does at the beginning, after importing theme_colors.css)
  • create a .css which only imports current theme
  • create a symlink (called for example import_theme.css) which points to either of previous css, so all use cases can be covered
  • create a symlink to $HOME/.config/gtk-3.0/colors.css
  • modify the change_theme.sh script so it can handle all these options.
  • set up the theme so default behaviour is number 1.

I'd say that with these changes, it will have the advantage of you proposal, and also improving code clarity. I'll try to work with branches too, my git experience is still very small.

So, again, many thanks for your contributions!

Hi ratsrats, thank you again. I like what you've com up with (linking Plasma's `HOME/.config/gtk-3.0/colors.css` to this theme's color_themes folder. That certainly allows to solve the fact that GTK4 engine ignores the file `$HOME/.config/gtk-4.0/colors.css` (which Plasma does put there). Plasma puts exactly the same content in `$HOME/.config/gtk-3.0/colors.css` and `$HOME/.config/gtk-4.0/colors.css`. However I see something strange: your `color_themes/adaptive.css` thinks Plasma's colors have a name without the \_breeze suffix. For example, you have: ```css @define-color window_fg @theme_fg_color; ``` But if I look at my `HOME/.config/gtk-3.0/colors.css`, Plasma defines this color: ```css @define-color theme_fg_color_breeze #e0dedb; ``` That is: Plasma adds this suffix so it will only affect (theoretically) their GTK3 Breeze theme. So your entries for `color_themes/adaptive.css` won't actually get current Plasma's colors. Plasma didn't use this suffix until some time ago, maybe you're working with an older Plasma version? Since I am working with a rolling distro, I always have the latest releases (of plasma, GTK, etc.) Also your PR has an error for file `gtk-4.0/gtk.css`: it is OK already, your change breaks it (the directory is `gtk-common`, not `gkt_common`). Now I was wandering what is best for this theme as a default behavior. I say this because I think most people won't try to execute the script to configure it. Different alternatives I see: 1. Already include a symlink to `$HOME/.config/gtk-3.0/colors.css`, and import colors from there (with the \_breeze suffix). This will make both GTK3 and GTK4 apps use Plasma's colors. These colors need to be imported on top of this pho-earth-adaptive's current color theme, in order to overwrite them. The ugliness of this solution is that if `$HOME/.config/gtk-3.0/colors.css` does not exist (for a person that does noy use Plasma but wants to use this theme anyway), I guess each GTK app will issue a warning (only visible if you load the app via terminal, usually). 2. Current behaviour: there is no link to `$HOME/.config/gtk-3.0/colors.css`. GTK3 apps get current Plasma scheme because they honor `$HOME/.config/gtk-3.0/colors.css`, if it exists, because `gtk-common\common.css` overwrites current theme with Plasma's \_breeze color definitions. But GTK4 themes don't, as I said. People who don't use Plasma don't get any error, and see pho-earth-adaptive's current color theme. The script allows to create the link and use this `color_themes/adaptive.css` so then on both GTK3 and GTK4 apps use Plasma's colors (this is what you PR adds). I'm starting to think the first one is the best, despite the warning issued to non-Plasma users. But it has a problem for an edge case: users who may have many installed DEs, including Plasma, but are currently not using Plasma. If this is the case, they might want this theme to kind of "force" using one of its own color themes and **not** honor `$HOME/.config/gtk-3.0/colors.css`. But for this case, I'd suppose these users are advanced, and wouldn't mind executing the script, that would offer the possibility of not overwriting current theme with Plasma's colors. So I guess this will be my next move: * create a .css which first imports current theme and then overwrites it with Plasma's (which is more or less what `gtk-common\common.css` does at the beginning, after importing `theme_colors.css`) * create a .css which only imports current theme * create a symlink (called for example import_theme.css) which points to either of previous css, so all use cases can be covered * create a symlink to `$HOME/.config/gtk-3.0/colors.css` * modify the `change_theme.sh` script so it can handle all these options. * set up the theme so default behaviour is number 1. I'd say that with these changes, it will have the advantage of you proposal, and also improving code clarity. I'll try to work with branches too, my git experience is still very small. So, again, many thanks for your contributions!
ratsrats commented 2022-01-17 10:51:35 +01:00
Author
First-time contributor
Copy Link

May I ask what version of KDE Plasma are you using and on what distribution? Without modifications the theme is broken on both of my Plasma instances (5.18.6 on openSUSE Leap 15.3 and 5.23 on Pisi Linux 2.2). The 5.18.6 one doesn't use the _breeze suffix yet, although the fallback behavior gets triggered even on my 5.23. Maybe unlinking common.css from the main CSS will restore the adaptive behavior on more recent KDE versions, but I have no means of testing my solution as of now because I have no clue about how sed works and I have a suspicion that my Pisi Linux box could catch fire at any moment.
Also, as of my latest commit, gtk4/gtk.css doesn't have that typo anymore.

May I ask what version of KDE Plasma are you using and on what distribution? Without modifications the theme is broken on both of my Plasma instances (5.18.6 on openSUSE Leap 15.3 and 5.23 on Pisi Linux 2.2). The 5.18.6 one doesn't use the _breeze suffix yet, although the fallback behavior gets triggered even on my 5.23. Maybe unlinking common.css from the main CSS will restore the adaptive behavior on more recent KDE versions, but I have no means of testing my solution as of now because I have no clue about how sed works and I have a suspicion that my Pisi Linux box could catch fire at any moment. Also, as of my latest commit, gtk4/gtk.css doesn't have that typo anymore.
ratsrats added 1 commit 2022-01-17 10:55:39 +01:00
eudaimon commented 2022-02-05 17:29:51 +01:00
Owner
Copy Link

Hi,

I've merged the plasma-rework branch onto main. I've done the following changes:

  • by default this theme does not follow current Plasma color scheme
  • I've created a script that lets you toggle this behaviour
  • When activated, both GTK3 and GTK4 follow current Plasma color scheme

I've decided to go this way to ensure that the theme will always work by default regardless of the user having Plasma installed or not. I haven't been able to use any trick so that GTK is not broken in case Plasma is not installed (that is, ~/.config/gtk-3.0/colors.css does not exist) but at the same time GTK3 and 4 behave properly if it is.

The idea was to make this theme behave "cleanly": either both GTK3 and 4 follow Plasma or both don't.

Now what's missing is GTK2 following either current color theme (I mean, from the predefined ones) or current Plasma theme. I can only think of doing this via a script, that can be called each time current color theme is changed, but it would also need to be called each time Plasma color scheme is modified (this is would need to be done manually, or, maybe via some sort of chron job at each login or something). The script would have to edit gtk-2.0/gtkrc file to alter its colors, maybe editing it from a template using sed.

I guess, then, that you PR is not needed anymore. And thanks again for your contribution and ideas.

Hi, I've merged the plasma-rework branch onto main. I've done the following changes: - by default this theme **does not** follow current Plasma color scheme - I've created a script that lets you toggle this behaviour - When activated, both GTK3 and GTK4 follow current Plasma color scheme I've decided to go this way to ensure that the theme will always work by default regardless of the user having Plasma installed or not. I haven't been able to use any trick so that GTK is not broken in case Plasma is not installed (that is, ~/.config/gtk-3.0/colors.css does not exist) but at the same time GTK3 and 4 behave properly if it is. The idea was to make this theme behave "cleanly": either both GTK3 and 4 follow Plasma or both don't. Now what's missing is GTK2 following either current color theme (I mean, from the predefined ones) or current Plasma theme. I can only think of doing this via a script, that can be called each time current color theme is changed, but it would also need to be called each time Plasma color scheme is modified (this is would need to be done manually, or, maybe via some sort of chron job at each login or something). The script would have to edit `gtk-2.0/gtkrc` file to alter its colors, maybe editing it from a template using sed. I guess, then, that you PR is not needed anymore. And thanks again for your contribution and ideas.
ratsrats added 1 commit 2022-02-06 12:10:56 +01:00
ratsrats added 1 commit 2022-02-06 14:44:52 +01:00
ratsrats added 1 commit 2022-02-06 14:47:36 +01:00
ratsrats added 1 commit 2022-02-06 15:00:52 +01:00
ratsrats added 1 commit 2022-02-06 15:02:38 +01:00
ratsrats commented 2022-02-06 15:22:12 +01:00
Author
First-time contributor
Copy Link

I rethought my approach to the "arbritrary fallback theme" issue and forced all upstream changes, with only the new adaptive color import being edited to work with older Plasma versions. I suggest that you pull in my fork as a new branch to provide <5.19 users with a version for their environments. As the current main version still uses _breeze color variables, its adaptive behavior will remain broken on anything older than 5.19.

I rethought my approach to the "arbritrary fallback theme" issue and forced all upstream changes, with only the new adaptive color import being edited to work with older Plasma versions. I suggest that you pull in my fork as a new branch to provide <5.19 users with a version for their environments. As the current main version still uses \_breeze color variables, its adaptive behavior will remain broken on anything older than 5.19.
eudaimon commented 2022-02-21 13:26:11 +01:00
Owner
Copy Link

OK, sorry for the delay: I'd say I've done it right: I've created a new branch (ratsrats-master) and there I've put your PR, so I'll close this one.
It's the first time I do such thing with git, since I have very little experience (and never in a professional environment), so if what I have done isn't what should have been, please tell me. I'll close this PR in a few days, if everything is fine.
Thanks again!

OK, sorry for the delay: I'd say I've done it right: I've created a new branch (ratsrats-master) and there I've put your PR, so I'll close this one. It's the first time I do such thing with git, since I have very little experience (and never in a professional environment), so if what I have done isn't what should have been, please tell me. I'll close this PR in a few days, if everything is fine. Thanks again!
This pull request has changes conflicting with the target branch.
  • imports/import_honor_plasma.css
You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.
git checkout -b ratsrats-master master
git pull master

Step 2:

Merge the changes and update on Forgejo.
git checkout master
git merge --no-ff ratsrats-master
git push origin master
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
invalid

Something is wrong

  
question

More information is needed

  
wontfix

This won't be fixed

No Label
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: eudaimon/pho-earth-adaptive#2
No description provided.
Delete Branch "ratsrats/pho-earth-adaptive:master"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?