GLava occasionally not visible as a startup application in XFCE4

[grublordgithub]

Have tried using it through cron, systemd, and .config/autostart, but none of them are persistent after reboot.

[mmhobi7]

I’m guessing that you need to add a sleep or delay on glava so that xfce has time to initialize first

[grublordgithub]

This fixed the problem, though Apport still throws a "System Program Problem Detected." Thanks for the suggestion!

[jarcode-foss]

This is a known problem I have personally run into, but proper solutions vary based on the distro and WM. As @aaahh mentioned, a delay is a suitable workaround for the time being.

Ideally, I should have glava itself wait on a window manager to be provided on the active display instead of needing workarounds like this, and since it seems to be a problem outside of my WM, I will reopen the issue.

[mmhobi7]

To be honest I feel like there should be a flag or a callback from these window managers once their all set up, but a quick fix I can think of is so

When the window cannot be found (which I think happens) then glava should run a while loop until it is, with a timeout of say a minute

[mmhobi7]

I can try implementing this in a week or so,
Before I do so I would hope that you can get the clean up code of Window so I can finish the update glava when config updated

[jarcode-foss]

@aaahh yeah, sorry about being absent from this project. I'll dedicate a bit of time now.

[jarcode-foss]

The above commit to master should fix the issue, although I can't test it on my own WM since GLava seems to startup properly without the fix now. It's mostly a load-order problem, so the problem might not even be reproducible.

@grublordgithub please test the master branch without @aaahh's delay fix and report if the above commit works.

[grublordgithub]

It didn't seem to work with the delay clause removed, though that could be on my end. Here's what the .desktop file in my .config/autostart looks like:

