Earlier quoted context omitted.
This. It’s so lame when UI elements can’t hang outside the bounds of the window (i.e. menus, tooltips, dropdowns, popovers) because everything is rendered like a game…
The problem right now the separation of concerns for GUIs is a complete shitshow on ALL platforms. Even such "simple" tasks as how to composite a window, a video in that window, and a floating menu over that window are not very well specified in any OS (try resizing that window and watch the fun). Or, for example, your floating menu--should the parent window resize itself and paint with transparent pixels in the extr…
I don’t really see the reason for multithreaded UIs either. A single UI thread works perfectly fine if you move your business logic off to a separate thread. Most people are just too lazy to do that, and start developing their app with the business logic running synchronously on the UI thread; which works for a while, but eventually reaches a point where it starts blocking the UI event loop; then they try bandaging it by moving certain pieces to a background thread and they shoot themselves in the foot with thread-safety issues. The way to solve this is not by making the UI framework multi-threaded… Simply be disciplined with UI ↔ business logic separation from the get go and all these problems go away. Yes, I know it’s so tempting to call the database directly from the button click handler - but don’t do it.