Won't display background

[Justinzobel]

> xlunch --background ~/Wallpapers/Tesla1.jpg
Error getting entries from stdin.
Reverting back to system entries list.
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile

[PMunch]

That is just a warning, it shouldn't affect the drawing of the background image. What kind of image is it? Does it have transparency? What does your settings look like?

[budRich]

I'm having the same issue. I have tried with both jpg and png and --rootwindowbackground. Also tested with --desktop, and with and without compositor (picom). just shows grey solid bg. If a nonworking path is specified the background is black.

I have libpng 1.6.37 installed on Arch linux (btw).

Program looks awesome otherwise. Really digging the desktop and recurse features. Hope this issue gets resolved.

[budRich]

Aha! If the backgroundcolor key is set in the config, the color will be shown. Either comment backgroundcolor out, or set the last two characters to '00' (backgroundcolor: FFe00000).

[Justinzobel]

OK yeah that works. @PMunch is it possible for xlunch to ignore backgroundcolor setting from the config if --background is specified? This would solve the issue.

[PMunch]

Not really, that is a feature and not a bug. The idea is that you might want to have a background created dynamically, but apply a colour over it to make text more legible. For example if you don't have a compositor you could grab a screenshot and set that as the background, and then add some colour on top of it. But this should probably be documented better as even I forgot that was a thing when looking into this issue..

[PMunch]

Added a note in the documentation: https://github.com/Tomas-M/xlunch/commit/645ac408ad90a4aef9de3d98512cfeabe84b1de7

[Justinzobel]

Makes no sense but it's your software.

[PMunch]

Why not? The user has specified that they want to draw an image and a background colour, the only question is really which order they should be drawn in: colour then image (with potential holes in the image that are filled with the background colour), or image then colour (like it is today). The reason it's the latter is because normally you won't obtain an image dynamically that has transparent holes in it. And if you are creating the image yourself then you might as well colour in the holes like you want. So the latter option makes more sense as it can be used as I mentioned earlier to apply a tint to the image that's chosen as background (for example if you have a folder with multiple backgrounds and want to apply a tint to make text more easily readable, or if you grab it dynamically). I think it makes perfect sense to do it this way instead of ignoring the users wishes and removing a feature. But it is good that this is now documented a bit better, as I agree that it might be a bit confusing.

[Justinzobel]

I as the user didn't specify that a colour should be drawn, it's pre-set in the configuration file.

On Mon, Jan 13, 2020 at 7:52 PM PMunch notifications@github.com wrote:

Why not? The user has specified that they want to draw an image and a background colour, the only question is really which order they should be drawn in: colour then image (with potential holes in the image that are filled with the background colour), or image then colour (like it is today). The reason it's the latter is because normally you won't obtain an image dynamically that has transparent holes in it. And if you are creating the image yourself then you might as well colour in the holes like you want. So the latter option makes more sense as it can be used as I mentioned earlier to apply a tint to the image that's chosen as background (for example if you have a folder with multiple backgrounds and want to apply a tint to make text more easily readable, or if you grab it dynamically). I think it makes perfect sense to do it this way instead of ignoring the users wishes and removing a feature. But it is good that this is now documented a bit better, as I agree that it might be a bit confusing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Tomas-M/xlunch/issues/110?email_source=notifications&email_token=AAKOQBIEZTUP543JXVZMJTDQ5QXFFA5CNFSM4J6JUHIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIYAMUA#issuecomment-573572688, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKOQBJQN6MW55R7WRXILGTQ5QXFFANCNFSM4J6JUHIA .

[PMunch]

It's pre-set in the default configuration, but you are free to create a new one that overrides all the options. You as a user have chosen not to do that and instead build upon the default configuration.

[Justinzobel]

Run time options should override user options which should override defaults.

[PMunch]

And it does, but the background option does not override backgroundcolor because they are two different options that can be used separately or together for different effects.