jarcode-foss
Plasma/KDE - stacking order and position issues
Setting the xwintype to 'desktop', glava only shows on the active workspace when the program is initially run. Also, clicking on the desktop outside of the glava 'window' causes it to disappear. It'll still be running just not visible.
OS: Arch
KDE Plasma: 5.11.5
Running glfw-x11-git out of the AUR.
Setting the xwintype to 'desktop', glava only shows on the active workspace when the program is initially run.
This is seemingly just how KDE Plasma handles desktop windows, they belong to a workspace (which might be an EWMH compliance issue, but the spec isn't clear on this). Do separate workspaces in KDE also have their own desktop icons?
Also, you can try to play around with window types other than "desktop" in GLava, as a temporary fix. I will research a way to get it to persist across workspaces later, when I get around to installing KDE.
Also, clicking on the desktop outside of the glava 'window' causes it to disappear. It'll still be running just not visible.
This is strange. This is almost certainly the desktop windows that KDE provides being reordered when you click them (ie. you are focusing the desktop background and it gets stacked over GLava), as if they are operating in their own layer for stacking windows -- but this makes no sense for desktop features!
A solution for KDE might just be to add code in GLava to make it run (optionally) as an actual KDE widget, since it looks like Plasma behaves weird in general.
I added a #request addxwinstate <state> directive that can be used to further tweak how the GLava window behaves. See https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336 for details of what this (should) tell your WM.
Specifically for KDE Plasma, try:
#request addxwinstate "above"
#request addxwinstate "sticky"
As an attempt to solve both of your issues.
In the future, I may add an #request embed option (and command line flag) that automatically detects the WM in use and adds the specific state/type xwin requests behind the scenes, but I need to play around with other WMs a bit first.
Also, see this issue, as it may be related. I changed the default values for setfloating and setfocused to false in the default copy of rc.glsl, as it's unessecary and seemed to cause issues with some WMs.
I am unable to install KDE in a systemd-nspawn container, preventing me from testing this myself. If someone else could play with addxwinstate values and other requests on KDE, it would help me address this issue.
I have the same problem @jpope777 described. I tried every single option from addxwinstate and some combinations of the options, including the suggested, but to no success. problem persists in the exact same manner as the original problem. I have also tried setting setxwintype to other options, but still nothing.
It looks like I will have to write GLava as an actual KDE widget to get it to work correctly.
probably better would be a wallpaper engine, because i don’t think you can maximize widgets. like widgets, the engines work by writing QML and usually a DataSource. QML also has a few ways to include custom OpenGL code
another way would be to create widgets from the modules, which would forego the glava config in favor of the config GUI that KDE users are accustomed to.
a third option is to get in touch with the KDE devs. they’re friendly, responsive, and helpful, and will try to help you to get your approach to work (or give you a friendly and well-reasoned explanation why it can’t)
@flying-sheep thanks for your input. I will start with trying to get in touch with people that work more closely with KWin on IRC (or mailing lists).
Note: KDE 5.12+ supports Wayland -- if you are using Wayland instead of X11, you will run into numerous issues with transparency, window hints, etc. Try to avoid using the Plasma (Wayland) session when providing details on this issue, the aforementioned problems are separate from the problems mentioned here.
#17 (recently fixed) may be related to the issues described here. Let me know if any of the fixes in unstable or for the 1.3 release are fixed with the relevant commit.
I had issues with plasma too but they're a bit unrelated: https://github.com/varlesh/xwinwrap/issues/1 Anyways, if it's still broken, one fix is to parent glava under the Plasma window (which contains wallpaper and clock) An example of this is here: https://github.com/Aaahh/xwinwrap/blob/master/xwinwrap.c#L245 sadly xwinwrap won't work on glava, as it creates a window that glava would have to output to, instead of editing glava's window, i'm working on it
@Aaahh that is extremely helpful. I will just implement this in GLava itself, see xwin.c for how GLava handles most X11-related tasks (other X11 code can be found in glx_wcb.c, but that is mostly for creating the OpenGL context).
xwinwrap probably doesn't work because you would need to perform some (possibly terrifying) hacks to redirect the GLX context to the new window it creates. I wouldn't worry about it not working with GLava.
Unfortunately this will have to wait until at least Monday, though.
Well I use it with mpv for example, as I can set the WID with a flag on mpv
I’m tweaking the code to modify the existing window rather than create one that is then passed. I already have code to modify an existing window and with XReparentWindow I can easily move it to the place I want
@Aaahh GLava (by default) will attempt to create a direct GLX context. This is probably why it's not working with xwinwrap. See the documentation from Khronos for ARB_create_context:
Direct rendering is requested if <direct> is True, and indirect
rendering if <direct> is False. If <direct> is True, the
implementation may nonetheless create an indirect rendering context
if any of the following conditions hold:
* The implementation does not support direct rendering.
* <display> is not a local X server.
* Implementation-dependent limits on the number of direct
rendering contexts that can be supported simultaneously are
exceeded.
Use glXIsDirect (see below) to determine whether or not a request
for a direct rendering context succeeded.
Ultimately, GLava should be able to position itself accordingly without xwinwrap, so it's best if you either look to implement a solution in xwin.c or wait until I do so.
Try https://github.com/Aaahh/glava/commit/d0fcb3512d6325f9a68ffabe5af999c24573ae80
If anyone can comment on whether @Aaahh's fork fixes the issue, it would help me decide whether to keep poking at this issue or to just close it.
No visible difference with @Aaahh's branch or not.
@ephemient and workspaces are still broken with GLava on the desktop (the topic of this issue)?
If @Aaahh's attempted fix using XReparentWindow doesn't actually seem to fix the problem here, I will probably omit that code for 1.5. Calling XReparentWindow might confuse some window managers anyway, as the window will already be reparented once to the associated frame window created by the WM.
I just tried @Aaahh's branch and GLava still disappears whenever I left click on the desktop on the setxwintype set to desktop.
@jpope777 For the sake of experimentation https://github.com/Aaahh/xwinwrap Download that and run it with xwinwrap -ovr -s mpv https://www.youtube.com/watch?v=TV1767i8X4Q
Also, clicking on the desktop outside of the glava 'window' causes it to disappear. It'll still be running just not visible
I was having a similar problem with a terminal visualizer. Setting window_type to "utility" using devilspie seemed to work for me
Setting the xwintype to 'desktop', glava only shows on the active workspace when the program is initially run.
This was fixed for me using devilspie's (pin)
@ujjwal96 This is great, I'll load Plasma over the weekend or some time and try implementing a proper fix into glava Glava also suffers with multiple displays on ubuntu
I was having a similar problem with a terminal visualizer. Setting window_type to "utility" using devilspie seemed to work for me
@ujjwal96 does setting the window type to "utility" within GLava also fix the issue? These should affect the same property.
This was fixed for me using devilspie's (pin)
Looking into how devilspie pins windows, I finally found a solution for issues with multiple workspaces via the EWMH standards! Apparently, I missed this portion of the specification:
_NET_WM_DESKTOP desktop, CARDINAL/32
Cardinal to determine the desktop the window is in (or wants to be) starting with 0 for the first desktop. A Client MAY choose not to set this property, in which case the Window Manager SHOULD place it as it wishes. 0xFFFFFFFF indicates that the window SHOULD appear on all desktops.
So a simple client message may fix a wide range of workspace-related bugs. Apparently wmctrl can do this as well if you move a client to desktop of ID -1 (underflow).
@wacossusca34 Yes, setting window type to utility fixes the first issue.
For pinning you can see https://github.com/GNOME/devilspie/blob/e3431f18c11a1a80fd846c899a3f16aa5ee91de0/src/actions.c#L380-L384
It uses libwnck
The above commit allows the following line to pin GLava to all desktops:
#request addxwinstate "pinned"
The changes are non-breaking and don't affect anyone not using this option so I made the changes immediately to master, but they are untested. If @ujjwal96 or @jpope777 could report if this issue is fixed by the above commit, I can finally close this issue and look at creating an option in GLava that automatically sets all the needed X11 atoms and window types for the underlying WM.
Stacking order issues may be solved with #request addxwinstate "below", as mentioned in #54, due to the hint sometimes placing desktop windows in the same stacking order as other normal clients. If this works for kwin, then this issue can be finally closed!
I thought I didn't have a problem with this so it might be my install but "below" does literally nothing. I used to use it and it used to work but I can't be certain. My xwinwrap works perfect with below so I'm blaming glava. Using any window type