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

Upstreaming plans? #40

Open
davidchisnall opened this issue Mar 8, 2022 · 2 comments
Open

Upstreaming plans? #40

davidchisnall opened this issue Mar 8, 2022 · 2 comments
Labels
question Further information is requested

Comments

@davidchisnall
Copy link

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
Copy link
Owner

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

@ggerganov ggerganov added the question Further information is requested label Mar 8, 2022
@davidchisnall
Copy link
Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants