Hacker News new | ask | show | jobs
by meindnoch 1280 days ago
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…
3 comments

There's no reason Rust toolkits can't use separate windows for elements like menus and tooltips, and I know this is planned for at least some of the toolkits discussed in the post.
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 extra area or should that menu be a separate "window"? And, what does being a "window" even mean?

Add into that the fact that we really should be making multithreaded GUI systems at this point and it's very clear that GUIs are stuck in a local minimum that's really hard to get out of because GUI systems require so many lines of code.

Window resizing works perfectly fine on macOS if you use the native AppKit framework. It’s only when you try to embed a whole different world (Qt, GTK, Flutter, Electron) in your window via an opaque OpenGL/Metal surface that things break/lag/distort on resizing the window, which again is another reason to stay away from these cross-platform GUI shims.

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.

What you are talking about has nothing to do with custom vs native controls. Instead it's a question of using a single or multiple windows.

There are Rust GUI toolkits like Druid with custom controls that have elements outside the bounds of the main window.