What problem are you trying to solve?
As I now know, Ink does not support any form of compositing (overlays). I became baffled a little by the overlay components (drawer, modal etc) not behaving as you imagine they would -- before realising that it's impossible for those to work in that way on top of Ink, and there is of course not really anything this project can do about that...
Meanwhile (I imagine this is part of the reason for OpenTUI now being offered :) ) OpenTUI can do real compositing and thus the OpenTUI-flavour termcn components designed for overlaying on other content, can truly be used like that.
However, on the face of it, when looking at the docs for the overlay components, its not immediately clear that you can't actually use those as "overlays" when on Ink, and that they must exist in the "flow". Thus, naive people like me or their agents can quite easily be accidentally mislead and set about the wrong path for them.
Proposed solution
Some or all of:
- A short note in
llms.txt about this.
- A note in
Introduction in the docs or possibly even a new page, "Supported Frameworks" that outlines the tradeoffs in the context of this library. Personally I think it's a big enough deal to perhaps lean towards a loose OpenTUI recommendation but that is a choice for you.
- A note/banner on each overlay component docs page that makes this limitation clear. Perhaps linking back to the note in the intro section.
- I'm not currently using the MCP yet but hypothetically doing something there makes sense too. Especially if the call suggests the user is about to add an Ink flavoured overlay component.
And....thats it :). Hopefully I can help the next guy with this.
Alternatives considered
No response
What problem are you trying to solve?
As I now know, Ink does not support any form of compositing (overlays). I became baffled a little by the overlay components (drawer, modal etc) not behaving as you imagine they would -- before realising that it's impossible for those to work in that way on top of Ink, and there is of course not really anything this project can do about that...
Meanwhile (I imagine this is part of the reason for OpenTUI now being offered :) ) OpenTUI can do real compositing and thus the OpenTUI-flavour termcn components designed for overlaying on other content, can truly be used like that.
However, on the face of it, when looking at the docs for the overlay components, its not immediately clear that you can't actually use those as "overlays" when on Ink, and that they must exist in the "flow". Thus, naive people like me or their agents can quite easily be accidentally mislead and set about the wrong path for them.
Proposed solution
Some or all of:
llms.txtabout this.Introductionin the docs or possibly even a new page, "Supported Frameworks" that outlines the tradeoffs in the context of this library. Personally I think it's a big enough deal to perhaps lean towards a loose OpenTUI recommendation but that is a choice for you.And....thats it :). Hopefully I can help the next guy with this.
Alternatives considered
No response