Improve Autotheming - Discussion [edit]

[doodev]

Hi, thanks for the extension. Loving it so far.
I have a suggestion. Details below:

Open Bar version: 30
Gnome Shell version: 46

When using blur my shell, setting bar background alpha to 0.0 gives better results (for my liking at least). (using mainland)

Examples :
BG alpha 0.0
BG 1 :
BG 2 :

BG alpha 0.9
BG 1:
BG 2:

If auto-theming is enabled, whenever a background changes, auto theme sets bar background alpha to 0.90.

Line 588 in autotheme.js

if(bartype == 'Mainland' || bartype == 'Floating') {
    bgalpha = 0.9;
}
else {
    bgalpha = 0;
}

I removed if-else and set bgalpha to 0. It works for me now as I expected.

Maybe it would be better if autotheme does not override BG alpha or there may be a checkbox/toggle to override BG alpha.

I have not inspected the code much so I do not know if I could add it. There may be reasons for current behaviour for different theme setups and use cases; so having an option for BG alpha override would be nice.

[neuromorph]

Hi, thanks for the extension. Loving it so far.

You are welcome! and thanks ❤️

Maybe it would be better if autotheme does not override BG alpha or there may be a checkbox/toggle to override BG alpha.
There may be reasons for current behaviour for different theme setups and use cases; so having an option for BG alpha override would be nice.

I have received similar requests about alphas for border and shadows as well. I had removed their override.
Initial reasoning was for readability and contrast between widgets/desktop in autotheme since it selects colors from the desktop background and auto-assings.
I agree that user settings should be honored when theme changes with wallpaper. Adding a toggle is a good idea. For now, I will add a single toggle for all the alphas (e.g. BG, border, shadows) so that autotheme will only set them if it is opted-in.

I removed if-else and set bgalpha to 0. It works for me now as I expected.

Cool! That would do it for now. I will include the toggle in the next update.

Also, since you are using auto-theme, it would be great to get some feedback. As in, which option are you using (color, dark, light with default or alt) and any suggestions to improve on it.

Thank you for reporting!

[doodev]

Initial reasoning was for readability and contrast between widgets/desktop in autotheme since it selects colors from the desktop background and auto-assigns.

Without blur my shell, that works better; I concur. I just like the frosty look of blur my shell bar.

Cool! That would do it for now. I will include the toggle in the next update.

That would be great, thanks.

Also, since you are using auto-theme, it would be great to get some feedback. As in, which option are you using (color, dark, light with default or alt) and any suggestions to improve on it.

Sure; I am using dark with default. I use dark because it is safer to use. Color mode with default sometimes chooses inconsistent or unexpected colors for menus. I don't know why; but i will share a few screenshots. I assume this is because of contrast you mentioned. I use Variety as wallpaper changer and it is set to change wallpaper hourly; dark always works at least it is blackish at worst scenario.

Screenshots (Color-default) :

Actually most of the time it works very well.

If color mode would have always worked like the second part(batch) of screenshots, i would have used that mode. First part has too much contrasting colors for my liking. Alt mode has even more contrast most of the time.

Dark mode almost always works great for my liking. The only thing I notice is sometimes the accent color has too much contrast or a strange none-existing/none-prominent color like in the screenshots below. (Pinkish color)


Color palette for the above screenshot:

Maybe if the wallpaper does not have color variety, the algorithm auto populates some colors(pink) instead? It may be better to populate the palette with similar colors ?
Actually this is not a problem with most of the high quality wallpapers.

I have no idea how the algorithm works, but sometimes it seems to apply the most contrasting color from the wallpaper. Maybe it is getting the least prominent color and using it for contrast like in the 3rd screenshot of first batch(brown/orange color).
I think I always expect to use the average or most prominent colors(least contrast) as menu background and accent color. If there was a third option like alt_average providing that, it would have a use for some users like me.

I know this is very complicated and hard work , that is just the feedback you asked for :)

Actually I am very satisfied with dark mode and customization options, thanks again for the extension and your hard work.

[neuromorph]

Awesome! That's the kind of feedback I was looking for. I get what you are saying.
First of all, some of those wallpapers seem to be far from the colors in menus, as you also pointed out. Can you please share the links to those (including the last one where the palette does not match with the wallpaper). I will use them as test candidates :)

A little about how it works:
I use a median cut based algorithm to quantize the colors and generate the palette from the background. I have to beforehand specify the number of "distinct" colors in the image or bins that can then be separated. And we don't know that so I use 6 bins to find prominent colors and again do it with 12 bins to get more colors that may be missed earlier, This kind of algo can do some averaging, which is expected, but sometimes can also find "non-existing' color due to this averaging esp. if num of bins are too off. But I would not expect the palette to be as random as the last image, so maybe a bug or it did not get refreshed.
I can also look into other algorithms, esp to get prominent colors.

After the palette is generated, there is bit of a circus trying to find good color candidates. Initially, I only worked with the color theme and later added Dark and Light options. I thought of a simple scheme: a) Select darker colors for the backgrounds and b) colorful colors for the Accent and highlight. When I implemented it, contrast between colors turned out to be a big issue. The background, foreground must be contrasting to a bare min else readability issue. But also contrast between, menu and submenu, bg and highlights, accent and highlights etc and for some reason I decided to find different colors for the Bar and Menus so twice the trouble. I keep filtering and rejecting colors until there is enough contrast and that might have messed it a bit.

