Upstreaming plans?

[davidchisnall]

Do you have plans to upstream your changes to Dear ImGui? I would like to be able to dynamically choose between a TUI and a GUI (ideally even a remote web GUI) in a single binary but that requires a single version of Dear ImGui that I can use and have different code paths to enable backend-specific configurations within my tool.

[ggerganov]

It would be pretty cool to have a text-based backend available in the original Dear ImGui. I'm all for it and also the Dear ImGui maintainer seems to be very supportive of the idea [0]. The main problem is to figure out how to avoid all these changes that are necessary to make draw data look OK in a terminal. Here is the current state of the diff:

https://github.com/ggerganov/imgui/compare/v1.81..imtui-v1.81

It's not much in terms of amount of code, but still - it is not clear how to make it compatible with the existing codebase without special-casing too much stuff.

I think, part of the diff can be reduced by implementing #25. Although it won't be enough to merge this upstream, it would be a good step forward. It's been on my TODO list for quite some time, but I keep getting distracted with other projects.

[0] https://twitter.com/ggerganov/status/1457763122131963906

[davidchisnall]

Thanks. Some of the things in the diff are guarded by WindowBorderAscii, which looks fairly non-invasive. A lot of the other bits look as if they are small displacements that could maybe be added to the style?

The approach in #25 looks interesting but I imagine that it would need some careful thought to be able to support unicode code points outside of the ASCII plane, though that seems to be broken in both simple cases (simple code points such as €) and more complex ones (combining diacritics such as 🇬🇧). The Dear ImGui docs imply that it supports UTF-8 in its strings, so I'd assumed that they worked here as well (my terminal supports UTF-8 and can render both of those correctly). Possibly it would be easier if Dear ImGui is doing code-point-sequence to glyph conversion, so you just need to provide the inverse map?