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.

[neuromorph]

@in4matix

Gnome tweaks is available for Gnome 42 (Ubuntu 22)

Sure! I was referring to the Dark and Light background options that aren't available.

When you switch to 24.04, please don't neglect us old school 22.04 guys!

This will be updated for 42 as mentioned earlier. I will report on the other issue for G42, when it's ready. However, I will move on later, so at that point 42 will retire for new features. I don't know what those features could be, for now it should be all same.

Here are some good articles explaining dynamic wallpapers:

Thank you for the articles! Apparently, Dark and Light dual wallpapers were introduced in 42 itself but Ubuntu ditched it. As for the transitioning wallpapers (XML ones), I have decided to not support it at this point. One can potentially take 20 different images and transition through them during the day and the image overlays during transitions will keep changing the colors.

Thanks!

@doodev

Thanks a lot for the feedback on colors and themes, appreciate it! Since you cycle through many backgrounds, if you come across any background samples for any theme-type that might suggest a direction for improvement, please take a screenshot and share whenever you are free.

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:

Ah, true. The auto foreground color is generated based on the background color. However, if the background is fully or mostly transparent, then it can fail since we don't know what's behind. Autotheme assumes relatively opaque background and then to avoid the scenario of FG merging with BG, it forces Auto-FG to On. So yes, it is designed that way, and yes I will add the toggles in autotheming to turn off Auto-FG. You would need to manually set the FG color in that case.

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.

Since you do not use Dash-to-dock, I assume it's the built in Dash. And also, just to make sure, when you click on an app-icon it has that Green highlight momentarily where Green is the accent color. If so, then that highlight is expected but the asymmetry is a bug. I will look into it. Not sure how you captured the momentary highlight :stuck_out_tongue:

Thanks!

[in4matix]

@neuromorph

Not sure how you captured the momentary highlight

Just assign a custom keyboard shortcut to Screenshot in system settings ;-)

[doodev]

Since you cycle through many backgrounds, if you come across any background samples for any theme-type that might suggest a direction for improvement, please take a screenshot and share whenever you are free.

Sure thing.

yes I will add the toggles in autotheming to turn off Auto-FG. You would need to manually set the FG color in that case.

Thank you, it would be perfect.

Since you do not use Dash-to-dock, I assume it's the built in Dash.

Yes I use built-in dash but now I installed dash-to-dock, problem almost solved :) But still there is small asymmetry.

Not sure how you captured the momentary highlight 😛

The credit goes to default gnome screenshot tool. When you press print screen, it freezes the screen the moment you press the key. Then you select the rectangle area or whole screen to save the screenshot. Very useful when a video or animation playing.

[neuromorph]

Thank you for the update guys!

Quick notes: I haven't looked into the highlight thing yet since something else has come up. Also, I was in the middle of implementing the "remember my manual color overrides when I change the modes between dark/light" thing as requested above. So I will try to finish that first, partly there but had to take a break due to some other work.

Also want to ask you guys for an idea that came up while discussing another issue. Currently, if an existing gtk.css is found under config/gtk-3.0 or 4.0 then it is backed up and then replaced with Open Bar gtk.css. Would you prefer that Open Bar do the backup but then instead of replacing it, append to it to apply styles on top of existing ones?

Thanks, I will update here when the in-progress things are ready.

[mkalinski]

I don't know how helpful it could be, but regarding the highlight issue that @doodev mentioned: I only recently updated the repo I'm using to commit 16be094 and I'm also seeing this issue, but when I was previously on a061d8c, I did not see this problem.

[neuromorph]

Hellos,

I had to install afresh on a new disk and so needed to get the setup ready again. Basic is ready though not there yet and switched to new OS (24.04) so it does have its own quirks. Nevertheless, some updates:

• I have separated dark/light mode change from overall theme change that happens when the background changes. Till now both were handled similarly and when the mode changes, new theme would override any manual changes to color made by user. Now, e.g. if you make changes to colors generated by auto-theme while in Dark mode and then switch mode to light and then back to dark, your changes will be retained. Changes made to color are matched to the current mode your are in. Also, when background changes or if you manually click on Apply to regenerate theme, the user made changes will be overridden by auto-theme (as per design). @Alan-Kuan and @Ancairon - you can try it out from latest commit. Note: it is only for colors, since they get auto-generated for theme. Other settings will be same for Dark/Light.
• 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.

Let me know if you face issues.

Thank you!

[Alan-Kuan]

Hi @neuromorph,

I tried the dark/light mode changing feature, and it worked perfectly. However, one weird thing happened: right after I updated to this commit, when I hit the mode change button, almost all my existing colors became the color of accent color (override), even though I didn't select the option Override auto-theme Accent Color. After I clicked the 🔁 Get button, it worked normally. The color schemes I modified later were preserved for both dark and light modes, and no color was changed to the color of accent color (override).

[neuromorph]

However, one weird thing happened: right after I updated to this commit, when I hit the mode change button, almost all my existing colors became the color of accent color (override), even though I didn't select the option Override auto-theme Accent Color.

