-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plasma/KDE - stacking order and position issues #4
Comments
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
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 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 |
Also, see this issue, as it may be related. I changed the default values for |
I am unable to install KDE in a |
I have the same problem @jpope777 described. I tried every single option from |
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 |
#17 (recently fixed) may be related to the issues described here. Let me know if any of the fixes in |
I had issues with plasma too but they're a bit unrelated: varlesh/xwinwrap#1 |
@aaahh that is extremely helpful. I will just implement this in GLava itself, see
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
Ultimately, GLava should be able to position itself accordingly without |
attempt to fix jarcode-foss#4
Try mmhobi7@d0fcb35 |
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. |
set the window type to desktop |
|
@ephemient and workspaces are still broken with GLava on the desktop (the topic of this issue)? |
If @aaahh's attempted fix using |
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 |
Stacking order issues may be solved with |
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 |
Haha jokes my WM is broken, I remember it working before but again I don't remember |
Pinning issues should be fixed in
I'm not sure how these approaches will actually effect KDE and need testing. The first might do nothing, or further confuse the WM. The second will definitely keep GLava above desktop windows, but I'm not sure if it will also be placed above regular windows as well. @ujjwal96 @jpope777 @ephemient @flying-sheep please report if the |
I finally got KDE running in a container (after a jumping through a few hoops). I found a solution, but the above attempts just make the problem worse because:
I discovered some strange things:
All this crazy nonsense when it comes to how the WM behaves with desktop windows in order to get the plasma shell to behave the way KDE developers want. Ideally, only the plasma shell should be subject to this treatment, probably with a KDE-specific property set on the window. So I thought I should try |
And it turns out the fix for click-through that @aaahh provided works like a charm on KDE! I think I'm going to enable clickthrough by default. At the moment, you will want the following options for KDE (in addition to defaults):
This should finally conclude this issue. Don't use real |
The latest changes to |
Testing this further, it looks like "Show Desktop" ( Turns out KDE has some (undocumented?) protocols: I had to dive into the source of KWin and |
Continuing the troubleshooting we've been doing on Reddit, I have more information after testing the latest
I copied the I've also used the following params at the bottom of
Happy to help troubleshoot more when possible, and I hope I am not doing something wrong myself either. I've also recorded a quick video demo which shows the behaviour with these latest tests. Note that I am using KWin with compositing on, in a VM with a GeForce 1050Ti host GPU, and |
@scar45 see my reply to you on reddit:
Also, note:
Setting these flags with the |
I am quite sure I didn't do that. I just edited the conky file according to this.
Window type set to desktop actually makes conky not transparent for me. Back to Glava... I took this to
Now, I did the same in glava, after I commented out the requests in my rc file. I even recopied the configs. I noticed that whatever I do, wmctrl doesn't do anything to glava. |
The conky config you linked is precisely what GLava does/allows, look at the hints themselves.
Note that if you are using You didn't really specify what the problem with GLava's window was. Is it not visible, or is it just stacking issues again (ie. stuck under wallpaper)? If it's not visible to do off-screen placement, I have noticed that KDE saves window positions and will happily ignore where applications initially map their windows to. You can work around this at the moment with
That's weird. You should verify it's setting the atoms properly with |
@wacossusca34 well again, seems to me that GLava is treated a bit differently. Glava shows fine for me. I can click through, it is above (not fullscreen stuff). I just pointed out that wmctrl doesn't apply rules to it. |
@RaitaroH you might want to try |
@wacossusca34
Keeping everything the same.... but changing window typing:
So after all that I can say that... dock is the least intrusive but if you want glava to stay on top of fullscreen stuff you need to have it appear in the |
@RaitaroH unfortunately "above" windows are going to have X11 and/or WM limitations, especially with fullscreen windows that use the If you want anything to be visible above fullscreen windows it will need to maintain focus in most (if not all) WMs. To do this, you will need to use a less-than-optimal solution, but I have already written it into GLava since I expected some people would want forced focus: #request setfullscreencheck false
#request setforceraised true
static void raise(struct glxwin* w) {
XClientMessageEvent ev = {
.type = ClientMessage,
.serial = 0,
.send_event = true,
.display = display,
.window = w->w,
.message_type = ATOM__NET_ACTIVE_WINDOW,
.format = 32,
.data = { .l = {
[0] = 1, /* source indication -- `1` when coming from an application */
[1] = 0, /* timestamp -- `0` to (attempt to) ignore */
[2] = w->w /* requestor's currently active window -- `0` for none */
}
}
};
/* Send the client message as defined by EWMH standards (usually works) */
XSendEvent(display, DefaultRootWindow(display), false, StructureNotifyMask, (XEvent*) &ev);
/* Raise the client in the X11 stacking order (sometimes works, can be blocked by the WM) */
XRaiseWindow(display, w->w);
XFlush(display);
}
At this point I'll make two
The latter suggestion is undeniably the best option here, but it's something better suited to external utilities ( edit: also see added |
It's worth noting some users have ran into placement issues on KDE when KWin tries to re-position GLava when its window is mapped, probably from some saved position. This is fixable via |
Is there a way to get transparency working on KDE (KWin)? |
Your config is totaly working, I got some workaround though. If using KDE, there is a section in KDE settings called Window Rules. Try to make changes there and set the window type to ! in rc.glsl and set the window type there, it shall fix the problem. I setted to dock(pannel), it works perfectly except above all desktop icons. for my condition. |
Doing the above does work, but glava then won't correctly detect when it's fully obscured, so performance may suffer in that case. |
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.The text was updated successfully, but these errors were encountered: