Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Layers #61

Open
4 tasks
nic-hartley opened this issue Oct 20, 2023 · 0 comments
Open
4 tasks

Layers #61

nic-hartley opened this issue Oct 20, 2023 · 0 comments
Labels
k: feature small increment to existing bits p: tuig-ui tuig-ui crate s: ui user interface

Comments

@nic-hartley
Copy link
Owner

It's really common in other textmode/terminal games to pop up a window over top of other things currently on screen. More generally, I want to implement a concept of Regions being able to split into "layers", where you can have as many as you like, stacked on top of each other. Open questions;

  • What order are they drawn in?
    • Bottom to top: Probably the order most people will think in, most clearly reflects the "stacking"/"overlaying". Very convenient if you want the positions of things in higher layers to depend on the positions of things in lower ones.
    • Top to bottom: Enables passthrough much more easily (if a region is marked "empty", and input goes there, hand it over to the next layer; otherwise, don't) and potentially some pretty big optimizations (though actually implementing them will probably have to wait for Refactor UI #59); plus,
    • All at once; Probably really really hard to implement, at least in an efficient way. The closest I can get to imagining this is some sort of "mask" which records the height of the layer that last wrote to it and discards writes from lower layers, but... (a) that means a bunch of extra memory used, and (b) that's a lot of overhead to put on what would otherwise be a plain write. Plus, Action lifetimes suddenly become a much bigger pain to manage.
  • Can input "pass through" from a higher layer to a lower one?
    • Pro: Enables some neat UI things, e.g. being able to do "picture in picture" without actually blocking any UI elements
      • Caveat: You could already do a lot of this just with normal regions, and in particular, layers being per-region means you can always do a layer over one region and then your inputs to the side -- not the same but probably not half bad neither
    • Con: Letting input fall through pretty significantly increases the implementation complexity, and adds a couple potential footguns that would have to be mitigated/documented real carefully
  • Are there any handy optimizations we can enable?
    • e.g. if you use layers exclusively to implement modals without passthrough, maybe there should be a way to "save" the screen contents and then just re-render them as a "static image" below your top layer, or even as a background within it
    • this should already be possible with the included tools but it could be made much easier
  • What's the cleanest API to implement this? In particular, how can we avoid needing to resort to callback hell?
    • Something like let (layer: Region, rest: Region) = region.peel() might be doable (where lifetimes ensure that layer doesn't get used after peel starts getting touched, maybe, somehow?) but if layers are going to go in a fixed order, then it'll probably be important to ensure there's only one at a time, which is... complex
      • Maybe let (layer1: Region, rest: Rest) = region.peel(); let (layer2, rest) = rest.peel(); let final: Region = rest.top() so that the peel can avoid "containing a &mut", and only the layer / final do, preventing them from coexisting? is that possible?
  • Probably more that I just haven't thought of yet at 01:22 in the morning.
@nic-hartley nic-hartley added s: ui user interface k: feature small increment to existing bits p: tuig-ui tuig-ui crate labels Oct 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
k: feature small increment to existing bits p: tuig-ui tuig-ui crate s: ui user interface
Projects
None yet
Development

No branches or pull requests

1 participant