@jaagr any comments?

@beenofs sorry for my extreme delay. I have a few comments, will open up a review as soon as I can.

@jaagr no problem, take your time. Just wanted to make sure this didn't get lost, as I often forget about PRs myself when I only take a short look at them and then github notification is gone ☺

This feature is currently not compatible with a bottom aligned bar.

@lmoesch oh? what happens in that case? i had assumed that m_rect would be the correct rect for a bottom alligned bar as well

The background area is still copied from the top of the background, not the bottom. I tried to modify the values of "copy_area_checked" within the background_manager wich did the trick. So basically we need to get the corner point information to that function.

@lmoesch background_manager stores a m_rect that specifies the target location from which the background should be copied. It is passed to it in via the activate method, so we just need to make sure we pass it the right values there.

@lmoesch should be fixed with last commit.

(needed to use m_bar.inner_area(true) instead of m_bar.inner_area())

Splendid, that worked like a charm! Thanks for the quick fix 👍

While fiddeling arround with some parameters I came across other bugs.

First thing is, that the offset of a border is not taken into account while calculating the background snippet. Unfortunately I have just few to no knowledge about X-Server classes and behaviour, but I assume that a border is also drawn by a rectangle which gets overdrawn by the content. So to fix this one I guess it is sufficient to replace the bar rectangle with the border rectangle.

Other thing is a trickey one. When using multiple bars ontop of each other, background location also fails due to the offset to each other. (e.g. if you have two bars on top, then both will have the background of the most upper one)

@lmoesch

Borders work correctly now: (this is a semi-transparent border at top)

Have to look into the "multipe bars stacked" issue.

Btw, I am not sure anymore what I originally meant by "Cleanup tray changes"

Ok, fixed the second issue as well:

Hope I haved missed any configuration :)

Rebased against latest master

Thanks for the review!

I have changed to using brace initialization. The tray works fine for me, but alpha support in the tray is dependent on the tray icon having alpha channel I think. What program have you tried, maybe it is specific to that program that it does not work (does it work if using a compositor)? I am using udiskie which has a tray icon and that it works there for me.

Yes we need a detection method. I will look into that. But with the changes, it should be pretty easy to turn of the pseudo-transparency if there is a compositor: right now, we fill the surface with the desktop background as a first step and then paint everything on top of that, using cairo's support for transparency. If we have a compositor, we can simply drop the first step and paint the window fully transparent, everything else should keep working.

I've tried nm-applet and yakyak (an Electron app) and both result in an opaque background, with and without compton.

@NBonaparte hmm, if I use the example config and change background to #BB222222 everything is semi-transparent for me. Were you using tray-background?

It works for me even when using tray-background (if tray-background is set, it takes precendence over background and is used instead of it) or tray-transparent (which will cause the tray to become 100% transparent)

I tried with and without tray-background, and it just gives me an opaque color. With #BB222222 I get the color #191919.

What window manager, desktop, distribution are you using? You're using the default config except for changing the background color, right? I can't reproduce this here.

Using bspwm, Arch Linux, default config with background = #BB222222 results in this:

Hmm, are you setting a background image? I use feh --bg-fill /path/to/desktop/background.jpg

Yeah, using nitrogen. The rest of the bar looks like

Awesome! I think we're done. I'm going to wait a week on NBonaparte's for feedback but after that we'll merge this.

After only 17 months we have finally merged this!

@bennofs, thank you so much for all your hard work, we really appreciate it. This is a really exciting feature to have!

Would you be available to help out if problems arise with this feature?

Thanks! You can ping me in any issues related to this.

Awesome! Let's hope we won't need to ;)

@patrick96 @bennofs Finally, congratulations.

Thank you so much for this!

Thank you guys for your work!

Thank you so much for this!! @bennofs you are amazing!

Looks like setting an offset x value for the tray breaks the transparency :

Can confirm. @bennofs any idea how to fix this? I was able to get transparency back by adding the offset to both the x and y arguments here (cairo_set_source_surface(*m_context, *surface, -x, -y);). But that gives me the background of wherever the tray would be without offset. Is it even possible to get the background for areas that are not covered by the bar?

I will look into this when I have time (probably right after new year, possibly earlier)

No rush :)

Looks like setting an offset x value for the tray breaks the transparency : example

The example file seems to have gone away. Can you restore it / upload to github?

@bennofs Also, here's a config with which I can reproduce the issue:

[bar/example]
width = 90%
height = 40
radius = 20.0

bottom = true

background = #99000000
foreground = #dfdfdf

border-size = 4
border-color = #dd000000

padding-left = 0
padding-right = 2

modules-left = title

tray-position = right
tray-padding = 2
tray-background = ${self.background}
tray-offset-x = 20
tray-offset-y = -20

[module/title]
type = internal/xwindow

[settings]
pseudo-transparency = true

; vim:ft=dosini

Ok. What exactly is the intended behaviour of that? The space that is "left over" due to the x/y movement should be filled with the bar's background as well?

I think the intended behavior should be that the whole tray has a transparent background even the parts that do not overlap the bar window.

I think the gap that the tray leaves doesn't need to be filled.

Should be fixed by #1571