I've seen this implementation of defer a few times now. I really dislike calling this defer (like the keyword in Go) as the given code won't be executed on return.
No no, I think you misunderstood my critic. Defer working on block-scope is fine; however, if I exit the block through a return (or break), the deferred function is not called.
To my knowledge, you need a compiler extension to implement this in C (or use a C++ destructor).
Do I understand correctly that they are building on top of wlroots? If so, I am pretty happy about this development as I might get to enjoy the solidity of XFCE apps in other WMs / compositors like Sway or River.
Yes, eventually anyway. I've done a little work on xfwm4, using wlroots, but it'll be another year or more before that's usable. For the desktop components that work on Wayland, we've mostly tested on wlroots-based compositors.
We've invested some time to improve this situation for the games we port, at least to some extent.
Keyboard input is read as a combination of scan code + win32 virtual key information to determine the physical key pressed on your keyboard.
This way the keybindings are (almost) independent of the keyboard layout.
However, we also reflect your current key bindings with dynamic button prompts that tell you which key to press in game. For this we translate the determined physical key back through the selected keyboard layout to figure out what the corresponding label on your keyboard might be.
Most of this is just win32 API shenanigans, but the following post provides a bit more detail on reading inputs this way.
I am actually quite happy with PowerToy's FancyZones [1]. It's not perfect but it's working nicely 99% of the time; although it does not tile automatically.
The newest PowerToy, Workspaces, seems to be a new sideways approach to some of the things auto-tiling is good for. I've not yet tried to learn Workspaces that well to know how well it succeeds at its new job, but it's on my TODO list.
reply