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

Support rendering web content in TUI apps - aka WebView support #2938

Open
iSeiryu opened this issue Oct 28, 2023 · 10 comments
Open

Support rendering web content in TUI apps - aka WebView support #2938

iSeiryu opened this issue Oct 28, 2023 · 10 comments

Comments

@iSeiryu
Copy link

iSeiryu commented Oct 28, 2023

Is your feature request related to a problem? Please describe.
View websites or render HTML strings inside a terminal. There are lots of potential uses for this feature. I'm not sure if it's even possible with the current state of dotnet without writing a whole new HTML rendering engine.

Describe the solution you'd like
Either incorporate one of the existing WebView controls, e.g. https://www.nuget.org/packages/Microsoft.AspNetCore.Components.WebView/ or create a new one based on some existing engine.

Additional context
Existing CLI based web browers:
https://github.com/fathyb/carbonyl
http://lynx.browser.org/
https://github.com/tats/w3m/tree/master/doc

@tznind
Copy link
Collaborator

tznind commented Oct 28, 2023

This is certainly an ambitious feature.

Implementing from scratch is not really feasible, so there would need to be a library which did all the heavy lifting (web page -> ascii, scroll, request link etc). So probably a library wrapping chromium or something. Any library/binary that is directly writing to screen e.g. with curses is going to be harder to wrap.

This would make more sense as a seperate library:

  • Avoids adding any big dependencies to Terminal.Gui
  • Isolates issues relating to web behaviours
  • Provides dedicated channel for the work

The other way to deal with this would be to have your main app exit from the Terminal.Gui main loop and run a web browser (e.g. lynx) full screen in the terminal. Then on exit re-launch the terminal gui. But that would not allow you to embed

@BDisp
Copy link
Collaborator

BDisp commented Oct 28, 2023

If you want to have an idea on how to do this here is a Blazor API done for the Terminal.Gui v1. For Terminal.Gui v2 this will not be possible anymore because the ConsoleDriver and others API's isn't exposed anymore. So as @tznind said avoids any big dependencies to Terminal.Gui. Another solution is add a new project integrated with on the gui.cs and ask to tig if it's possible to do it. Good luck.

@tig
Copy link
Collaborator

tig commented Oct 28, 2023

If you want to have an idea on how to do this here is a Blazor API done for the Terminal.Gui v1. For Terminal.Gui v2 this will not be possible anymore because the ConsoleDriver and others API's isn't exposed anymore. So as @tznind said avoids any big dependencies to Terminal.Gui. Another solution is add a new project integrated with on the gui.cs and ask to tig if it's possible to do it. Good luck.

@BDisp the OP is not asking for Terminal.Gui apps in a browser. He/she is asking for a web browser within a Terminal.Gui app.

@BDisp
Copy link
Collaborator

BDisp commented Oct 28, 2023

@BDisp the OP is not asking for Terminal.Gui apps in a browser. He/she is asking for a web browser within a Terminal.Gui app.

Ops my bad, sorry for the misunderstand.

@tig
Copy link
Collaborator

tig commented Oct 28, 2023

This is certainly an ambitious feature.

Implementing from scratch is not really feasible, so there would need to be a library which did all the heavy lifting (web page -> ascii, scroll, request link etc). So probably a library wrapping chromium or something. Any library/binary that is directly writing to screen e.g. with curses is going to be harder to wrap.

This would make more sense as a seperate library:

  • Avoids adding any big dependencies to Terminal.Gui
  • Isolates issues relating to web behaviours
  • Provides dedicated channel for the work

The other way to deal with this would be to have your main app exit from the Terminal.Gui main loop and run a web browser (e.g. lynx) full screen in the terminal. Then on exit re-launch the terminal gui. But that would not allow you to embed

I have experience with .NET Html engines as part of https://github.com/tig/winprint.

I use LiteHtml to be able to print HTML files. See https://github.com/tig/winprint/tree/master/src/WinPrint.LiteHtml

99% of the cases users of WinPrint choose fixed-pitch fonts, and thus it would not be THAT hard to use LiteHtml to be able to render to a Terminal.Gui View.

@iSeiryu
Copy link
Author

iSeiryu commented Oct 29, 2023

@tig just curious were those strings supposed to look like this or someone forgot to update them?
https://github.com/tig/winprint/blob/master/src/WinPrint.LiteHtml/LibInterop.cs#L47

The rendered pages don't have to look fancy, just get a general idea of what a page looks like and to be able to read text.
But rendering a single page is just a part of the problem. Being able to navigate between pages by clicking links is the bare minimum for the internet surfing.

Maybe the engine that https://github.com/fathyb/carbonyl uses could be an option? It seems very light-weight.

@tig
Copy link
Collaborator

tig commented Oct 29, 2023

@tig just curious were those strings supposed to look like this or someone forgot to update them? https://github.com/tig/winprint/blob/master/src/WinPrint.LiteHtml/LibInterop.cs#L47

Sorry, don't remember.

The rendered pages don't have to look fancy, just get a general idea of what a page looks like and to be able to read text. But rendering a single page is just a part of the problem. Being able to navigate between pages by clicking links is the bare minimum for the internet surfing.

Maybe the engine that https://github.com/fathyb/carbonyl uses could be an option? It seems very light-weight.

Wow. That's cool.

It's not clear to me if this is a PORT of Chromium or somehow uses Chromium??

@a-usr
Copy link

a-usr commented Nov 9, 2023

According to this carbonyl uses a modified version of the chromium headless shell

@tig
Copy link
Collaborator

tig commented Nov 9, 2023

According to this carbonyl uses a modified version of the chromium headless shell

Thinking about this more, I'm skeptical a Chromium-based solution will work well for many Terminal.Gui scenarios:

  • Huge bloat. One great things about Terminal.Gui is it has a small-ish footprint and thus can run on very constrained devices. If terminal.Gui's 'WebView' support were based on Chromium this would no longer be true.
  • Complex dependency. Similar to above, but also means setup / deployment would be tricky. Imagine if Microsoft.PowerShell.ConsoleGuiTools wanted to use WebView in some way. No way, would it be acceptable that Install-Module Microsoft.PowerShell.ConsoleGuiTools install and configure Chromium.

I'm back to the idea that WebView should be based on pure .NET based HTML engine like LiteHtml.

@tznind
Copy link
Collaborator

tznind commented Nov 12, 2023

I wonder how feasible it would be to have a view that wrapped another console process (kind of like tmux). This would allow running w3c or lynx in a view as well as solving another asked for feature which is to run a full console surrounded by terminal gui components.

I know there has been work in the past on TerminalView e.g. https://github.com/migueldeicaza/XtermSharp/blob/master/GuiCsHost/TerminalView.cs which might allow something like this (see #1244 (comment)).

@tig tig changed the title WebView support Support rendering web content in TUI apps - aka WebView support Jan 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

5 participants