For the Accent, I think of it as the cherry on the cake or lipstick on the face if you will :) So, I tried to pick most colorful, bright option and also preferably one that is closer to red (if available). I still feel it should be a color that stands out (doesn't have to be red though) but yes, it should also be something that is pleasant for the user. Manual override option for accent is added in AutoTheming so one can choose a favorite color. I will also look into improving the auto option. This is especially relevant since I am also working on extending this accent color to the entire shell (as an option). [In fact, there will be options to apply accent, menu styles to the shell allover and extend the accent to Gtk/Flatpak].

Looking forward:
So, most prominent issue I see is that the palette does not always capture prominent colors. Second, I have been thinking about going for a much milder highlight ( I plan to add that option). And, going light on the color contrast.

One more thing I would like to know is about difference between background colors for the Bar and Menu. Do you prefer same, or similar colors for them or Bar should have different style. It can be subjective, some might go with candybar for e.g., but any thoughts are welcome.

Share the background links if possible. I will look into it.

Thank you for the feedback!!

[doodev]

I understand, as I thought, this is very hard work. It is almost impossible to find a perfect solution of course.
I have been using color mode for a day and actually it is pretty good with proper wallpapers.

For the Accent, I think of it as the cherry on the cake or lipstick on the face if you will :)

That's a good way to describe :) Actually at first I used accent color manual override like you said, but it does not always fit and gets boring.
I have been tinkering with color mode since last message, and most of the time it works good with proper wallpapers.

I also think, I have figured out what bothers me :

That green accent for example is too live,bright and contrasting for me. I prefer more "easy on the eyes" colors, a lit bit more pastel or a toned down version of this would suffice i think. But I get your cherry style accent algorithm, so now that makes sense :)

This is especially relevant since I am also working on extending this accent color to the entire shell (as an option). [In fact, there will be options to apply accent, menu styles to the shell allover and extend the accent to Gtk/Flatpak].

That would be awesome, but then again too much contrast might be too distracting for global accent color :) It would be more awesome if you could add a toned down version of current accent color.

So, most prominent issue I see is that the palette does not always capture prominent colors. Second, I have been thinking about going for a much milder highlight ( I plan to add that option). And, going light on the color contrast.

Yes, exactly what i meant, thanks.

One more thing I would like to know is about difference between background colors for the Bar and Menu. Do you prefer same, or similar colors for them or Bar should have different style. It can be subjective, some might go with candybar for e.g., but any thoughts are welcome.

I prefer same or similar colors but I agree that candybar users would like different style. I actually always use blurred transparent bar so it mostly looks like a tone darker version of prominent color.

I have deleted those wallpapers, but I found them again, a few of them missing but critical ones you are asking for are there:
https://wallhaven.cc/w/m3m7p8
https://www.reddit.com/r/EarthPorn/comments/1c3alh1/south_sister_and_broken_top_from_mt_bachelor/
https://wallhaven.cc/index.php/w/m3mk5m
https://wallhaven.cc/w/9dykpd

Thank you for the feedback!!

Thanks for your hard work!

[mkalinski]

Also, since you are using auto-theme, it would be great to get some feedback. As in, which option are you using (color, dark, light with default or alt) and any suggestions to improve on it.

I'm using dark default. Like already mentioned, "color" is too unpredictable, and "alt" seems to produce almost exclusively blackish background (but I'm nor sure what the exact goal of "alt" is, it's not very descriptive).

One more thing I would like to know is about difference between background colors for the Bar and Menu. Do you prefer same, or similar colors for them or Bar should have different style. It can be subjective, some might go with candybar for e.g., but any thoughts are welcome.

I prefer the bar and menu to have a similar color. I think that's about how dark default works now.

I have a question about how autotheme works. Is the "neon glow" color automatically updated also? I noticed at one time that it wasn't, but I'm not sure if it was because of a bug, or it was never meant to be updated. But if not, why?

In fact, I think it might be useful to document in the GUI what options are or are not affected by autotheming. Because right now, I'm not even sure.

[In fact, there will be options to apply accent, menu styles to the shell allover and extend the accent to Gtk/Flatpak]

I know it's slightly off-topic, but how do you plan to style Flatpak? I looked into it some time ago, and there just doesn't seem to be a good way. So I stopped even bothering about trying to style my desktop with anything other than the default Adwaita.

[neuromorph]

Thank you for the feedback!

"color" is too unpredictable

It seemed to work very well for many backgrounds and okayish for most others in my test images. But turns out it can be a disaster for yet others. The main reason is, the palette itself is way off and secondly, the algorithm trying to make everything stand out against each other (Menu/Submenu BG, highlights, accent etc).

Anyway, I am rewriting it already. I managed to get much better palette, at least for my existing test images as well as the ones shared above. If you guys have any more images to add to my test suit, please share links. I use parameters to guide color selection. I start with what I expect to be reasonable and then tune based on how it works on the test images. Having diverse set of images helps to reduce over-fitting.
The color selection logic is being renewed to incorporate the feedback here, so hopefully better results ahead. It will still not work equally for all images but should be better overall.

"alt" seems to produce almost exclusively blackish background (but I'm nor sure what the exact goal of "alt" is, it's not very descriptive).

I thought of describing Alt somewhere but wasn't sure if anyone reads it 😄 . The option itself was not so deliberate. I was selecting the color for highlights and I could prefer lighter or darker one and that decision would many times cascade into different BG colors as well. So, I just added it as an option called 'Alt' :)
But I will be deprecating it. Currently, I am planning option for 'True Color', 'Dark', 'Light' and possibly, 'Pastel'. True Color will use the colors from the image as is. Dark/Light will darken/lighten as needed. Pastel will pastelify them.

Is the "neon glow" color automatically updated also?

Yes, but maybe not entirely. Neon glow color is basically the border color. Autotheme does update the border color, so yes. But currently, it does not care about neon On/Off while selecting the color. The thing is neon only works well if color itself has neon like shade, the background is mostly opaque and dark.

I think it might be useful to document in the GUI what options are or are not affected by autotheming.

Yes, in the new version, I am adding a note in the AutoTheming section. Because it will now only update the colors. Meaning, the alpha values, type of bar, On/Off for neon, border, shadow, wmax bar etc. will all be kept as per user settings.

how do you plan to style Flatpak? I looked into it some time ago, and there just doesn't seem to be a good way. So I stopped even bothering about trying to style my desktop with anything other than the default Adwaita.

True, it can be finicky. For now, I am only trying to extend the accent color and mainly just add overrides to provide flatpak apps access to Gtk configs.

Thanks for the discussion guys, I will share something soon here.

[neuromorph]

Update:
I have been working on this and so wanted to give an update here since it's been a while.

• I have improved upon the palette generation algorithm and so far it seems to have fixed the erroneous palette issue.
• Also, re-implemented the auto-theming logic from scratch to now have the 4 themes as mentioned earlier (True Color, Pastel, Dark, Light). Dark and Light are still safer options and others would depend on the wallpaper colors more.
• Preferences now has a new UI.
• There are options to extend the styles to the entire shell and accent for Gtk/Flatpak apps.

I am working here. It is yet to be finalized but ready to check out. I have tested on Gnome 45. Also ported to Gnome 46 and currently in test, maybe will do tomorrow. Feel free to try it out (or wait for a day or two if you wish).
It will be great to get any feedback, small or big and I will try to add the fixes accordingly.

Thank you!

[in4matix]

Hope we will also get these enhancement for Gnome 42?

[neuromorph]

@0Raik, @Alan-Kuan, @Plyply99, @Ancairon, @JxJxxJxJ

Hello folks, tagging you based on our previous interaction about this extension. Feel free to unsubscribe to the issue, if you wish.
On the other hand, if you would like to try out Open Bar 2.0, you can do so by manually installing from here (Gnome 45+). Any feedback you may have will be greatly appreciated!

TLDR of the above discussion:

• Auto-theming had some issues, primarily incorrect color palette for some images and also some of the assumptions for selecting colors needed revisiting.
• Secondly, I was planning to extend the styles beyond the bar, to the shell and also dock, Gtk apps etc.
• I have improved upon the palette generation algorithm and so far it seems to have fixed the erroneous palette issue.
• Also, re-implemented the auto-theming logic from scratch to now have the 4 themes as mentioned above (True Color, Pastel, Dark, Light). Dark and Light are still safer options and others would depend on the wallpaper colors more.
• Preferences now has a new UI.
• There are options to extend the styles to the entire shell and accent for Gtk/Flatpak apps.

Thank you!

[in4matix]

Are you abandoning Gnome 42 compatibility?

[Alan-Kuan]

Hi @neuromorph.

I tried your Open Bar 2.0 on Gnome 46, and it worked great.
However, I use "Dash to Panel" rather than "Dash to Dock", and Open Bar made icons in my panel incredibly small.
I configured the icon size option in "Dash / Dock" section of its settings but in vain.
Please take a look. Thanks.

[neuromorph]

Hi @Alan-Kuan
Gnome 46 has altered the app icon paddings and that should have caused this issue. I was not specifically checking with Dash-to-panel but it can affect them all.
I have added a fix that should resolve this. You need to get the updated version of stylesheets.js from same branch.
Some settings, like icon size may not work due to the overrides in Dash-to-Panel settings.

@in4matix
Not yet, the 42 version will be available after 45+ is streamlined.

Thanks.

[mkalinski]

I've played around a bit with the openbar2.0 branch and here I my observations so far:

The colors for dark theme are much deeper but still dark. Good job! 👍 Though I have to test out more backgrounds.

The settings menu is much easier to navigate. I breathed a sigh of relief.

What's all these quotes about rice?

Bar Border Radius seems broken. If you set it so that it does not apply to both top or both bottom corners, alpha setting gets ignored (behaves as if it was 100%) and if neon glow is on, it gets weirdly smudged everywhere.

In Gnome Shell overview app bar, icons get very tiny! I'm on Gnome 45, so I don't believe "Gnome 46 has altered the app icon paddings" part applies to me. I honestly maybe prefer the icons like that, but there's no setting to turn this on/off, and it's very unexpected to have an addon that's supposed to control colors in a bar mess with icon sizes in an unrelated part of the shell.

Also, it seems impossible to dosable this effect OpenBar has on the overview app icons even if all settings in the Gnome Shell tab are disabled.

The GTK and Flatpak overrides should not be on by default! I didn't have a custom gtk.css files, but right now just turning on the addon can cause data loss! What's the use of the warning after that?

And I feel like it should not be hard for OpenBar to rename the gtk.css files if they're already there to back them up, instead of overwriting them blindly.

Turning off the extension doesn't disable the gtk.css files it installs, or the flatpak overrides. I think it's a big omission.

In fact, nothing disables the gtk.css files after they've been installed, you need to go and delete them manually to restore previous styling.

Somehow, the gtk.css file installed by OpenBar completely changes the look of the switch control. From this:

To this:

Why would it happen? And of course, I mean the shape. The colour is on theme.

Overall, I like the way it's going with regards to colours, but other additions I find a bit questionable at the moment.

[neuromorph]

Thank you for trying out and for your feedback!!

The GTK and Flatpak overrides should not be on by default!

Yep, I had turned On for my tests in VMs and I finalize the defaults as well as disabling in the end. But you are right, it needs fixing for you guys to test. I have turned off, Shell, Gtk, Flatpak and also Dash/Dock is on Default theme by default.

Also, it seems impossible to dosable this effect OpenBar has on the overview app icons even if all settings in the Gnome Shell tab are disabled.

I think you mean the Dash. In the Dash/Dock Style , select 'Keep Default Theme'. I have kept it as default now, as mentioned above. Also, there is a setting for icon size which had a lower default value (increased now) and can be set from there.

Turning off the extension doesn't disable the gtk.css files it installs, or the flatpak overrides.

That's a miss, since disable isn't yet finalized. I have fixed it. All cleanup will be included before releasing as required for Gnome review as well.

