Boron: conky sometimes has black background

unklar · 2023-09-16 11:21:02

Conky and the black background window.
There is no compositor running in the 32-boron!

Suggestion for change:

/home/USER/.config/bunsen/autostart

...
    ## Composition
    ## NOTE: composition must be started before tint2
    # disabled for lite system
    #bl-compositor --start

    ## Start the tint2 session (the default tint2 will run if no sessions have been set)
    ( sleep 2; bl-tint2-session ) &

    ## Start the Conky session (the default conkyrc will run if no sessions have been set)
    ( sleep 10; bl-conky-session ) &
...

Justification:
When looking for the error, you notice that Conky ALWAYS starts first, even before the tint2 bar.

Already more than 10 years ago I learned from @Sector11, Conky should appear as last application on the desktop.
In the delivered beta1 conky is BEFORE tint2 in the autostart. I changed that and, because even 4 sec. still make conky appear before tint2 bar, increased to finally 10 sec.

Thus also at these settings in the conky's nothing needs to be changed:

...
--  Window Settings
    own_window = true,
    own_window_type = 'desktop',
    own_window_transparent = true,
    own_window_hints = 'undecorated,below,skip_taskbar,skip_pager,sticky',
    own_window_colour = '000000',
    own_window_class = 'Conky',
    own_window_title = 'BunsenLabs Default Conky',
...

Please test!

johnraff · 2023-09-16 12:43:28

unklar wrote:

Conky and the black background window.
There is no compositor running in the 32-boron!

Correct. It is supposed to be a lightweight system. Of course installing and running picom is optional.

Suggestion for change:

/home/USER/.config/bunsen/autostart

...
    ## Composition
    ## NOTE: composition must be started before tint2
    # disabled for lite system
    #bl-compositor --start

    ## Start the tint2 session (the default tint2 will run if no sessions have been set)
    ( sleep 2; bl-tint2-session ) &

    ## Start the Conky session (the default conkyrc will run if no sessions have been set)
    ( sleep 10; bl-conky-session ) &
...

Justification:
When looking for the error...

I get no problem on my VM or laptop with autostart as it is. That order has been the same for some years now.

...you notice that Conky ALWAYS starts first, even before the tint2 bar.
Already more than 10 years ago I learned from @Sector11, Conky should appear as last application on the desktop.
In the delivered beta1 conky is BEFORE tint2 in the autostart. I changed that and, because even 4 sec. still make conky appear before tint2 bar, increased to finally 10 sec.
Thus also at these settings in the conky's nothing needs to be changed:
...
--  Window Settings
    own_window = true,
    own_window_type = 'desktop',
    own_window_transparent = true,
    own_window_hints = 'undecorated,below,skip_taskbar,skip_pager,sticky',
    own_window_colour = '000000',
    own_window_class = 'Conky',
    own_window_title = 'BunsenLabs Default Conky',
...
Please test!

I wonder why you got the black conky. I can't reproduce it, even without composition.
Here is my 32bit VM:

Notice the square-cornered (composition off) tint2. The conky started well before it, but with no problems. Same settings you posted above. Default conky from the iso, except I added a short system info at the top.

rbh · 2023-09-16 21:50:31

johnraff wrote:

I wonder why you got the black conky. I can't reproduce it, even without composition.

I have the same problem as unklar. Not on new installs, only on my old pc's.
I disabled composition a couple of weeks ago, (feels better for my old tired eyes).
Then, I got that black conky.
I have compared config settings with working default conkys. Can not see I have made any error...
Without compositor, conky aint transparent. It just takes the underlying color and paint that as background in the conky window.

johnraff · 2023-09-17 00:29:29

rbh wrote:

Without compositor, conky aint transparent. It just takes the underlying color and paint that as background in the conky window.

So I'm thinking that maybe on old machines nitrogen hasn't had enough time to draw the wallpaper on the desktop before conky starts? In the default bunsen/autostart the nitrogen command is not forked (no final &) so you would expect its work to be done before the next command runs. But once the desktop is drawn, on my VM it seems to remain even after a logout. (??)