Oh yeh, it would be weird indeed. The thing is, there are now new sets of colors added for Dark and Light in the settings (used internally). They take the same default values as the original default for that color and get updated when you click on Apply Theme or Get (as you tried). I suppose you never changed the 'accent color (override)', so it is still on the original default color. So, when you changed mode directly, the colors got overridden with the defaults which are around 'cyan' color. This would be normal for a new user since all colors will be defaults and consistent. For us, it is weird until we regenerate the theme with 'Apply' or 'Get'. Note: 'Apply' takes the palette and generates the themes. 'Get' first regenerates the palette then triggers Apply.

After I clicked the 🔁 Get button, it worked normally. The color schemes I modified later were preserved for both dark and light modes, and no color was changed to the color of accent color (override).

Cool! Thank you for trying out and providing the update! Do report in case some bug creeps up.

[JE-Amouel]

I am really very satisfied with the extension, I achieved a refined and responsive result.

however I hope that one day there will be a port of the new functionality for the pop os platform, which I think is now under gnome 42.9.

thanks again.

[neuromorph]

Hi JE-Amouel,

I am really very satisfied with the extension, I achieved a refined and responsive result.

That's great to hear! Thank you for the feedback! :clinking_glasses:

however I hope that one day there will be a port of the new functionality for the pop os platform, which I think is now under gnome 42.9.

I am not sure what you mean since your screens show Ubuntu 22.04 with same Gnome version 42.9. This extension will get released for both Gnome 42-44 and separate version for Gnome 45+ (only difference being version number). I have not tested on Pop OS but it should work if it is using Gnome. I wanted to try Pop but I hear they will be moving away from Gnome with the new Cosmic.

===

Hey All,

Some finetuning updates were pushed today, in case you would like to try.

And, I have a somewhat embarrassing question - how to use Gradience? I tried it out today by setting some window colors to test if it applies well to all apps and whether it is instant. I set the color then hit Apply to save. It changes the color of Gradience window when color is selected but not any other app. And, when Gradience is closed and reopened the changes are lost. I saved it as preset and then applied the preset but it behaved the same. So I must be doing some silly mistake. I am guessing some of you might be using it, so can you please enlighten me?

Thank you!

[JE-Amouel]

I am not sure what you mean since your screens show Ubuntu 22.04 with same Gnome version 42.9. This extension will get released for both Gnome 42-44 and separate version for Gnome 45+ (only difference being version number). I have not tested on Pop OS but it should work if it is using Gnome. I wanted to try Pop but I hear they will be moving away from Gnome with the new Cosmic. @neuromorph

pop os is my backup distribution, I always keep it next to me, I always copy the setup of my Ubuntu desktop onto it, and yes they are preparing a migration to COSMIC DE, but since there is not much detailed information on this desktop, I hope that they will keep some compatibility with the gnome extensions, that would be really good,

but my main distribution remains ubuntu with GNOME 42.9, I am still waiting for some of my favorite extensions which are stagnating a little to move to version 45+ of gnome before I can make the change too, and since I have become a little familiar with open-bar it has also become one of my favorite extensions, and in addition as you have already upgraded to gnome45+ I am already more reassured.

since version 40, GNOME has become an increasingly refined and elegant environment, but what makes me feel more comfortable and boosts my productivity are these extensions made by inspiring and talented developers like you,

if COSMIC DE breaks compatibility with the GNOME extensions it would still be a shame, especially for a distribution which has often been a GNOME spiced up with reworked extensions, something which was really very good.

THANKS.

[neuromorph]

Hey,

Some more updates are pushed in the last couple days including refactoring and some new additions. I plan to wrap it up now and send for Gnome extensions review and release. I thus request you guys to pull the latest commit from 'openbar2.0' and use that. So that if any bug or suggestion pops up then you could let me know while I update the Gnome 42 port and finalize the 'Disable' cleanup.

Oh, any inputs on Gradience are still welcome.

Thank you for your contribution! Much appreciated!

[mkalinski]

Here's a bug for you. ;)

When I open the settings window, it opens with the X button somehow partially obscured.

There's something wrong with the title bar in general, the window title will also be obscured if the window is narrow enough.

That's not how windows in Gnome generally behave. Contrast with ex. the settings app, you can narrow the window but the title always stays in center, and the X is never covered.

[neuromorph]

Here's a bug for you. ;)

Great catch! There was a bug that pushed the width of content more than the rest of the UI. It's fixed now.

There's something wrong with the title bar in general, the window title will also be obscured if the window is narrow enough. That's not how windows in Gnome generally behave. Contrast with ex. the settings app, you can narrow the window but the title always stays in center, and the X is never covered.

Yeh, the window is custom made using Gtk and not responsive to resize. I don't know how to fix that. The straight way to go about it is to build it using Adwaita and everything will behave like Gnome windows. I had started with that but Gnome 42 doesn't support much of its API so had to ditch it. I plan to rewrite the 45+ version with Adwaita in the future. For now, I have fixed the defaults and minimum resize limits to avoid the issue.

Another bug with the Card/Dialog hint is also fixed.

Thank you!

[mkalinski]

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. This is seemingly gone now, and it looks like the closest replacement is an option to set the Yaru theme. Why was styling of title bars removed? Or am I missing the option somehow?

[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 :shrug:

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

[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 :+1: . 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.