Comment by ~joe-getcouragenow on ~eliasnaur/gio
i use mage and afero for exactly these reasons on other golang and non golang projects and its really great. give you agnostic base and makes it much easier to onboard new devs on any os
Comment by ~joe-getcouragenow on ~whereswaldon/arbor-dev
https://github.com/tailscale/tailscale-android/blob/master/Dockerfile
Its pretty easy to copy the output from the guest to the host. But there is an excellent golang tool that does all of this in local and CI for you. Cant find it right now. Will come to me...
Ticket created by ~joe-getcouragenow on ~whereswaldon/arbor-dev
Can we use docker for the android build. Just such a PITA to get android and its tooling going.
tailscale do it this way and its a joy for teams and also CI.
https://github.com/tailscale/tailscale-android/blob/master/Makefile#L35
Comment by ~joe-getcouragenow on ~eliasnaur/gio
Its cool. I will have a look and post back here on progress, questions etc.
Comment by ~joe-getcouragenow on ~eliasnaur/gio
:) well thanks for letting me know.
Any feelings about where the problem could be, before i start hunting for the source of the bug ?
Comment by ~joe-getcouragenow on ~eliasnaur/gio
The sqlite tool that translates c to go has now reached beta and actually works. This transpiler is a likely candidate for doing the same with hafbuzz
https://www.reddit.com/r/golang/comments/hyenjh/cgofree_sqlite_databasesql_driver_for_linuxamd64/
Here is the generator: https://gitlab.com/cznic/sqlite/-/blob/master/generator.go
Ticket created by ~joe-getcouragenow on ~eliasnaur/gio
This is the only working example that i could find to show tinygo being used to compile golang to WASM for browsers
Its all here:
https://github.com/vugu/vugu/blob/master/devutil/tinygo-compiler.go
- https://github.com/vugu-examples/tinygo/blob/master/devserver.go#L24 is copying the dependencies across explicitly.
- https://github.com/CosmWasm/cosmwasm/issues/448 explains why it was done this way. Basically to get around the fact that tinygo cannot handle go.mod.
Which uses: https://github.com/vugu/docker-vugu-tinygo-dev
- this does nothing special and is just a convenience.
This is the example that shows it:
https://github.com/vugu-examples/tinygo
- Calls to tinygo-compiler.go at https://github.com/vugu-examples/tinygo/blob/master/devserver.go#L16
I plan to have a go at this approach, but wanted to let others know also as they may have their own thoughts on this.
It would be cool to get this working as the WASM code will go from 8 MB to 400 KB in general for basic projects.
Ticket created by ~joe-getcouragenow on ~eliasnaur/gio
In the kitchen example on IOS Safari the touch events now work.
The input events dont work. For example when the user types in the "Hint" area, no virtual keyboard comes up on the mobile.
Comment by ~joe-getcouragenow on ~eliasnaur/gio
Thanks so much. I just tested the kitchen example on IOS Safari and the touch events work.
Everything seems to work pretty well. The input events dont work. For example when the user types in the "Hint" area, no virtual keyboard comes up on the mobile. I will raise an issue for this for now.
I agree that the runtime performance is not great. Getting the obvious bugs fixed will allow me and others to experiment with getting it working with Tinygo. Being able to write a GUi app in golang for web is still a huge win for gophers in many ways still.
Download size can be reduced using compression. This compresses the WASM file using brotli https://github.com/ctessum/cityaq/blob/master/gendoc.go#L34 Kitchen.wasm goes from 7 MB to about 1 MB. Not a bad win.
About tinygo. Here is the only example i could find where tinygo works for golang wasm: https://www.vugu.org/ Code: https://github.com/vugu-examples/tinygo Docker: I suspect that this is the dockerised version of Tiny go that is being used by this example.
Again thank you for the fix.
Comment by ~joe-getcouragenow on ~whereswaldon/arbor-dev
Go-Flutter and Flutter in general is very impressive. Things really work.
- Video does not work... Which is sad.
- When google changes stuff the go-flutter teams fixes things.
GIO is literally the exact same architecture and way way closer to the metal. Hence why my interest in GIO :) Not as many plugins, but way easier to develop.
Its a game of tradeoffs as always, so here goes:
The way i use them. You can code up all your plugins in go and use them for desktop, mobile and Web ( as wasm). So then the community can use them with gio and flutter. Thats my intent. Some projects need flutter some need gio and give people choice. The plugins can have a DB, Event source changes to the GUI layer to update for real time apps.
Hope this helps.
I am much more into GIO because i find using it much faster. But GIO web on mobile does not work properly, hence why i am trying to get that fixed with the Team.