Closed ghost closed 3 years ago
Since this PR from this series will probably require some discussion, I’ll ask here about the rest of what I currently have on mine
. Do you want these commits upstream? (Fwiw, I don’t use either of them in my config yet, maybe because they weren’t as important for me to take advantage of.)
.editorconfig
file (5a6d147c50666de7ece6ebebf19a909260e8e826), for I have 2 spaces by defaultAbout the PRs:
I'm currently thinking about an API for the z-axis, specifically since that's going to be relevant with the new rendering API, and I'm not quite sure what the best way to approach that is. I think something like top, bottom (absolute) and above and below another view would be the most flexible and still very simple. The downside would be that if you want something to be second-from-top for example you would need to keep a reference to the top-most view, though I personally don't think that's much of an issue, as I think that use case won't be very common anyways.
Any ideas from your side?
Either way, thanks a lot for the PRs, I was actually just discussing usable_area with a friend!
Whats disgusting about clear color? imo thats better way to have background color handled through compositor because swaybg have to render it as separated thing in whole bottom surface which wastes 30mb of ram! (thats not a lot at all) and makes a bit non sense to me because rendering special surface only to get clear color through swaybg/paper/azote is pointless.
- .editorconfig: sure, doesn't hurt to have it
- verbosity control would be great, that was lost somewhere when I converted my TODO list apparently, haha
PR’d.
- default background: background is actually not handled at all rn. The clear color is disgusting on purpose, so I can easily tell when something is going on in the future, though I'm not doing any fancy damage tracking that could go wrong anyways rn
Makes sense. Though I wouldn’t call that dark grey disgusting.
I'm currently thinking about an API for the z-axis, specifically since that's going to be relevant with the new rendering API, and I'm not quite sure what the best way to approach that is. I think something like top, bottom (absolute) and above and below another view would be the most flexible and still very simple. The downside would be that if you want something to be second-from-top for example you would need to keep a reference to the top-most view, though I personally don't think that's much of an issue, as I think that use case won't be very common anyways.
Any ideas from your side?
Seems good. I’ll think about it and let you know if I come up with anything. That means this PR will be closed and potentially reused, right?
kiwmi:{top,bottom}_view()
and view:view_{above,below}()
could help.
Either way, thanks a lot for the PRs, I was actually just discussing usable_area with a friend!
Let’s just hope our ideas don’t collapse too often so we don’t duplicate our efforts.
@HeavyRain266 I wonder if you have anything against solid-buffer if/when it gets merged.
@HeavyRain266 I wonder if you have anything against solid-buffer if/when it gets merged.
I would like to see it, setting clear color with stupid vulkan in your compositor is about 350 loc...
I'll probably close this for now, yeah.
Background stuff I'd probably merge for now, we can always rethink stuff later when it actually matters.
This PR disables auto-raising views on focus;
view:focus()
could get an optional argument defaulting to true.It doesn’t solve
desktop_active_output
possibly returning a wrong output. It would mean messing with the code around to get access to the seat, so I haven’t done it yet. I can do it if desired.(this is another PR from
tiosgz/mine
, commit 48439b31cd3746c1026f12a1dca9fbec7ab6071b)