However, both very valid points about defaults and disable. It was my bad, fixed in the latest commits. Thanks for pointing out!

I will check the other items soon, wanted to get these up for anyone looking to install.

[mkalinski]

Okay, I didn't know that the app bar in overview is the dash, and I though dash/dock style is only for dash-to-dock for some reason, so I didn't touch anything, there. 😉

Thanks.

[Alan-Kuan]

Hi @neuromorph.

I tried latest version and the problem of small icon in dash-to-panel was fixed.
Another problem I found was that when I switched between light mode/dark mode, my manual customization got overwritten.
Hope this can be fixed too.
Thank you.

[neuromorph]

@Alan-Kuan

I tried latest version and the problem of small icon in dash-to-panel was fixed.

Cool, good to know!

my manual customization got overwritten

Changing the light/dark mode will apply the autotheme as selected in settings. This can change the colors if the wallpaper has light/dark variants or if different theme is selected for each mode. Please elaborate on what exact customization you are referring to.

cheers

[Alan-Kuan]

@neuromorph

The switch did update the theme according to the setting in the "Auto Theming" section.
However, I used to modify the color chosen by auto-theming, and this will get overwritten when switching modes.
For example, I changed the menu background color from blue to green.
After switching from dark mode to light mode and then back to dark mode, the menu background color changed back to blue instead of green.

[neuromorph]

@Alan-Kuan
I see. There is only one set of settings. Every time you change the theme or manually change a setting, old value gets overwritten. So currently, there is no way to recover old values. When the theme or mode changes, the colors are regenerated as per selection if auto-theme-refresh is On. The changes are retained if auto-refresh is Off.
Also, in your scenario, it is hard to know the intent, some would expect the auto theme to generate colors again (e.g. if they messed up something manually) when switching to a given auto-theme.
It seems more on the lines of creating and saving custom profiles that can be applied instead of auto-theme, but that is not supported, sorry.

@mkalinski

The colors for dark theme are much deeper but still dark.
The settings menu is much easier to navigate.

Thanks, good to know!

What's all these quotes about rice?

Just for fun :)

Gtk CSS:

And I feel like it should not be hard for OpenBar to rename the gtk.css files if they're already there to back them up, instead of overwriting them blindly.

The gtk css gets written many times. Everytime the accent color changes (including every autotheme apply) or when any other Gtk settings change. Also, the file or its content must be removed on disable, meaning it will need to be written on every enable as well. Gnome will disable the extension every time you lock the screen or logout or login. In fact it will do it more than once since it uses a rebasing mechanism that can cause extensions to disable/enable multiple times when you lock/unlock etc. Soon enough, there will be hundreds of backed up Gtk css files. So, no auto backups, sorry.

Somehow, the gtk.css file installed by OpenBar completely changes the look of the switch control.

True. Open Bar needs to create new switch svg icon for the shell since it is not themable. While at it I made the 'socket' narrower than the 'knob' which looks better to me than the big switch and maybe closer to physical switch. You can check it in the notifications panel - the 'Do Not Disturb' switch. Then I tried to match the Gtk switch to it for consistency and it supports theming with css so that was cool. I guess it is a bit shorter and needs some tweaking. Yet to figure that out. Suggestions for tweaks are welcome.

Bar Border Radius seems broken. If you set it so that it does not apply to both top or both bottom corners, alpha setting gets ignored (behaves as if it was 100%) and if neon glow is on, it gets weirdly smudged everywhere.

I believe you are referring to the border alpha. There is no change in this part from the published version. I just tested in Fedora 39-1.5 in a VM and cannot reproduce the issue. The alpha changes the border opacity as expected. Please provide pics of the issue in case I am missing something.
The neon glow requires some supporting settings like appropriate border width/color (border is the neon tube) and mostly dark, opaque background so that a shadow behind it can create the glow effect (shadow is the glow). Smudge is can be mainly from non-opaque background or from higher border width and alpha.

In Gnome Shell overview app bar, icons get very tiny! I'm on Gnome 45, so I don't believe "Gnome 46 has altered the app icon paddings" part applies to me. I honestly maybe prefer the icons like that, but there's no setting to turn this on/off, and it's very unexpected to have an addon that's supposed to control colors in a bar mess with icon sizes in an unrelated part of the shell.

I guess the first part is solved. The settings for icon size are under Dash/Dock and the default is set to size of 48 now.

A heads up, the Gnome 45/46 codebase is same, I am trying to make it work for both equally, but it also means that a stylesheet change added for 46 can also affect 45.

Oh, the extension has been beyond "supposed to control colors in a bar" from early on :) but now it's gone beyond the rest of the shell as well. Even though it is pretty limited in terms of theming apps, I mainly wanted the accent to flow through. I underestimated how hard it would be to make it work for arbitrary colors on the fly. Making a specific theme is hard enough but still much easier and provides much better control. Here, I can't even test for the combinations of selected settings, wallpaper and shell elements that may cause it to fail miserably or highlight room for improvement.
That's where having fresh set of eyes certainly helps. So, thanks folks for trying out and providing feedback. I will surely try to fix the glitches as much possible.

[mkalinski]

The gtk css gets written many times. Everytime the accent color changes (including every autotheme apply) or when any other Gtk settings change. Also, the file or its content must be removed on disable, meaning it will need to be written on every enable as well. Gnome will disable the extension every time you lock the screen or logout or login. In fact it will do it more than once since it uses a rebasing mechanism that can cause extensions to disable/enable multiple times when you lock/unlock etc. Soon enough, there will be hundreds of backed up Gtk css files. So, no auto backups, sorry.

I meant backing up the css files when the option is being turned on or off. Obviously, there's no point in backing up intermittent files that OpenBar writes to.