[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=Glava
Comment=Audio Visualiser
Exec=glava
OnlyShowIn=XFCE;
StartupNotify=false
Terminal=false
Hidden=false

[jarcode-foss]

@grublordgithub what exactly is happening to GLava when you try to start it like this? Does it appear to be running in the background? Can you manually bring it to focus with wmctrl?

[grublordgithub]

It doesn't appear at all in wmctrl -l and wmctrl -R glava shows nothing. I'll trying switching a few of the flags in the desktop file and see if that works.

[grublordgithub]

If I have terminal set to true and hidden set to false, it shows the program running, but the visualizer doesn't show up on my desktop.

[jarcode-foss]

@grublordgithub so the window doesn't appear at all, but glava still runs? That's really odd, since XCreateWindow should exit with an error if it fails in GLava, and XMapWindow can't fail unless the window is invalid (and would also crash).

This leads me to believe the X11 window exists but the window is not being managed under XFCE's client list (see _NET_CLIENT_LIST of the root window). What is the output of xwininfo -tree -root | grep GLava?

[grublordgithub]

0x2000002 "GLava": ("GLava" "GLava") 247x47+0+0 +555+546 is the output. And I'm not sure if this issue is correlated, but when I run glava after boot and click or drag on the desktop, the visualizer completely disappears.

[mmhobi7]

Wait so you can see the visualizer, it just doesn’t react to audio? And clicking elsewhere sends glava behind the xfce window? (Disappear)

[grublordgithub]

I can't see the visualizer unless I run it in a terminal after boot. And then when I click on the desktop it disappears and I can't bring it back into focus.

[jarcode-foss]

@grublordgithub it's likely related, if you weren't getting stacking issues (desktop/root window on top of glava) normally. The information you have provided clearly indicates that XFCE is not managing the glava window.

This might actually be an XFCE bug. I did notice my _NET_SUPPORTING_WM_CHECK doesn't consider hanging properties from a previous window manager if only the WM was restarted (and not X), so make sure you are restarting X completely to test glava as a desktop startup entry. In the meantime I will alter the check to handle WM restarts.

[grublordgithub]

I have been running a full hardware reboot on my computer whenever I test the startup entry, and if it's at all useful I can upload my rc.glsl.

[jarcode-foss]

@grublordgithub Do you get similar issues with starting other applications? Try making an entry with glxgears instead (provided you have it installed).

[grublordgithub]

That runs fine on boot, but it starts in it's own dedicated window, rather than against the desktop.

[jarcode-foss]

@grublordgithub does starting glava as a regular window remove the problems?

[jarcode-foss]

I'm going to try testing these problems in Xephyr in a container with XFCE4.

[grublordgithub]

Starting it as a regular window does eliminate the problem, but then it isn't persistent across desktops.

[jarcode-foss]

This still points to a bug with XFCE4, but this makes things weirder:

• XFCE4 creates _NET_SUPPORTING_WM_CHECK and is capable of managing windows once this is defined

• UNLESS it's a desktop window, in which case it pretends it's not a real client and doesn't add it to its client list

• However, none of the above matters if a script sleeps enough for XFCE4 to start up completely.

If this is correct, this is probably some niche bug in XFCE4, but I'm going to continue testing this myself.

[jarcode-foss]

I was not able to reproduce your issue by:

• Running a systemd-nspawn container with an up-to-date XFCE4 install from the Arch repos
• Starting Xephyr for a child X11 instance with software (llvmpipe) rendering, but not starting a window manager in it.
• Started GLava prematurely. It waits for a window manager to start, as I recently updated it to do. I used the default config aside from setting #request setxwintype "desktop" and #request addxwinstate "pinned". Without window pinning, GLava didn't seem to appear at all (regardless of how it was started).
• Started XFCE4 with startxfce4. GLava started immediately after without problems.
• Played some music.

My advice is to make sure you have GLava pinned, and update xfwm4.

[mmhobi7]

@wacossusca34
I’m guessing race condition, and you sir have a very fast computer,

[jarcode-foss]

@aaahh unlikely, since GLava was started (and waiting) beforehand, although still a possibility.

[grublordgithub]

I can't currently update xfwm as I'm on Xubuntu, and pinning does not seem to fix the issue of it disappearing when I click anywhere on the desktop.

[jarcode-foss]

@grublordgithub I can't get this behavior myself at all, so you definitely should compile your own build of xfwm4 if you get the chance. Just to clarify, it only gets stuck behind the wallpaper when you run it as a startup entry, right?

[grublordgithub]

It disappears regardless of when or how I run it, it would seem.

[jarcode-foss]

@grublordgithub whoops, I guess I didn't test the problem enough. I went back and managed to get it to behave this way, and sure enough xfdesktop creates a window named "Desktop" for its icons, but apparently selecting it changes stacking order between other desktop windows! This is definitely a problem with the window manager, and you should report this to xfwm4.

At the moment though, you can (ab)use some weird functionality in the window manager to fix the issue. #request addxwinstate "below" places the GLava window in the same stacking order as other normal clients, and keeps it above the desktop. I will again update the readme with this information.

[jarcode-foss]

It's possible that the above fix also fixes the original issue, as the initial stacking order of desktop windows may simply depend on which window was mapped first on startup (in which case, @aaahh would be right about a race condition).

[grublordgithub]

That does fix the issue with it going behind to desktop for me, though not the startup bug. However, I'll just be using the sleep condition at startup to fix that, which seems to make everything run perfectly. The bugs are all seemingly in my desktop and window manager, so I'll sort those out on my own end. Thank you so much for all your help, people like you are why I love open source software.

[jarcode-foss]

@grublordgithub it may be very difficult to diagnose the issue with your window manager. I would try to manually raise the window with wmctrl after startup to see if it's just a stacking issue.

[mmhobi7]

Post a list of all the windows
I think it was like wmctrl -l

[jarcode-foss]

@aaahh that will show the client list from the window manager, desktop windows won't be included by that.

[jarcode-foss]

I am closing this issue due to inactivity and the nature of the startup bug (cannot reproduce, probably related to a race condition in certain scenario(s), and not a bug in glava). The stacking order bug can be fixed with #request addxwinstate "below", which was helpful to know.

[antyung88]

This happened to me running as startup application on Ubuntu 20.04 and switches audio channels between built-in speakers and bluetooth audio.

/home/user/.config/autostart/glava.desktop

[Desktop Entry]
Type=Application
Exec=sh -c 'glava --desktop'
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=GLava

When running via cli glava --desktop switching works