What I just noticed is that if the wallpaper is changed (menu > user settings > wallpaper) then for a moment conky is still using the previous wallpaper as its background, but then adjusts to the new one. So conky is detecting a changed desktop and restarting itself?

I have to go now for 2 days but when I get back I'll test this on a real 32bit machine.

unklar · 2023-09-17 06:41:13

Conky does not require a compositor.

Therefore it is already correct to deliver this ISO without compositor.
Conky is simply too fast for these 32-bit machines and it is right to make sure that it appears as the last application on the desktop.

If we don't want the conky window to be affected by the desktop manager openbox, then in this case of the 32-bit variant all conky's should have the variable 'override'.

That would be:

	own_window_type = 'override', --normal', --desktop',

Last edited by unklar (2023-09-17 07:03:13)

johnraff · 2023-09-19 02:47:01

@unklar I'm hoping to have time today to test this out on my old 32bit laptop.

Meanwhile, could you tell me the difference between window types 'desktop' and 'override'?
The documentation is not very helpful ('dock' is not mentioned at all):

Override windows are not under the control of the window manager. Hints are ignored. This type of window can be useful for certain situations.

Thanks!

johnraff · 2023-09-19 07:05:42

I have Boron beta 1 installed on this laptop, no composition, default conky (except for RAM/Swap/CPU), tint2 and autostart settings, and... still can't reproduce the conky-black-background issue.

I wonder what's happening? Right now, all I can think of is that @unklar and @rbh have machines even older and slower than mine, or else non-standard configuration somewhere.

Comparing the inxi output @unklar posted here: https://forums.bunsenlabs.org/viewtopic … 16#p129416 with my own screenshot here:

also, at the bottom of the terminal so not on the screen:

Info:
    Processes: 114 Memory: 988.2 MiB used: 446.1 MiB (45.1%)
    Init: systemd target: graphical (5)
    Inxi: 3.3.26

The two machines seem very similar, both BIOS year 2006, CPU speed quite similar, memory too, both using Intel graphics - in general @unklar's machine looks slightly faster than mine.

I did a bit more testing:

First, the lightdm greeter sets a background image, and that remains on the user's desktop after login until nitrogen runs. So, even if 'nitrogen --restore' is commented out in ~/.config/bunsen/autostart there is a wallpaper. To remove that complication, temporarily open Menu > System Settings > Login Interface and set Background to Color plain black. Log out and in, and now there should be a plain black desktop, with conky and tint2. Now change the nitrogen line in ~/.config/bunsen/autostart to

( sleep 5; nitrogen --restore ) &

Logout/in and this time, do you see a black desktop, replaced after 5 seconds with the regular emerald-blue? And does conky get a black background, replaced after ~1sec with the correct wallpaper?

That's what I get. And, as on the VM, if the wallpaper is changed from Menu > User Settings > Wallpaper, then conky automatically corrects its own background to match, after a very short time. (No composition here, picom is not installed.)

Last edited by johnraff (2023-09-19 07:19:46)

grubernd · 2023-09-19 09:28:30

I have seen the exact same behaviour when changing display resolutions.
Sometimes dragging windows over that "zombie" area will result in staggered fragments.

Only method I found was to trigger a refresh through the wallpaper.

I have filed the issue under "workaround available, GUI stack too complex to be fixed".

unklar · 2023-09-19 09:33:20

johnraff wrote:

Meanwhile, could you tell me the difference between window types 'desktop' and 'override'?
The documentation is not very helpful ('dock' is not mentioned at all):

First, I have this statement:

If own_window is YES, you may specify type: normal, desktop, dock, panel or override. The default is "normal". Desktop windows are special windows that have no window decorations; are always visible on your desktop; do not appear in your pager or taskbar; and are sticky across all workspaces. Panel windows reserve space along a desktop edge, just like panels and taskbars, preventing maximized windows from overlapping them. The edge is chosen based on the alignment option. Override windows are not under the control of the window manager. Hints are ignored. This type of window can be useful for certain situations.
#own_window_type normal
#own_window_type desktop
#own_window_type dock
#own_window_type panel
own_window_type override

An example with both conky's and 'override' ves. 'desktop'
override_desktop-logout
override_desktop-reboot
conky left = override conky right = desktop
Here I have in the 'autostart' BEFORE the original setting again activated, so

...
    ## Composition
    ## NOTE: composition must be started before tint2
    # disabled for lite system
    #bl-compositor --start
bl-conky-session &
    ## Start the tint2 session (the default tint2 will run if no sessions have been set)
    ( sleep 2; bl-tint2-session ) &

    ## Start the Conky session (the default conkyrc will run if no sessions have been set)
    #( sleep 10; bl-conky-session ) &
...

Nevertheless appears left override immediately and right desktop further after the 10 Sec., although these are no longer set.

Somewhere the system notices this and it gets crazier and crazier the more you play around with it.

johnraff wrote:

Logout/in and this time, do you see a black desktop, replaced after 5 seconds with the regular emerald-blue? And does conky get a black background, replaced after ~1sec with the correct wallpaper?

Exact!

Last edited by unklar (2023-09-19 09:39:26)

johnraff · 2023-09-19 09:35:08

grubernd wrote:

I have seen the exact same behaviour when changing display resolutions.

Which post are you replying to here? What "same behaviour"?
My own post just above was basically saying that I couldn't find anything wrong.

Anyway, yes changing screen dimensions will mess up both wallpaper and conky - they both have to be restarted.
Conky takes its position by referring to the screen edge, and the wallpaper needs to be rescaled to fit the new screen.

grubernd · 2023-09-19 10:45:26

johnraff wrote:

What "same behaviour"?

From what I deduct and remember vaguely from testing some time ago - must have been the Lithium days - the blacked out conky and ghosts of windows over the desktop are all somehow related through some unwanted interactions in the whole GUI stack from xorg upwards. I tried a lot of things but they all boiled down to interactions and timings way above my head.

And the fix was - at least for me - always a wallpaper reset.

johnraff · 2023-09-20 01:24:19

unklar wrote:

johnraff wrote:
Meanwhile, could you tell me the difference between window types 'desktop' and 'override'?
The documentation is not very helpful ('dock' is not mentioned at all):
First, I have this statement:

Thanks - I already found this and posted above:

This type of window can be useful for certain situations.

But no hint that I could find anywhere as to what those "certain situations" might be...

---
OT: the latest docs above, and 'man conky' on Bullseye refer to a new window type "utility":

man conky wrote:

Utility windows are like desktop windows, except they appear above everything else rather than below.

This might actually be useful sometimes, although you can already get it with window hints.

---

An example with both conky's and 'override' ves. 'desktop'
override_desktop-logout https://i.imgur.com/wzHY3tCt.png
override_desktop-reboot https://i.imgur.com/VlDN4sst.png
conky left = override conky right = desktop

I have no idea why you and rbh are getting that black conky background. My almost identical laptop doesn't suffer from it, nor my 32bit VM.

Here I have in the 'autostart' BEFORE the original setting again activated, so
...
bl-conky-session &
    ## Start the tint2 session (the default tint2 will run if no sessions have been set)
    ( sleep 2; bl-tint2-session ) &

    ## Start the Conky session (the default conkyrc will run if no sessions have been set)
    #( sleep 10; bl-conky-session ) &
...
Nevertheless appears left override immediately and right desktop further after the 10 Sec., although these are no longer set.
Somewhere the system notices this and it gets crazier and crazier the more you play around with it.

I find picom can be like that too.