True. Open Bar needs to create new switch svg icon for the shell since it is not themable. While at it I made the 'socket' narrower than the 'knob' which looks better to me than the big switch and maybe closer to physical switch. You can check it in the notifications panel - the 'Do Not Disturb' switch. Then I tried to match the Gtk switch to it for consistency and it supports theming with css so that was cool. I guess it is a bit shorter and needs some tweaking. Yet to figure that out. Suggestions for tweaks are welcome.

I see. I didn't know that the icon needed to be recreated to be themed. And I saw a very similar switch icon somewhere; I thought maybe in an older version of GTK, but now that I think of it, I think Material uses a similar style.

I don't really have a preference, I was just surprised it was happening, and thought maybe OpenBar is triggering some legacy GTK thing by accident.

I believe you are referring to the border alpha. There is no change in this part from the published version. I just tested in Fedora 39-1.5 in a VM and cannot reproduce the issue. The alpha changes the border opacity as expected. Please provide pics of the issue in case I am missing something.

Yes, you're right. I just noticed this bug only now because on the previous version I didn't try to blend my islands with the background.

Weird things I've seen the border setting do include width seemingly being only set in intervals of 0.5 and then 1.0. It's hard to explain but try this out: Set the width to 0 and then use arrow keys to slowly increase it. It only actually changes visually when it reaches 0.5, and then 1.5, 2.5, etc.

As for smudge, look at this, it's a white border with width 4.0, alpha 0.3 and neon glow on:

(This is not my normal setting, I just wanted to make the neon glow very noticeable)

And now I turn off "apply radius to" for Top-L and Top-R.

Although maybe it's an intended behaviour? This is what happens when radius is turned off.

Anyway, I've stopped using visible border at all, and I think it's better this way for me.

[Ancairon]

Hey, @neuromorph I installed the extension too, and I like what I see!

One thought would be if you were going to allow for manual tinkering on both light mode and dark mode, let's say I want to "lock" the top bar color in the two modes to my hex values and have the rest of the os themed, is that a possibility?

[neuromorph]

@mkalinski

I meant backing up the css files when the option is being turned on or off.

This does not work. Like I said, besides the option toggle, the files need to be removed on disable and so need to add again on enable (may require backup here). The trouble is detecting intermittent file vs actual user file that needs to be backed up. Initially I thought of timing like install/uninstall but there isn't exactly a notion of install/uninstall from within the extension, only enable/disable and that happens anytime without user/extension intervention. So while it can be done, I didn't think it would be reliable and so I thought the hassle may not be worth it.
However, since you were persistent, I decided to give it another thought. I have now implemented a backup scheme as below:

• First, to mitigate the file identification issue, Open Bar gtk css now has an identifier which helps to skip its backup
• If a non Open Bar generated file is found, it will be backed up to gtk_backup_byOpenBar.css
• Only one backup is supported
• On disable or when toggle is turned Off, Open Bar css will be removed and backup, if any, will be restored
• A warning is kept in preferences since things can go wrong in blind scenarios e.g. file being edited or replaced by other extensions, apps or themes.
  Note: If you currently have an Open Bar generated gtk css, it will not have the identifier so it will be backup up (only for folks here using the test setup).

And I saw a very similar switch icon somewhere; I thought maybe in an older version of GTK, but now that I think of it, I think Material uses a similar style.

Not legacy Gtk. It is more like Orchis or Material as you said. I started with the default Gnome switch and added few mods. Also tried to make both Shell and Gtk switches close to each other in the current update.

I just noticed this bug only now because on the previous version I didn't try to blend my islands with the background.

As I see, you are referring to multiple points, so lets take one by one.
The first issue you mentioned earlier about border alpha not working when both top or bottom radius is off. I had created that scenario and changed alpha scale and found it to be working. However, now I tried to replicate as per your pics and while setting noticed that the alpha seems to change right when the radius is turned off. After that moving the alpha scale allows to adjust it again. This is an issue. After digging I found that it faces a rendering issue if the border radius is more than a limit (roughly half the height) in this scenario. Having both top and bottom On helps to cancel the extra radius effect. I have now put a limit internally depending height and border width and so that issue should not occur anymore. Great catch!

Secondly, about the smudge. You mentioned about trying to blend the island with the background which I suppose means lowering the opacity of the islands background. For neon in islands mode, the islands background alpha needs to be sufficiently high to hide the shadow behind. Other than that, smaller width border with high border alpha can give the sharper neon if you wish.

Third, I see in the second and third pic, the gap between islands get this vertical bar like effect with neon esp. when the border radius is off. This causes overlap between neon shadows of neighboring islands. Radius off means more overlap. You will need to increase horizontal padding in 'Highlights' to create space between islands and it will be fixed.

And finally,

Weird things I've seen the border setting do include width seemingly being only set in intervals of 0.5 and then 1.0. It's hard to explain but try this out: Set the width to 0 and then use arrow keys to slowly increase it. It only actually changes visually when it reaches 0.5, and then 1.5, 2.5, etc.

That's true. This can happen in some other settings as well. The width here is specified in pixels. From specifying it in css to actually rendering on the screen, there could be a few steps. More prominently the display scaling and support for sub-pixel accuracy. Normally, at 100% scaling, the 1.5px will get rounded to 2px and will be so until 2.5 at which point it gets rounded to 3px etc. I kept sub-pixel support since for 2x scaling, 1.3px might take roughly 2.6 rounded to 3px on screen. Else it may only be 2px or 4px etc.

Anyway, I've stopped using visible border at all, and I think it's better this way for me.

Border can certainly help in some cases, currently I have also turned it off.

Thank you for the feedback!

[neuromorph]

Hi @Ancairon

I installed the extension too, and I like what I see!

Thank you!

One thought would be if you were going to allow for manual tinkering on both light mode and dark mode, let's say I want to "lock" the top bar color in the two modes to my hex values and have the rest of the os themed, is that a possibility?

