drawin: Add support for the desktop layer. #3750
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3750 +/- ##
=======================================
Coverage 90.97% 90.98%
=======================================
Files 900 900
Lines 57500 57521 +21
=======================================
+ Hits 52309 52333 +24
+ Misses 5191 5188 -3
Flags with carried forward coverage won't be shown. Click here to find out more.
|
|
Hello, Thanks for this. I think there is multiple ways to implement this feature. I think the most trivial would be to expose Also, more generally, the layering code, is you noticed with the A much more labor intensive way to handling this would be to replace the hardcoded layers by recursive buckets. Where a bucket can contains either |
|
i don't think i quite understand the bucket approach. the layers are still a part of the freedesktop wm specs, aren't they? how would that still be kept? and how would you pair a client and a wibox, exactly? would it just be them having the same parent bucket? i would honestly love to implement something like that, though. i believe that a z-index-like feature would be amazing and could have many features. if you could bring me up to speed with the details that you have worked out so far, i could try my hardest to implement something like that. |
|
Comment on the general approach (whether AwesomeWM devs want this or not is for them to decide):
I'd really prefer if this gets a different name. EWMH has the layers "desktop", "below", none-of-the-rest, "dock"&"above", "fullscreen". These layers are for client windows. AwesomeWM invented "ontop" for drawins. This has a special name to make it clear that this is its own layer and one cannot mix clients and drawins (drawin above a client above a drawin within the same layer). Not-ontop drawins also get their own layer. This makes the C implementation a lot easier (as @Aproxia-dev noticed, but @Elv13 apparently did not yet?) Sadly, I do not have a good suggestion for a new name... What is the opposite of "ontop" that is not "below"?
You mean "trivial" from the Lua side, right? In C, this idea would be a nightmare to implement. The above would throw out the current way these orderings are managed and would mean that a lot of code needs to be touched. I'm not sure whether that's a good request for someone's first contribution to a project (at least I did not find your name on https://github.com/awesomeWM/awesome/graphs/contributors ). |
https://www.wordhippo.com/what-is/the-opposite-of/on_top_of.html How about Adding a new layer certainly doesn't make the layering easier to understand, but that can be fixed by an addition to the docs (or just kept as-is). |
| @@ -37,6 +37,13 @@ | |||
| -- @tparam[opt=false] boolean ontop | |||
| -- @propemits false false | |||
|
|
|||
| --- Below other windows and widgets. | |||
There was a problem hiding this comment.
What does and widgets refer to? Wiboxes/drawins are not ordered relative to widgets, are they? I'd just leave that part out
There was a problem hiding this comment.
it would probably be better to say and wiboxes or and drawins, or, as you said, just leave that part out entirely. not sure which one would be better. my bad for getting the terminology wrong lol
There was a problem hiding this comment.
now thinking about it, and drawins is probably not optimal, since there's not many places where drawins are explained in the docs, unlike wiboxes, which have a dedicated page.
| @@ -53,6 +53,7 @@ lua_class_t drawin_class; | |||
| * @field border_width Border width. | |||
| * @field border_color Border color. | |||
| * @field ontop On top of other windows. | |||
| * @field desktop Below other windows and widgets. | |||
| if(b != drawin->desktop) | ||
| { | ||
| if(b) | ||
| drawin_set_ontop(L, drawin, false); |
There was a problem hiding this comment.
This doesn't necessarily work. Lua could react to property::ontop and just set d.ontop = true again. Thus, you are not guaranteed that drawin->ontop = false after this call. I fear one would have to defer all signal emission until the end of this function to work-around this (not that the result would then look good from Lua's point of view, but at least that should ensure that at most one of these properties can be true at the same time).
I think these "multiple exclusive states"-thing also came up in client.c, but I don't know how it was handled there. I fear "not nicely"... :-(
Somehow this feels like it should be an enum, but that would break the magic behind LUA_OBJECT_EXPORT_PROPERTY. I don't have any good suggestion, sorry.
There was a problem hiding this comment.
I think these "multiple exclusive states"-thing also came up in
client.c, but I don't know how it was handled there. I fear "not nicely"... :-(
correct, i mostly copied the code over from client.c..
this probably suggests that the way layers are handled should be remade entirely lol
i do like |
i made one small pr in late october this year, but it wasn't anything difficult. probably doesn't even count lol... #3734 |
i tried reading the freedesktop wm spec so thoroughly to not get the naming wrong and yet i somehow still missed that |
Hm... this is actually a good argument against my previous argument. AwesomeWM already has such a "clash". Meh... @awesomeWM/write-access What do you think? How should this be implemented? Should this even be implemented? |
|
this patch looks quite small so i don't see a problem adding a new feature, but add some |
|
So lets start with the parts we all agree on. 1) the problem is real, 2) it is worth fixing, 3) the current layering code is confusing. I made a pull request to start dismantling the old code without actually breaking anything (I think). It would have more iterations to remove the C part of The PR is rather simple, even if it touches more code than I hoped. The old hardcoded spaghetti is converted to signals. Then Lua is responsible to assemble the final stack of drawin/clients. The current implementation copy pasted from the C code and ported to Lua inline. It still has most of the issues, but changing that would make the PR much bigger and much more complex. From there, after a few more round of cleanup to split the wm-spec atoms from the API layers, I propose to add a hook to let individual layouts implement their own stacking. The tree based layouts like layout-machi, treesome and dynamite (#644) can use the bucket thing I mentioned above while the other layouts can leave it unimplemented and use the current code.
Well, I argue it is worth throwing away :P. I started the process with #3751
Should it be implemented? Absolutely. This is actually not the first time this was mentioned like, in the past month. It's not even the second or third time. Literally, people have been hitting multiple problems on Discord. 2 of them related to the desktop layer, 1 for a drag and drop tooltip and one for creating a tabbar. Plus there are workaround in my dynamite module, layout-machine and even the main codebase. The problems are very real and affecting many people. My main issue with the original patch is that it adds more hardcoded stuff rather than solve the larger issue. It also added more public APIs which might not survive fixing the larger problem. @Aproxia-dev Sorry for the pain and extra steps. What do you think about #3751? Note that I moved |
@Elv13 I've suggested some changes, but other than that it seems really good. |
I've added support for drawins to be rendered on the desktop layer. this could be used for making desktop icon widgets, as well as wallpaper animations without directly interacting with the root window like i have done here:
we-win-these.mp4
I've also updated the documentation.