Anyway, since the 'lite' 32bit configs do ship their own bunsen/autostart, we could add a delay before starting the conky session (which might have multiple conkys of course), if it looks as if that would help some people on old machines. Is 10 seconds necessary though? That is an irritatingly long time to wait.

Adding own_window_type override to the default conky, might change its behaviour in some unexpected way for some users. We already know from the manual that:

own_window_argb_visual
This option will not work as desired (in most cases) in conjunction with `own_window_type override'.

So the delay might be a safer workaround - if it does actually work.

---
a few tests:

@unklar and @rbh, do any of these actions remove the black conky background and restore the wallpaper behind conky?

1) logout and back in
2) change wallpaper ( menu > User Settings > Wallpaper )
3) restart conky ( menu > User Settings > Conky > Reload Startup Session )
4) load a different conky ( menu > User Settings > Conky > Conky Manager ) then optionally restore the original conky
5) reboot

Last edited by johnraff (2023-09-20 01:31:50)

unklar · 2023-09-20 09:22:40

johnraff wrote:

unklar wrote:
johnraff wrote:
Meanwhile, could you tell me the difference between window types 'desktop' and 'override'?
The documentation is not very helpful ('dock' is not mentioned at all):
First, I have this statement:
Thanks - I already found this and posted above:
This type of window can be useful for certain situations.
But no hint that I could find anywhere as to what those "certain situations" might be...

I think this refers to the different window managers, how they place and handle windows on the desktop. The conky window is where all these hints bounce off.

johnraff wrote:

OT: the latest docs above, and 'man conky' on Bullseye refer to a new window type "utility":
man conky wrote:
Utility windows are like desktop windows, except they appear above everything else rather than below.
This might actually be useful sometimes, although you can already get it with window hints.

Here I have three conky windows.

S11 its conky on top and Teo its conky on the bottom right. Both have the 'normal' setting, which is the default. Right clicking on their windows shows me the menu.

The boron conky has the setting 'desktop'. Right clicking on the window shows nothing.

If you enter this newfangled 'utility' instead of 'desktop', you will also get the menu there when you right-click. However, you won't like it if, for example, the Thunar window is under the Conky window.

johnraff wrote:

I have no idea why you and rbh are getting that black conky background. My almost identical laptop doesn't suffer from it, nor my 32bit VM.

Create a second Conky with

 gap_x = 320,-- left | right

next to the boron conky and change the default to 'normal'; 'utility'; override etc. Play with it, do logout, reboot etc, or, KILLALL, AND you will experience the black background window.

johnraff wrote:

Adding own_window_type override to the default conky, might change its behaviour in some unexpected way for some users. We already know from the manual that:
own_window_argb_visual
This option will not work as desired (in most cases) in conjunction with `own_window_type override'.

We don't have a compositor here, though. That's what @Sector11 wrote into each configuration. Ergo, it's irrelevant.

-- NOTE that a composite manager is required for real transparency and ARGB will not

.

johnraff · 2023-09-21 05:18:09

unklar wrote:

Here I have three conky windows.
https://i.imgur.com/mfI6ij0t.png
S11 its conky on top and Teo its conky on the bottom right. Both have the 'normal' setting, which is the default. Right clicking on their windows shows me the menu.
The boron conky has the setting 'desktop'. Right clicking on the window shows nothing.

Confirmed. This is the opposite of what I would expect, in fact. Other normal windows (thunar, geany...) do not pass clicks down to the window manager, while I would hope that a "desktop" conky was transparent to clicks.

'override' and 'utility' also pass the right-click to openbox. Only 'desktop' does not (I haven't tested 'dock').

johnraff wrote:
I have no idea why you and rbh are getting that black conky background. My almost identical laptop doesn't suffer from it, nor my 32bit VM.
Create a second Conky with
 gap_x = 320,-- left | right
next to the boron conky and change the default to 'normal'; 'utility'; override etc. Play with it, do logout, reboot etc, or, KILLALL, AND you will experience the black background window.

OK on the VM created BL-Boron-conky-tmp.conf with 320 gap as you suggested, created a new conky session from menu>UserSettings>Conky>New Conky Session with those two conkys and set it as the startup session so it would reload after logins.

Set *-tmp.conf to window_type 'desktop' 'normal' 'utility' and 'override' and in each case did:
logout/in
reboot
Alt+F2 'killall conky', then conky menu "Reload Startup Session"

...in no case did I see any black conky backgrounds.

johnraff wrote:
Adding own_window_type override to the default conky, might change its behaviour in some unexpected way for some users. We already know from the manual that:
own_window_argb_visual
This option will not work as desired (in most cases) in conjunction with `own_window_type override'.
We don't have a compositor here, though. That's what @Sector11 wrote into each configuration. Ergo, it's irrelevant.

Irrelevant for the 32bit desktop (except for people who want composition), but not for the amd64 desktop which has composition and uses the same default conky config file. We could have a special conky for the 32bit iso, but it's less work for the devs to keep the number of files which have 'normal' and 'lite' versions down to a minimum.

I'll have to check if composition makes any difference to click-through behaviour on the amd64 setup.

moogleinc · 2025-02-28 13:20:15

unklar wrote:

Conky and the black background window.
There is no compositor running in the 32-boron!
Suggestion for change:
/home/USER/.config/bunsen/autostart
...
    ## Composition
    ## NOTE: composition must be started before tint2
    # disabled for lite system
    #bl-compositor --start

    ## Start the tint2 session (the default tint2 will run if no sessions have been set)
    ( sleep 2; bl-tint2-session ) &

    ## Start the Conky session (the default conkyrc will run if no sessions have been set)
    ( sleep 10; bl-conky-session ) &
...
Justification:
When looking for the error, you notice that Conky ALWAYS starts first, even before the tint2 bar.
Already more than 10 years ago I learned from @Sector11, Conky should appear as last application on the desktop.
In the delivered beta1 conky is BEFORE tint2 in the autostart. I changed that and, because even 4 sec. still make conky appear before tint2 bar, increased to finally 10 sec.
Thus also at these settings in the conky's nothing needs to be changed:
...
--  Window Settings
    own_window = true,
    own_window_type = 'desktop',
    own_window_transparent = true,
    own_window_hints = 'undecorated,below,skip_taskbar,skip_pager,sticky',
    own_window_colour = '000000',
    own_window_class = 'Conky',
    own_window_title = 'BunsenLabs Default Conky',
...
Please test!

Interesting issue! I’ve had similar problems with Conky in the past. Usually, tweaking the own_window settings in the Conky config file (e.g., own_window_type = 'normal' or own_window_argb_visual = true) helps resolve the black background problem. Hope that works for you!

#1 2023-09-16 11:21:02

Boron: conky sometimes has black background

#2 2023-09-16 12:43:28

Re: Boron: conky sometimes has black background

#3 2023-09-16 21:50:31

Re: Boron: conky sometimes has black background

#4 2023-09-17 00:29:29

Re: Boron: conky sometimes has black background

#5 2023-09-17 06:41:13

Re: Boron: conky sometimes has black background

#6 2023-09-19 02:47:01

Re: Boron: conky sometimes has black background

#7 2023-09-19 07:05:42

Re: Boron: conky sometimes has black background

#8 2023-09-19 09:28:30

Re: Boron: conky sometimes has black background

#9 2023-09-19 09:33:20

Re: Boron: conky sometimes has black background

#10 2023-09-19 09:35:08

Re: Boron: conky sometimes has black background

#11 2023-09-19 10:45:26

Re: Boron: conky sometimes has black background

#12 2023-09-20 01:24:19

Re: Boron: conky sometimes has black background

#13 2023-09-20 09:22:40

Re: Boron: conky sometimes has black background

#14 2023-09-21 05:18:09

Re: Boron: conky sometimes has black background

#15 2025-02-28 13:20:15

Re: Boron: conky sometimes has black background

Board footer