I think you are suggesting same thing as @Alan-Kuan said here . Let me try to rephrase:
You want to be able to select an auto-theme for each Dark and Light mode and apply it (as available in Auto Theming). Then you want to change some color for Dark and maybe also for Light mode. Then you want to be able to switch between Dark and Light mode from Quick Settings panel and expect that the Auto-theme corresponding to that mode should apply but also include the altered colors.
As I mentioned here , this is not supported and wasn't considered in the design. Thus it will be more involved to implement. However, if multiple folks are asking for it, then there is something to it that would push me to look into it. Please confirm if you guys are talking about the same thing as mentioned above and I will see what I can do.

[mkalinski]

However, since you were persistent

Well, now I kind of feel bad, because it's not really a functionality I particularly need, and from your response I think I misunderstood how the shell handles the extension being disabled / reenabled, so I wouldn't have kept proposing this if I actually got that right. 😁

However, the eventual solution described looks pretty good.

Secondly, about the smudge. You mentioned about trying to blend the island with the background which I suppose means lowering the opacity of the islands background. For neon in islands mode, the islands background alpha needs to be sufficiently high to hide the shadow behind. Other than that, smaller width border with high border alpha can give the sharper neon if you wish.

By "smudge" I mean the effect visible on my screenshots:

Because it looks like the neon glow that would follow the border crisply when the radius was applied would get smudged to the sides when the radius was turned off. There's no other issue I had in mind. Sorry for the misunderstanding.

Third, I see in the second and third pic, the gap between islands get this vertical bar like effect with neon esp. when the border radius is off. This causes overlap between neon shadows of neighboring islands. Radius off means more overlap. You will need to increase horizontal padding in 'Highlights' to create space between islands and it will be fixed.

Well, I guess increasing the padding would indeed fix the overlap. I didn't think about it. So, I understand that this behaves as it's expected, and there's no bug here.

[neuromorph]

There's one thing I noticed: in one of the previous versions, enabling the GTK 3/4 override would make OpenBar style the title bars of GTK application windows.

That's the 'Headerbar Hint' slider in Gtk/Flatpak Apps tab. It adds hint of Accent color based on selected % value. Initially, default for both Headerbar and Sidebar was 10 so you would see a 10% hint when enabled. I then realized that the default look these days in Gnome/Adwaita does not highlight the headerbar, instead it is just left and right panes. So I changed the default for Headerbar Hint to zero, so it shows the two panes similar to Gnome. Well, I am not sure which one is better default, 0 or 10, so suggestions welcome. The idea is to not change it too much by default and let users do the change but at the same time also provide clues of what's possible 🤷

TL;DR - The setting is called 'Headerbar Hint' similar to 'Sidebar Hint' and newly added 'Card/Dialog Hint'. Default value is now set to zero but can be set to desired % using the slider.

The Auto Yaru themes is an additional option for people using them (default on Ubuntu) so that the non-colorable assets like icons or animations (e.g. mouse scroll in settings) also look similar by following nearest available Yaru theme.

Also,
I have pushed some modifications, in latest commit, for Auto-theming colors. Hope it works a little bit better now.

Thanks.

[mkalinski]

That's the 'Headerbar Hint' slider in Gtk/Flatpak Apps tab. It adds hint of Accent color based on selected % value. Initially, default for both Headerbar and Sidebar was 10 so you would see a 10% hint when enabled. I then realized that the default look these days in Gnome/Adwaita does not highlight the headerbar, instead it is just left and right panes. So I changed the default for Headerbar Hint to zero, so it shows the two panes similar to Gnome. Well, I am not sure which one is better default, 0 or 10, so suggestions welcome. The idea is to not change it too much by default and let users do the change but at the same time also provide clues of what's possible 🤷

Thanks. Looking at both styles, I really like the tinted headerbar. But I guess that the current default looks more sensible on GTK4 apps with sidebar. It's a shame that also makes GTK3 apps and apps without a sidebar mostly not tinted. Then again, client-side decorations in the headbar remain untinted, which may subjectively look awful or quaint. But me, I like more color. 😄

[neuromorph]

Looking at both styles, I really like the tinted headerbar. But I guess that the current default looks more sensible on GTK4 apps with sidebar. It's a shame that also makes GTK3 apps and apps without a sidebar mostly not tinted.

Agreed 👍 . This is how my settings app looking now:

Then again, client-side decorations in the headbar remain untinted, which may subjectively look awful or quaint.

Yes, again. But do you have an example pic for CSD, other than Terminal maybe?

More colors to you! :)

[doodev]

Hi @neuromorph

Auto FG toggles for Bar and Menu in Auto Themes section to select whether to auto-generate FG color or retain user selected. @doodev - you can check it out, also the next item for highlight fix, in latest commit.
Fix for the highlight in Dash/Dock when an app icon is clicked.

Thank you for these fixes, I have been testing since you updated and they work perfectly.

There is a few minor issues though but I don't have time to inspect it.
1 - Sometimes GTK themes are not applied or color palette does not change after a wallpaper change.
2 - Rarely, after a wallpaper change (by Variety) the extensions starts using excessive amount of cpu and does not stop until I disable the extension. Even it caused the shell crash completely once. The algorithm is CPU heavy of course and I think sometimes it is stuck in a loop or sth triggered by wallpaper change. I will open another issue for this when I have time.

By the way I did not encounter any other crashes like fullscreen or lock screen crash issues mentioned.

I have also pulled the latest commits today. Maybe it has been fixed :)

[neuromorph]

Hey,

1 - Sometimes GTK themes are not applied or color palette does not change after a wallpaper change.

Gtk may not be instant and may require reopening app or reloading Gnome but if the palette itself does not update then that might be the main issue (for Gtk as well). I will look into it but any more inputs on how to reproduce will be great.

