OpenBar 2.0 theming apps

[NotMephisto]

How to reproduce it:

Config theme in Gradience
Enable GTK theming in OpenBar
Unable GTK theming

Distro: Fedora 40 Gnome 46.1

Possible problem occurrence:

1. The script returns an empty css file instead of creating css.bak and returning from them.
2. Something keeps resetting the css file so that the theme from Gradience can't be applied.

How I solved the problem:

Made a link to the css file from ~/.var/app/com.github.GradienceTeam.Gradience/config/gtk-3|4.0

[neuromorph]

Hello, Thank you for trying out!

Can you please elaborate on what exactly is the issue you are referring to? I am guessing the scenario as:

• You created a gtk css theme using Gradience
• You then enabled Gtk theming in OpenBar which takes backup of existing css (in ~/.config) and creates new gtk.css in ~/.config
• You disabled it OpenBar and the original gtk.css should be restored in ~/.config

Questions:

• Is there an existing gtk css in ~/.config/gtk4.0 or 3.0 before enabling in OpenBar?
• If so, was is not backed up?
• Is the back up not restored on disable?

I don't really have experience with Gradience, but it seems it will create its css in ~/.var path and not ~/.config? Except may be the custom css in Advanced tab. When I opened Gradience, it showed the OpenBar created gtk.css in the custom box under Advanced. When I made some change in gradience Colors tab and clicked on 'Apply' after the overwrite warning pop up, it did not create any css file in ~/.config or in ~/.var for me, so I am not sure of expected behavior.

Please help me understand the issue so I can fix it.

Note: make sure you have the latest code for 'openbar2.0' branch since this feature was added today.

Thanks.

[NotMephisto]

Hello, Thank you for trying out!

Can you please elaborate on what exactly is the issue you are referring to? I am guessing the scenario as:

* You created a gtk css theme using Gradience

* You then enabled Gtk theming in OpenBar which takes backup of existing css (in ~/.config) and creates new gtk.css in ~/.config

* You disabled it OpenBar and the original gtk.css should be restored in ~/.config

Questions:

* Is there an existing gtk css in ~/.config/gtk4.0 or 3.0 before enabling in OpenBar?

* If so, was is not backed up?

* Is the back up not restored on disable?

I don't really have experience with Gradience, but it seems it will create its css in ~/.var path and not ~/.config? Except may be the custom css in Advanced tab. When I opened Gradience, it showed the OpenBar created gtk.css in the custom box under Advanced. When I made some change in gradience Colors tab and clicked on 'Apply' after the overwrite warning pop up, it did not create any css file in ~/.config or in ~/.var for me, so I am not sure of expected behavior.

Please help me understand the issue so I can fix it.

Note: make sure you have the latest code for 'openbar2.0' branch since this feature was added today.

Thanks.

Yes, they were before. Since Gradience creates them after applying a theme, however, after enabling gtk theme change in OpenBar it stopped changing them itself as if something was preventing it from doing so. Also it keeps overwriting the file over time. This problem started after installing OpenBar 2.0 and enabling the gtk theme. Plus it broke flatpak app themes, can you tell me where it goes to change flatpak app themes?

I installed the extension 8-9 hours ago, but I saw that you changed it 6 hours ago. I'll try some more with it, but I don't think it will fix anything.

Video how it happens: https://github.com/neuromorph/openbar/assets/38382271/a0a937db-d4d6-406e-9583-953923c2e6d8

P.S.: After turn off applying the Gtk theme, it overwrites the gtk.css file, even though you change other settings, for example, accent color.

[neuromorph]

I installed the extension 8-9 hours ago, but I saw that you changed it 6 hours ago. I'll try some more with it, but I don't think it will fix anything.

I saw in video, that version does not support backups or restore. Please use latest version for your tests.

Plus it broke flatpak app themes, can you tell me where it goes to change flatpak app themes?

For flatpak, it adds an override to tell flatpak apps to use the same Gtk css theme from ~/.config/gtk4.0 and gtk3.0. If the option is disabled then it removes the override.

