[HN Gopher] Forking Chrome to render in a terminal
___________________________________________________________________
Forking Chrome to render in a terminal
Author : fathyb
Score : 279 points
Date : 2023-01-27 15:42 UTC (7 hours ago)
(HTM) web link (fathy.fr)
(TXT) w3m dump (fathy.fr)
| anthk wrote:
| Meh, electron. I'd prefer elinks being boosted with QuickJS
| support instead of the old engine based on... Mozilla?
|
| Edbrowse uses it and it has enough JS support to even login and
| comment against JS ridden sites.
|
| https://edbrowse.org
|
| Browser, email, irc, SQL client, file manager and editor for the
| blind with an ed philosophy.
| wwarner wrote:
| I mean. This works really really well. I almost made it through a
| captcha.
| comfypotato wrote:
| Could probably zoom into the captcha with some elbow grease.
| The resolution is there if it filled the terminal.
|
| This is actually the showstopper for me with any kind of
| terminal browser. I enjoyed playing with browsh (or what was it
| called?) a few years ago, but this is much better.
|
| I wonder if my suggested workaround has any meat to it.
| kps wrote:
| Time to dig out my Wyse 50 again!
| https://chromium.googlesource.com/chromium/src/+/HEAD/docs/o...
| SirRockALot wrote:
| This is really neat. Did you consider using the full range of
| Unicode block glyphs to squeeze out a little bit more resolution
| from the terminal vs just using the half-block?
|
| https://github.com/blitzcode/term-gfx/blob/master/src/main.r...
|
| You're still just getting two colors per character, but I think
| it works quite nicely.
| fathyb wrote:
| It's a great idea, I did explore it but ended up falling in the
| dithering and Fourier rabbit hole.. I'll give it another try
| without any color tricks!
| lights0123 wrote:
| > One of the unicode characters we can render is the lower half
| block element U+2584: . Knowing that cells generally have an
| aspect ratio of 1:2, we can render perfectly square pixels by
| setting the background color to the top pixel color, and the
| foregound color to the bottom pixel color.
|
| Even better: https://en.wikipedia.org/wiki/Sixel Doesn't support
| 24-bit color though.
| fathyb wrote:
| I did write a very fast SIXEL back-end [0] with adaptative
| quantizing and GPU acceleration, but most emulators have a very
| inefficient implementation unfortunately. For example iTerm
| converts the SIXEL data to PNG, writes it to tmpdir, and
| displays it as an image you can drag and drop.
|
| I'm still exploring it thought, but as a separate program to
| run any X apps through SSH.
|
| [0]: https://news.ycombinator.com/item?id=34288262
| [deleted]
| whatever1 wrote:
| Newbie question: why the terminal cannot have full high
| definition graphics ?
| ShowalkKama wrote:
| Reminds me of https://www.brow.sh/
| dodslaser wrote:
| Super neat. If you want to go even deeper down the terminal
| graphics rabbit hole you should look into adding sixel support.
|
| https://github.com/saitoha/libsixel
| csdvrx wrote:
| And for terminals that don't support sixel yet, sixel-tmux will
| let you see them:
|
| http://github.com/csdvrx/sixel-tmux
|
| For example with Windows Terminal:
| https://raw.githubusercontent.com/csdvrx/sixel-tmux/main/exa...
|
| OP, if you want to keep your current solution, check how going
| beyond unicode halfblocks can help:
| https://github.com/csdvrx/derasterize
| wing-_-nuts wrote:
| This is really cool. Is it supported on the framebuffer
| terminal as well?
| [deleted]
| azalemeth wrote:
| This is both genuinely very impressive and also brings me hope
| that I can finally use Microsoft SSO only services natively in
| the console...
| sramsay wrote:
| Hadn't thought of that. Take my money!
| randall wrote:
| This is the coolest shit ever.
| synergy20 wrote:
| xterm + w3m can browse with images for me.
|
| kitty + w3m is getting there as well.
| michaelmior wrote:
| I'm incredibly impressed with how smooth this is. (And how small
| the Docker container is!) I might actually use this for real
| things.
| rubatuga wrote:
| Absolutely insane engineering. Hope this is an alternative to
| elinks
| realworldperson wrote:
| [dead]
| sylware wrote:
| What we actually need would be a full-blown modern javascript-
| enabled browser written in simple and plain C (c89 with benign
| bits of c99/c11), namely with a compile-time/runtime object model
| suited for the "web".
|
| I good start: re-use the parsers from netsurf, get mr Bellard and
| friends quickJS... and then the ez part: get 748392749324732984
| full-time devs full for 748937489234 centuries in order to get
| such engine working... BUT it is not finish since, once
| "working", you will have to play catch up with blackrock/vanguard
| financed web engines and everything they will do to break compat
| with your engine.
|
| Some ppl are still trying with rust? servo something?
| anthk wrote:
| QuickJS it's being used in the edbrowse terminal browser and
| it's good enough to login and post on a lot of web sites.
| sylware wrote:
| Been a user of it for a while now. But don't worry, where it
| was used to work, well... it usually do not last very long:
| it feels like there is active work done to "break" any
| alternative from vanguard/blackrock financed javascript-able
| browers from "working".
| rightbyte wrote:
| Ye the problem is the web sorta standard themself. A never
| ending bloat race that you need 100s of programmers to keep up
| with.
|
| Thatcher is by design and I guess Google is mainly to blame by
| now.
| sylware wrote:
| Well geeko/webkit and blink are all financed by the big tech
| controlling funds. webkit(apple) and blink(google=alphabet)
| are own and steered by those same ppl.
|
| Oh, and those ppl own and steer microsoft too, and some
| wonder why those are using blink now. I do ask myself how
| long they will keep webkit and blink since they have already
| geeko to feint the anti-trust laws.
|
| But your are right, they made the "Standard" so insanely
| complex on top of the core noscript/basic (x)html, that it
| "works" only in their implementations with their armies of
| devs.
|
| This is accutely toxic for humanity. The only "real" ways out
| of this: restore noscript/basic (x)html where it is still
| doing a good enough job, and if a "new" web has to be born:
| an implemention must be something reasonable in time/skills
| and efforts for a small team of devs.
| igneo676 wrote:
| Huh, built on electron. I wonder how difficult it would be to
| bolt this onto vieb and have the ultimate vim-terminal browser
| oldgradstudent wrote:
| Next step: vscode on the terminal.
| yuck39 wrote:
| Install the VIM plugin and we go full circle
| SeanAnderson wrote:
| My jaw is on the floor. I would've been fully impressed with the
| unoptimized version, but pushing it to squeak out significant
| rendering performance improvements was a surprise treat!
___________________________________________________________________
(page generated 2023-01-27 23:00 UTC)