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 :heart:

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 :smile: . 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! :+1: 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. :wink:

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. :grin:

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]

Well, now I kind of feel bad

No need to feel bad, lol :smiley: . I meant, with your followups I got the necessary push to re-look into it. And yes, I am happy with the result.

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.

It does not happen in Gnome 42 but I was able to reproduce it in 45 , so finally I got it. Maybe something changed in box-shadow for 44/45. The shadow in Gnome has never been friendly with arbitrary radii. Anyway, adjusting the shadow spread and the limit on border radius should have fixed it in the latest commit (few mins ago). Works OK in my tests.

As a side note, I am also using border width 4 here but a smaller width with higher alpha gives more crisp result.

Thank you.

[neuromorph]

Hello folks,

Some heads up:

• Flatpak overrides option is changed a bit. It will now add the override on top of any existing ones set by other apps like Gradience. And when it is turned off, it will restore the original configuration that was there at the time of turning-on or enabling the extension.
• New settings for window border are added to Gtk / Flatpak section.

Questions:

• There is a Sidebar Transparency option but it doesn't seem to work properly. Have any of you tried it? I will probably just remove it if it messes up unexpectedly (transparency in unwanted parts).
• I saw an option in System Backgrounds, I guess in Fedora 39 (Gnome 45). It shows like a regular dual background option for Dark/Light modes but it is some Day/Night wallpaper thing. It seems that it should automatically switch between two wallpapres based on time of day and also has some transition periods between them. The issue is, in place of the uri for background image, it saves uri for an XML file, so autotheme fails to generate palette since it doesn't find an image. Parsing the XML could help to get the images, though I haven't looked into it. Another issue is transition, have you guys used it and what happens during transition? Is there any kind of mixing of background images?
• On the other hand, in general, is there a way to set up any two custom images as Dark/Light mode backgrounds, through the GUI? (since they show some built-in options for dual backgrounds). This doesn't affect as such but sounds amiss.

Thank you!

[mkalinski]

On the other hand, in general, is there a way to set up any two custom images as Dark/Light mode backgrounds, through the GUI? (since they show some built-in options for dual backgrounds). This doesn't affect as such but sounds amiss.

Does semi-official gnome-tweaks app count?

[neuromorph]

Does semi-official gnome-tweaks app count?

It sure does, hadn't looked into it (have to switch to 24.04 soon). Thanks! Any idea on the transitioning wallpapres? not sure if people are using it.

Hey @doodev , I had totally missed the bg alpha toggle discussed in the beginning here. I remembered and have implemented it now in the latest commits. Hope that helps.

Thanks!

[in4matix]

Hi @neuromorph

It sure does, hadn't looked into it (have to switch to 24.04 soon). Thanks!

Gnome tweaks is available for Gnome 42 (Ubuntu 22) sudo apt install gnome-tweaks or get it on Flathub. When you switch to 24.04, please don't neglect us old school 22.04 guys! Personally I'm staying with 22.04 because I have spent so much time getting it just the way I want it, and having 24.04 running in a VM, I just don't see the viability especially considering that with free pro subscription 22.04 is supported right up to 2032...

Any idea on the transitioning wallpapres? not sure if people are using it.

Here are some good articles explaining dynamic wallpapers: https://itsfoss.com/dark-light-wallpaper-gnome/ https://linuxconfig.org/how-to-create-gnome-dynamic-wallpapers https://www.omgubuntu.co.uk/2022/04/this-dynamic-wallpaper-maker-for-gnome-42-is-nifty

[doodev]

Hey @doodev , I had totally missed the bg alpha toggle discussed in the beginning here. I remembered and have implemented it now in the latest commits. Hope that helps.

Thanks!

Hi @neuromorph, I have been silently using Open Bar 2.0 branch since last week :) I really liked what you have done. Color tones are much better and color problems seems to be fixed. Thank you very much. New pastel and true color options are great too. I am using them for light mode during daytime. I am also using Gtk and shell theming and so far it seems quite nice.

I have been very busy lately so I did not have time to remind you about that toggle :) I am glad you implemented it, thank you. I tried it today and it works just fine.

One minor thing that I notice is when using true color or pastel color with transparent bar, autotheme sets foregorund color to black(sometimes unreadable) in some cases like the one below: This does not happen when using dark mode, and it is not a problem when using with autothemed BG alpha.

Even if I toggle off the Auto FG toggle: Autotheme enables it back again on wallpaper change. Is this a bug or is it supposed to work like that. If it is then may I ask you to add auto FG color toggle to autotheme like this alpha toggle as well?

I have just noticed another thing. This happens when clicking an icon, not hovering. (I do not use dash to dock or anything like that). The proportions of colored part is not symmetrical, looks weird. Not very important but just for you to know.