2 - Rarely, after a wallpaper change (by Variety) the extensions starts using excessive amount of cpu and does not stop until I disable the extension. Even it caused the shell crash completely once. The algorithm is CPU heavy of course and I think sometimes it is stuck in a loop or sth triggered by wallpaper change. I will open another issue for this when I have time.

OK, this is a biggy. I was ready to upload to extensions web today but this needs investigating first. I have not used Variety, not sure how that may affect but will try it out. A screencast of the screen with CPU % while the wallpaper changes will be helpful. Any more inputs on how to reproduce the 'excessive CPU or stuck in loop' situation will be of great help too.
You can try with a nested shell (under wayland) to test out any scenarios so that: 1. The nested shell may crash but host shell won't, 2. You will be able to see the log in the terminal to help trace the issue.
Quoting nested shell instructions from another issue:
You will need to be on Wayland, then open a terminal and run following command. It will launch a new window with a new (nested) instance of the shell. It will throw a lot of messages in the terminal from all sorts of processes/extensions but that's normal. Then trigger the wallpaper change within the nested shell. If the issue occurs, the nested shell window will crash but the terminal should show a log of what happened. Share that log here so we can check for clues. (You may want to send the log to a file). Command:

MUTTER_DEBUG_DUMMY_MODE_SPECS=1200x800 SHELL_DEBUG=all dbus-run-session -- gnome-shell --nested --wayland

Thank you for reporting! Hope to crack it soon.

[mkalinski]

Yes, again. But do you have an example pic for CSD, other than Terminal maybe?

There are a couple of them, mostly from GNOME apps that were not favoured enough to be ported to GTK4.

Evolution, the GNOME mail client:

gThumb, the (better) GNOME image viewer:

Bonus one: while Firefox has its own theme system that doesn't follow GNOME theming, it also uses a stock GTK3 file chooser, in which the uncoloured buttons are also visible:

GTK 4 also puts buttons in titlebar, but they're flat, so there's no colouring problem (I'm not a fan of the great flattening of everything, but alas. Maybe I'll move to XFCE when it completes Wayland implementation).

[neuromorph]

There are a couple of them, mostly from GNOME apps that were not favoured enough to be ported to GTK4.

Thank you for sharing these! I have installed gThumb and am looking through it and firefox and maybe able to fix the tint for the buttons. I will update here once I get it up.

[neuromorph]

Thank you for sharing these! I have installed gThumb and am looking through it and firefox and maybe able to fix the tint for the buttons. I will update here once I get it up.

The headerbar buttons tint update is up in last commit! Samples from Ubuntu 24.04 Gnome 46:

GThumb

Terminal

Firefox

[neuromorph]

@doodev

2 - Rarely, after a wallpaper change (by Variety) the extensions starts using excessive amount of cpu and does not stop until I disable the extension. Even it caused the shell crash completely once. The algorithm is CPU heavy of course and I think sometimes it is stuck in a loop or sth triggered by wallpaper change.

I tried a bit with Variety. I think the algorithm feels heavier than it is with Variety due to repeat signals causing it to run in succession. I noticed that the repeat signals would also happen at times without variety. But with it, the repetitions were more and would happen more often. I have some idea of why that could be even though I haven't looked into their code in much details. I had also faced this issue - e.g. when you set a wallpaper by right clicking on an image file, it would copy the wallpaper to a location for 'current background' but the URI for both light and dark wallpapers would stay at '...../background'. If a dconf setting is updated with same value, it does not trigger update signal. To force the signal, you need to ensure the value of the setting changes. Probably for this reason, Variety adds random strings to the wallpaper filenames in it's own directory and uses that as URI. Some unknown reason seems to cause it to update the URI with new random string even when the underlying file is same.
Anyway, Open Bar listens to any changes in URIs for Dark/Light wallpapers and triggers refresh. I have now updated it with longer repeated signal blocking, meaning repeated signals in quick succession (within few seconds) will be discarded to avoid repeating the whole theming process a few times.
I also noticed CPU going way up when starting/stopping Variety and realized that it was due to the URI update signals. This happens since, it sets random string URIs when started and resets to actual filenames when quit, even though the background did not change during this time.

You can watch for the URI changes while you start/stop or interact with Variety by using this command:
dconf watch /org/gnome/desktop/background/

Please try with the latest commit, hopefully the excessive CPU will be solved. Not sure on the crash thing if it is related but could be.

[mkalinski]

The headerbar buttons tint update is up in last commit! Samples from Ubuntu 24.04 Gnome 46:

That's impressive. However, for some reason, there's no visible change in Evolution (see my previous post, first screenshot).

