[GH-ISSUE #236] opentui dotnet support #829

New issue

Closed

opened 2026-03-14 08:42:51 +03:00 by kerem · 4 comments

kerem commented

2026-03-14 08:42:51 +03:00

Owner

Originally created by @moutansos on GitHub (Oct 27, 2025).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/236

Not really an issue, more of just some questions and figured I should start a conversation. Right now I have a fork of the repo and I'm (slowly) working on building out dotnet bindings. My goal is to match feature parity with the TS bindings in the core package. I've got a few different ideas for projects and would like to use this to build them but with C# instead of TS or go. I'm mostly through getting the FFIRenderLIb built out and have basic stuff drawing to the terminal properly. Here are my questions:

Are you guys interested in me contributing back these bindings? I'm planning on maintaining them in the fork no matter what anyway but figured if there was interest I could contribute them back.
Is there anything I should know roadmap wise to avoid porting or are there any methods deprecated as of right now?

If you are interested in merging these in eventually I'd be happy to provide maintenence for them moving forward, especially as I'd be using them for my own projects, but my time is admitedly limited.

Link to the fork: https://github.com/moutansos/opentui/tree/dotnet-add

Thanks for your time!

Originally created by @moutansos on GitHub (Oct 27, 2025). Original GitHub issue: https://github.com/anomalyco/opentui/issues/236 Not really an issue, more of just some questions and figured I should start a conversation. Right now I have a fork of the repo and I'm (slowly) working on building out dotnet bindings. My goal is to match feature parity with the TS bindings in the core package. I've got a few different ideas for projects and would like to use this to build them but with C# instead of TS or go. I'm mostly through getting the FFIRenderLIb built out and have basic stuff drawing to the terminal properly. Here are my questions: 1. Are you guys interested in me contributing back these bindings? I'm planning on maintaining them in the fork no matter what anyway but figured if there was interest I could contribute them back. 2. Is there anything I should know roadmap wise to avoid porting or are there any methods deprecated as of right now? If you are interested in merging these in eventually I'd be happy to provide maintenence for them moving forward, especially as I'd be using them for my own projects, but my time is admitedly limited. Link to the fork: https://github.com/moutansos/opentui/tree/dotnet-add Thanks for your time!

kerem closed this issue

2026-03-14 08:42:56 +03:00

kerem commented

2026-03-14 08:43:02 +03:00

Author

Owner

@kommander commented on GitHub (Oct 27, 2025):

I am happy to see bindings to other languages and will support and promote that.

Given that we already have Go and Vue as unmaintained fragments in the monorepo, I will probably remove them and keep only what is officially supported, which would be react and solid on top of the bun/ts bindings. Language bindings can then live in their own repos, so I am also not a bottleneck for merges etc.

The native API is very much in flux still. The core rendering parts with the renderer.zig and buffer.zig are mostly stable and didn't change much in the last months. Text rendering is heavily under development currently, so I cannot guarantee stability there.

That said, there is a release.yml workflow that creates a GitHub release with prebuilt binary artifacts, which could be used by language bindings and bindings could then lock that version and get something working, migrating to newer versions when possible. The pipeline needs some love though to set that up properly, so it creates a GitHub release when an npm release is triggered via tag and a GitHub draft release for snapshot npm releases.

All that said, again, I am happy to support other language bindings, just not in the monorepo to not block one or the other way.

@kommander commented on GitHub (Oct 27, 2025): I am happy to see bindings to other languages and will support and promote that. Given that we already have Go and Vue as unmaintained fragments in the monorepo, I will probably remove them and keep only what is officially supported, which would be react and solid on top of the bun/ts bindings. Language bindings can then live in their own repos, so I am also not a bottleneck for merges etc. The native API is very much in flux still. The core rendering parts with the renderer.zig and buffer.zig are mostly stable and didn't change much in the last months. Text rendering is heavily under development currently, so I cannot guarantee stability there. That said, there is a release.yml workflow that creates a GitHub release with prebuilt binary artifacts, which could be used by language bindings and bindings could then lock that version and get something working, migrating to newer versions when possible. The pipeline needs some love though to set that up properly, so it creates a GitHub release when an npm release is triggered via tag and a GitHub draft release for snapshot npm releases. All that said, again, I am happy to support other language bindings, just not in the monorepo to not block one or the other way.

kerem commented

2026-03-14 08:43:07 +03:00

Author

Owner

@moutansos commented on GitHub (Oct 28, 2025):

Absolutely that makes a ton of sense to keep the bindings separate. In a separate repo I might even be able to automatically cook up a draft PR when a release is cut in this repo, bump the pinned native dependencies and that'd give me a starting point to test and implement the changes version to version. All that said I'd need to catch up and reach at least parity with the buffer/renderer side of things before I could probably get something like that set up.

So if I'm reading you correctly, step one of all that sounds like taking a look at the release pipelines and get those working and producing native libraries for downstream projects to consume

@moutansos commented on GitHub (Oct 28, 2025): Absolutely that makes a ton of sense to keep the bindings separate. In a separate repo I might even be able to automatically cook up a draft PR when a release is cut in this repo, bump the pinned native dependencies and that'd give me a starting point to test and implement the changes version to version. All that said I'd need to catch up and reach at least parity with the buffer/renderer side of things before I could probably get something like that set up. So if I'm reading you correctly, step one of all that sounds like taking a look at the release pipelines and get those working and producing native libraries for downstream projects to consume

kerem commented

2026-03-14 08:43:12 +03:00

Author

Owner

@kommander commented on GitHub (Oct 28, 2025):

Yes, the main culprit was auto generating a c header for the abi in lib.zig, there are tools to do that, I didn't get to look into details yet. Might have to be maintained manually for a while.

@kommander commented on GitHub (Oct 28, 2025): Yes, the main culprit was auto generating a c header for the abi in lib.zig, there are tools to do that, I didn't get to look into details yet. Might have to be maintained manually for a while.

kerem commented

2026-03-14 08:43:17 +03:00

Author

Owner

@msmps commented on GitHub (Jan 7, 2026):

We're focusing the main opentui monorepo on only @opentui/core, @opentui/react, and @opentui/solid. Language bindings should be maintained as independent repositories.

See #489 for details

@msmps commented on GitHub (Jan 7, 2026): We're focusing the main opentui monorepo on only **@opentui/core, @opentui/react, and @opentui/solid**. Language bindings should be maintained as independent repositories. See #489 for details