P.S.: After turn off applying the Gtk theme, it overwrites the gtk.css file, even though you change other settings, for example, accent color.

This should certainly Not happen if the Apply Gtk option is turned Off. Please check with latest version from Github.

On the Gradience part, I am still not sure what is a valid scenario. I will look your video more carefully to try and understand.

[NotMephisto]

After updating extension I haven't encountered this error anymore, however, flatpak apps don't apply themes from Gradience

[neuromorph]

After updating extension I haven't encountered this error anymore

Great news! I also looked more carefully into the video and realized that it shows the same issue that is resolved in that update.

flatpak apps don't apply themes from Gradience

Basically, themes are defined in Gtk3.0 (or Adw gtk3) and Gtk4.0. We can add overrides in Flatpak to access those Gtk themes. I had a look at Gradience and both Open Bar and Gradience seem to be doing the same thing i.e. add overrides. Open Bar has a single toggle for both Gtk3/Gtk4 while Gradience has two separate ones with some instructions (which seems better way to handle it maybe). In the end, I think, you maybe facing some clash. To allow themes from Gradience for Flatpak, I would suggest you keep the Flatpak option in Open Bar turned On (so that it does not remove overrides) and then also turn it On in Gradience. Let me know how it goes.

[NotMephisto]

Basically, themes are defined in Gtk3.0 (or Adw gtk3) and Gtk4.0. We can add overrides in Flatpak to access those Gtk themes. I had a look at Gradience and both Open Bar and Gradience seem to be doing the same thing i.e. add overrides. Open Bar has a single toggle for both Gtk3/Gtk4 while Gradience has two separate ones with some instructions (which seems better way to handle it maybe). In the end, I think, you maybe facing some clash. To allow themes from Gradience for Flatpak, I would suggest you keep the Flatpak option in Open Bar turned On (so that it does not remove overrides) and then also turn it On in Gradience. Let me know how it goes.

I found another bug, your overrides "overwrite" past changes with files incorrectly by adding ! to the beginning, which prohibits the use of gtk configs.

Video:

https://github.com/neuromorph/openbar/assets/38382271/bc14e4bd-5367-427d-af3d-e34216f738e5

[neuromorph]

Firstly, when you turn on 'Apply to Gtk Apps' in OpenBar, it will create a new gtk.css theme (and backup any old one). When that option is turned off, it will restore backup. While, turning on Flatpak, allows Flatpak apps access to any Gtk themes in config and turning off disallows access to config.

I found another bug, your overrides "overwrite" past changes with files incorrectly by adding ! to the beginning, which prohibits the use of gtk configs.

Now, about the current video, it is not a bug, this is how it is currently setup. These are global overrides that can be added/removed by Open Bar or Gradience or any other app. Open Bar provides (ro) read-only access to the themes since only that is really needed. Gradience does not add read only limit. It is not that critical though, both should be OK. Resetting is tricky. Blind reset will reset every override, including those for Firefox/Chrome etc. Open Bar uses the --nofilesystem option in Flatpak override, which adds the '!' to the beginning. This removes the Flatpak access to the Gtk configs (themes). Remember, you are turning off the override in Open Bar settings so the access is removed. If you want to still apply theme from Gradience, you need to go into Gradience preferences and turn On the Flatpak override for Gtk3 and Gtk4 there. Note - at least on my version, Gradience Flatpak switches have a bug where they show active (blue) color while turned off (white ball on left). You need to click it a couple times to properly turn it On. You can keep Flatseal open to see that an entry appears there when you turn on override from Gradience settings. After that, Flatseal will show, two entries from OpenBar with the '!' and other entries from Gradience without the '!' and themes from Gradience will be applied as expected.

Is there a better way to go about it? Well I am not sure right now, but maybe that is worth looking into. For now, please try it out this way. Whatever app (whether Gradience, OpenBar or something else) that you don't want to use the Flatpak override - go in their settings and turn it off. Then, whatever app you do want to use overrides - go into there settings and turn it on.

[NotMephisto]