Perhaps the text button with icon and dropdown (as you can see, all are like that in Evolution's titlebar) is some completely separate component from those other button kinds that you styled?

[neuromorph]

Perhaps the text button with icon and dropdown (as you can see, all are like that in Evolution's titlebar) is some completely separate component from those other button kinds that you styled?

Yes, Evolution buttons have a bit different class / layout. I installed Evolution and fixed the tint in the latest commit.

Also,
There is another issue where a couple folks reported crash with Candybar On. I am not able to reproduce it at all and yet to here more from them to be able to investigate. Can you guys please try it out by turning On Candybar Palette in Bar Background. Apparently, Gnome may crash on screen lock/sleep Or when resuming (which is essentially extension Disable and Enable respectively). To avoid crashing host shell, you can test in nested shell under wayland using this command:
MUTTER_DEBUG_DUMMY_MODE_SPECS=1200x800 SHELL_DEBUG=all dbus-run-session -- gnome-shell --nested --wayland

If you face this or any other Crash issue please let me know.

Thanks much!

[neuromorph]

Quick Update:

There is another issue where a couple folks reported crash with Candybar On. I am not able to reproduce it at all and yet to here more from them to be able to investigate.

I finally faced this issue and was able to look into it. There is an upstream issue with an MR ready. I also added a potential workaround in the meanwhile (latest commit). I talk about it here.

[mkalinski]

Yes, Evolution buttons have a bit different class / layout. I installed Evolution and fixed the tint in the latest commit.

There's another problem with the GTK3 buttons styling.

Evolution uses buttons that stay pressed down to indicate that they're active.

But in Open Bar's "flat" GTK3 buttons it's impossible to see.

The button on the left is pressed down, the one of the right isn't, but they look the same.

[neuromorph]

Evolution uses buttons that stay pressed down to indicate that they're active.

Ah OK, CSS ftw. If you touch default state color in shell css, all other state styles give up for no reason 😬
Fixed in latest commit.

If you folks face any crashes , please let me know.

Cheers

[neuromorph]

Hello All,

I have uploaded OpenBar 2.0 to the Gnome extensions site for review. Yet to merge into 'main', will do sometime soon.

The metadata.json file was edited earlier to bump up the version since it can otherwise be overwritten by any intermediate update. If you have pulled the latest commit at least by yesterday then it should already be reset else you may want to pull now. This is so that when the extension goes live on the web, you'll be notified of update and it will get downloaded/installed. You can anytime edit the metadata later as well. The new versions will be - Gnome 42-44 => 31, Gnome 45+ => 32, or a higher number if the review has any corrections/suggestions.

Thanks a lot for the discussion here !!

Feel free to raise a new issue as needed.

Best.

[in4matix]

Hey @neuromorph , Thank you so much for your commitment, patience and hard work!! You rock dude!!

[neuromorph]

You are welcome @in4matix and Thanks much!! :)

[doodev]

Please try with the latest commit, hopefully the excessive CPU will be solved. Not sure on the crash thing if it is related but could be.

Hi @neuromorph,

I have been testing since you fixed that problem. I have not encountered any excessive CPU usage or crash since then. Even, theme changes are applied instantly now when Variety changes the wallpaper. (was hanging the system a bit before)

Thanks for your quick fixes and hard work; awesome extension :)

[neuromorph]

I have not encountered any excessive CPU usage or crash since then. Even, theme changes are applied instantly now when Variety changes the wallpaper.

Great news! System hanging is certainly bad. There is still enough room for optimizations but it was already quick in my tests on my old laptop and it may require quite some refactoring so I haven't gone much down that path. It's kept for future updates.

Thank you for all the helpful feedback 👍

[Alan-Kuan]

Hi @neuromorph

After I pulled the latest commit from 2.0 recently, I encountered an issue that the extension would be disabled when my laptop resumed from sleep.
The following is the error message provided by the Extension app.

I could not think of any other things that may cause the problem.
Please take a look. Thank you.

[neuromorph]

@Alan-Kuan

Have you added any new app or extension that adds an indicator to the panel?
Here, 'btn' is a container and 'child' is the actual indicator as per default Gnome panel-button layout. But sometimes, extensions do not follow standard layout. Besides, in the latest commits, there are some updates for Candybar buttons which should not but may have caused it.

A pic of the panel can help to see what all is in there. Also a log will be needed to get the trace for the error.
You can use following command to monitor the journal and then enable / disable the extension and watch for the errors. If it only happens on sleep then you can try that as well while keeping the command running in terminal:

SHELL_DEBUG=all journalctl /usr/bin/{gjs,gnome-shell} -fo cat

To simulate lock/sleep, you may run a nested shell with following command and use the Quick Settings in the nested shell to Lock or Suspend it and watch for errors in the terminal.

MUTTER_DEBUG_DUMMY_MODE_SPECS=1200x800 SHELL_DEBUG=backtrace-warnings dbus-run-session -- gnome-shell --nested --wayland

Please share the log here so I can figure out and fix it.

Thanks!

[Alan-Kuan]

Hi @neuromorph

A relevant extension I can think of is "Dash to Panel". I'm not sure whether the green dot in the following screenshot is the indicator you mentioned.

Furthermore, I found the problem occurred when I lock/suspend the session twice. After the second resume, the extension was disabled due to the error. To spot the first malfunction commit, I tried reproducing the error with "git bisect" and confirmed it is the commit 6256c5a.

In addition, I reproduced it in the latest commit and dump the log to openbar.log.

Hope the information can help you fix the bug.
Thank You.

[neuromorph]

Hello @Alan-Kuan

I have pushed a fix to 'openbar2.0' branch. Can you please pull the latest commit and test with it to confirm the fix. If it works well, then I would have to resubmit for Gnome review since they are still pending there.

Thanks.

[Alan-Kuan]

Hi @neuromorph

I tried, but unfortunately, it still exists.

UPDATE:
The error changed:

And here's the log: openbar.log

[neuromorph]

Hi @Alan-Kuan

The error changed:

Oops :(
Thanks for the log! I have pushed another update that should hopefully fix it.
I haven't faced the issue but that could be due to difference in our panel setup.

Let me know how it goes.

[Alan-Kuan]

Hi @neuromorph

I tried again. This time, the extension works well.
I suspended and resumed the session for 3 times, and no issue occurred.
I think it is solved.

Thank you.

[neuromorph]

Quick Update:

• I have merged OpenBar 2.0 into 'main' branch so all new updates will be there.
• Some fixes are already added in 'main', mainly for candybar and for the 'color palette not getting updated' bug
• I had uploaded the extension to Gnome, as informed earlier, and it just got published.
• It does not have latest commits, so I will upload another version very soon. Meanwhile if you face any issues in the current version from 'main', please let me know.

Thanks!

[neuromorph]

Thank you all for your contribution, I am closing this thread now!

A reminder, please refer to 'main' branch for any updates instead of 'openbar2.0'.

Feel free to log a new issue for any bug or suggestions.