Which slider are you talking about? The ones in the opacity section (at the bottom of the second tab of the preferences dialog), or the one in the colors dialog?
Feel free to provide screenshots with your setting and the result on the panel to clarify.
After some investigation I found out that the problem comes from Picom not from xfwm4 compositor. If I logout/in from xfwm4 the panels remain transparent but with Picom they get black and I have replace the panels to get them transparent again. It sounds like Picom doesn't initialize the panels.
I managed to get this working by restarting XFCE panel with:
xfce4-panel -r
This makes me think it is actually an xfce panel issue, Other's have saiid that when the panel starts (before picom) it is running at 24 bit due to it not detecting picom, Once picom is running and you issue xfce4-panel -r (to replace the current) it detects picom and starts in 32 bit.
This is probably due to 87c609e7. However this fixes #251 (closed), so if the only side effect is having to restart the panel once picom is running (and only to get the transparency working properly), I'd be tempted to leave things as they are.
I can't reproduce the transparency problem, it works for me for some reason. But I can reproduce the color depth problem and I think there's actually something to be done there, so let's reopen this.
Setting a new visual will not cause widget to recreate its windows, so you should call this function before widget is realized.
So restarting the panel seems necessary in this case.
Note that for me, starting the panel with compositing disabled and then enabling it does not prevent transparency from working (either with xfwm4 or picom), so there must be something else.
if you’re talking about the entire panel transparency it works because it's based on the opacity atom and compositors handle this correctly, however, background set to a solid color with transparency won’t work. i can upload a video of reproduction if you want.
If we exclude the case of people enabling/disabling the compositor at run time, it could be a race at startup, the outcome depending who wins and starts first, between xfwm4 and the panel.
the video reproduction is too big to upload it here, so here is the link to it with some basic explanation of what's going on included (sorry for my accent, i'm not the english native): https://sinair.ru/f/TidmV3Wp
Thanks for the video (your accent is correct, at least better than mine :D). I can indeed reproduce this problem, and I confirm that invoking gtk_widget_set_visual() on GdkScreen::composited-changed doesn't change anything (both on the output of xwininfo and on the panel transparency via solid color).
So again I think the solution is to restart the panel in this case. Besides, I don't think that everything is bound to work properly after a change of compositor during a session.
As for a possible race condition between the panel and xfwm4 (or any other compositor), this is a session startup problem that does not concern the panel directly.
to be honest, i'm not sure what #251 (closed) is trying to approach because
32-bit depth compared to the 24-bit one just adds the 8 bits of alpha channel (32-bit depth is 8a8r8g8b and 24-bit is 8r8g8b), it doesn't affect sizes of the color components;
instead of fixing the issue with his monitor he prefers to report issues with the software he's using, but there is a lot of software behaving the same way. as i can see, on my setup almost everything runs with the 32-bit depth.
if you ask me, i'd revert the fix for the #251 (closed) and close it as wontfix. however, if you want to keep this behavior, i'd tune the fix to also set 32-bit depth if the panel is configured to have transparent background color. this fix for this weird issue disturbs normal users and it's not obvious that you have to restart the panel to get the transparency you've configured.
if you ask me, i'd revert the fix for the #251 (closed) (closed) and close it as wontfix.
I'm not opposed to it, actually I'm not sure what the right attitude is.
As said in #251 (comment 49193), Thunar also only sets an RGBA visual if compositing is enabled, but that's not necessarily an argument, as for the documentation it can actually be interpreted in various ways.
Leaving this as is seems to be a bit shitty.
If I set something to be transparent I expect it to be that not using a cludge of restarting what I want to be transparent to get it be that way because the rest of the DE can't make it's mind up of what it should/shouldn't do is not the right approach.
If this is the way forwards I'll just leave xfce and move to another DE that functions correctly without work arounds.
I'm calm and polite in confront of your condescension.
Is the "do not attribute thoughts to me that are not mine" your sense of responsibility ? What are you representing here, someone from the staff or a visitor ?
My "sense of responsibility" has nothing to do with it, I just ask you not to pretend that I think this or that when you don't know, that's all.
For the rest the discussion is closed. If you have any comments about the way Xfce or this or that component is maintained, I invite you to use the mailing list.