This means that there's now a canonical script that allows other
distributers to build Browsh. The only caveat being that the web
extension cannot be built (Mozilla only allows one signed `.xpi` per
version), so it is downloaded.
This is the wrong way round, it should default to binary as that's what
most of the OS's are and just set the zip override for `darwin`.
Watch this issue for updates:
https://github.com/goreleaser/goreleaser/issues/720
This means that Browsh can now be entirely run just by running the CLI
binary. The client launches Firefox as a subprocess, then connects to it
via the Marionette protocol, installs the webextension and finally
triggers a new tab with, currently, the Google homepage in it.
I was trying to set this up for automated testing as well by installing
the built webextension as a temporary addon, because otherwise you need
to sign the extension everytime with a unique semantic version. However
for some reason I can't quite recreate the environment that MDN's
`web-ext` creates. The extension installs fine but fails to load the
`content.js` script, I can't find a backtrace or any other details about
the failure. So for now, we're just going to have to use `web-ext` as
seperate process and have the client connect to that. Which is what one
should do during development anyway, so it's not a huge loss.
After weighing up the options it seems that Golang's termbox-go TTY
library has better support for terminals, and it's cross-platform out of
the box. So this commit is the first working version where the
interfacer launches a websocket server, makes a connection to the
webextension and listens to STDIN from the CLI, sending all input to the
webextenstion.
Using JS's `getComputedStyle()` for every character is too CPU
intensive, so instead I'm experimenting with using a custom font
to take the canvas snapshot. The font is made up of only the unicode
block character, which basically fills the entire space given to a
monospace glyph. This also means that we can fairly reliably work out
the visibility (whether it's obscured or hidden with CSS) of text.
This proves that frames can be generated on Firefox using the canvas and
a Tree Walker to examine text nodes. Already with little optimisation
frames don't ever take longer than 200ms to render.
Chrome has a MediaStream of the viewport, hopefully that will prove
performant as well.
This doesn't have functioning text colour detection or text occlusion
support. But early research suggests this will possible by comparing 2
screenshots: one with and the other without rendered text.
The big problem with XFCE's zoom was that it follwed the mouse. So there was no way
to have the terminal representation of the desktop map to a smaller segment of the
real desktop without the terminal mouse position being able to exactly 'hover' over
the real mouse position.
The xzoom program is a window that displays a zoom of a portion of the desktop. So
double the width of the desktop and place the xzoom window on the right, but have
it watch only the half of the desktop on the left. What's more xzoom is small and
it's C code is easily incuded in the Golang code so they act as one, even sharing
state such as mouse coords, viewport position, current zoom level, etc.
WIP. Still contains old XFCE zoom code.
Thomas Buckley-Houston