Now, about the current video, it is not a bug, this is how it is currently setup. These are global overrides that can be added/removed by Open Bar or Gradience or any other app. Open Bar provides (ro) read-only access to the themes since only that is really needed. Gradience does not add read only limit. It is not that critical though, both should be OK. Resetting is tricky. Blind reset will reset every override, including those for Firefox/Chrome etc. Open Bar uses the --nofilesystem option in Flatpak override, which adds the '!' to the beginning. This removes the Flatpak access to the Gtk configs (themes). Remember, you are turning off the override in Open Bar settings so the access is removed. If you want to still apply theme from Gradience, you need to go into Gradience preferences and turn On the Flatpak override for Gtk3 and Gtk4 there.

Is there a better way to go about it? Well I am not sure right now, but maybe that is worth looking into. For now, please try it out this way. Whatever app (whether Gradience, OpenBar or something else) that you don't want to use the Flatpak override - go in their settings and turn it off. Then, whatever app you do want to use overrides - go into there settings and turn it on.

I think it's better to implement saving this before applying overrides, so that you don't have such problems. As you wrote above, it won't cause any problems if you just return everything as it was originally. You can do this by saving global file at /var/lib/flatpak/overrides as I suggested above with css files, create a new file with the same name and change it, then if the user doesn't need this function, just delete this file and restore the previous one!

Note - at least on my version, Gradience Flatpak switches have a bug where they show active (blue) color while turned off (white ball on left). You need to click it a couple times to properly turn it On. You can keep Flatseal open to see that an entry appears there when you turn on override from Gradience settings. After that, Flatseal will show, two entries from OpenBar with the '!' and other entries from Gradience without the '!' and themes from Gradience will be applied as expected.

I have it too, but I don't think it's affects on working program like visual issue. I might be wrong about that.

And another thing I noticed is that when you turn off the extension, it resets the overrides again. I guess it also happens with css files.

[neuromorph]

I think it's better to implement saving this before applying overrides, so that you don't have such problems. As you wrote above, it won't cause any problems if you just return everything as it was originally. You can do this by saving global file at /var/lib/flatpak/overrides as I suggested above with css files, create a new file with the same name and change it, then if the user doesn't need this function, just delete this file and restore the previous one!

Firstly, /var/lib path is for system wide updates, I only do changes for current user since it is preferred for extensions. So it will be a local user path if we are to go this way. Secondly, the file you refer to is the override config file that would contain all the overrides e.g. overrides for network, ipc, socket, device etc along with 'filesystem' that we need for themes. Replacing the file would lead to user loosing all the overrides while we only want to change the filesystem ones. So backing up existing file and replacing it with our file is not a good option for users who use the other overrides.

One thing I had thought of is checking if the Gtk override exists beforehand and if so then do not remove it when turned off. I haven't yet looked into a clean way to check for that.

I have it too, but I don't think it's affects on working program like visual issue. I might be wrong about that.

It does affect it but only in the sense that, it may seem like its On, due to visual bug while the setting internally is off. That's why I asked to check Flatseal. I think, iirc, if you just close the preferences after toggling and reopen it shows correct status, so that also works.

And another thing I noticed is that when you turn off the extension, it resets the overrides again. I guess it also happens with css files.

It is required by Gnome that an extension should remove any changes including overrides on disable. So yes, it will remove it on disable even if the settings was kept On. For css files, OpenBar uses an identifier in every css that it generates. When the extension is enabled, if there is an existing css that was not generated by OpenBar then it will be backed up. On disable, OpenBar css is removed and if there is a backup available then it will be restored. Note that, this was added in the last update and so if you had any earlier OpenBar css lying there then it will be backed up and restored since it will not have the identifier. So, delete any old OpenBar css and then use the extension.

[NotMephisto]

Firstly, /var/lib path is for system wide updates, I only do changes for current user since it is preferred for extensions. So it will be a local user path if we are to go this way. Secondly, the file you refer to is the override config file that would contain all the overrides e.g. overrides for network, ipc, socket, device etc along with 'filesystem' that we need for themes. Replacing the file would lead to user loosing all the overrides while we only want to change the filesystem ones. So backing up existing file and replacing it with our file is not a good option for users who use the other overrides.

One thing I had thought of is checking if the Gtk override exists beforehand and if so then do not remove it when turned off. I haven't yet looked into a clean way to check for that. .... It is required by Gnome that an extension should remove any changes including overrides on disable. So yes, it will remove it on disable even if the settings was kept On. For css files, OpenBar uses an identifier in every css that it generates. When the extension is enabled, if there is an existing css that was not generated by OpenBar then it will be backed up. On disable, OpenBar css is removed and if there is a backup available then it will be restored. Note that, this was added in the last update and so if you had any earlier OpenBar css lying there then it will be backed up and restored since it will not have the identifier. So, delete any old OpenBar css and then use the extension.

The problem we have is related to adding "!" at the beginning. An inexperienced user won't understand why themes from Gradience or other programs don't work.

You could try doing it this way:

Open a file, read all the information from there, reserve it in a temporary file, after saving the past file, create a new one and stuff all the information from the temporary file into it, while deleting it afterwards. After that you can change everything.

This can be a costly process, but it ensures that all data is preserved or you could write a warning about this problem so that the user can fix it, but it would be easier for the user not to worry about it.

[neuromorph]

The problem we have is related to adding "!" at the beginning. An inexperienced user won't understand why themes from Gradience or other programs don't work.

They would work as long as you turn it on in Gradience. I tried it multiple times here. This kind of issue happens when multiple apps or extensions modify the same resource. By the way, the '!' is not added at the beginning, the entire content of filesystem override is replaced. Gradience also does the same as in replace the entire content but does not use '!'. Need to check what they are doing since there is no reset option for specific context, reset is global. You are right that it can be confusing for users who are not aware of how it works.

You could try doing it this way

That's the idea, though I want to avoid writing a parser for that file. It would be finicky in the sense that it may fail in cases I did not consider ( I don't know the specification for it) and when they change something in it, it will surely fail. Flatpak must be using their own parser so need a way to use the same. Ideally it should have been possible through the override command but doesn't seem like it. This is what I meant when I said that I need to look for a clean way to do it instead of parsing text files. BTW, here is a flatpak override spec if you are interested.

I got you feedback already, I have been trying to explain how things are and why they are the way they are. I will look for the better option as I mentioned, so you can keep it open if you wish. Thanks for the feedback!

[NotMephisto]

The problem we have is related to adding "!" at the beginning. An inexperienced user won't understand why themes from Gradience or other programs don't work.

They would work as long as you turn it on in Gradience. I tried it multiple times here. This kind of issue happens when multiple apps or extensions modify the same resource. By the way, the '!' is not added at the beginning, the entire content of filesystem override is replaced. Gradience also does the same as in replace the entire content but does not use '!'. Need to check what they are doing since there is no reset option for specific context, reset is global. You are right that it can be confusing for users who are not aware of how it works.

You could try doing it this way

That's the idea, though I want to avoid writing a parser for that file. It would be finicky in the sense that it may fail in cases I did not consider ( I don't know the specification for it) and when they change something in it, it will surely fail. Flatpak must be using their own parser so need a way to use the same. Ideally it should have been possible through the override command but doesn't seem like it. This is what I meant when I said that I need to look for a clean way to do it instead of parsing text files. BTW, here is a flatpak override spec if you are interested.

I see, thanks for explanation! I apologize for the misunderstanding and inconvenience

I got you feedback already, I have been trying to explain how things are and why they are the way they are. I will look for the better option as I mentioned, so you can keep it open if you wish. Thanks for the feedback!

No needed, I know that cause this and could fix it anytime.

[neuromorph]

Hello, an update: I found a parser for the file so I have implemented it. It works on the user specific override under ~/.local/share/flatpak/ When turned on, Open Bar will add the overrides on top of whatever exists. All existing config are retained. When turned Off, Open Bar will restore the original config. You need to get the latest commits if you wish to try.

Cheers