After some investigation, it turns out that both Alpine and Arch suffer
from the same bug - their packages completely lack SwiftShader.
The current workaround is still the best that we have right now. But at
least we can actually provide a good explanation why, and a TODO to
improve this once the issues filed with the distros are fixed.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
For example, if the browser doesn't have webgl at all, the gio app will
fail to load. This will result in the screenshot being incorrect,
without an apparent reason:
--- FAIL: TestJSOnChrome (0.89s)
js_test.go:122: got 0xffffffffffffffff at (5,5), want 0xffff00000000ffff
js_test.go:122: got 0xffffffffffffffff at (595,595), want 0xffff00000000ffff
The underlying webgl error was accessible if one added a sleep and ran
'go test -headless=false', allowing to open the console and see the
error messages.
Instead, capture them via chromedp and print them to the test's logger:
--- FAIL: TestJSOnChrome (0.89s)
js_test.go:79: console log: "2019/10/29 12:41:07 app: webgl is not supported"
js_test.go:79: console warning: "exit code:", 1
js_test.go:122: got 0xffffffffffffffff at (5,5), want 0xffff00000000ffff
js_test.go:122: got 0xffffffffffffffff at (595,595), want 0xffff00000000ffff
JS Exceptions are a completely different mechanism, so they're not
covered by this patch. We can add them at a later time if needed.
While at it, update to the latest tagged version of chromedp.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
The `gogio` tool adds the `-fmodules -fobjc-arc` flags to the Cgo
C flags. Unfortunately, that masks problems where Cgo packages
accidentally didn't have the flags in their #cgo directives such
as package log.
Move the flags so they're only explicitly mentioned when `gogio`
invokes the host compiler to build the `main.m` shim.
Fix package log to include the missing flags.
While we're here, silence OpenGL ES deprecation warnings on iOS, just
as we do for macOS. The warnings are normally not visible because
the gogio tool suppress output from the go tool.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
First, add a headless boolean flag that defaults to true. That way, one
can run 'go test -headless=false' to, for example, see how Chrome runs
the webassembly endtoend test.
Second, skip the Chrome test if the browser isn't installed.
While at it, run 'gofmt -s' on the package.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Package ui is now only about units except for the Config.Now method.
Remove Now and rename Config to Converter. Add layout.Config to
replace the old ui.Config.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit adds the first fully end-to-end test. It builds a very
simple Gio app, loads it on Chrome, and checks that it works.
To control Chrome, we use chromedp, a library in pure Go that takes care
of starting the browser and talking to it via the devtools protocol.
We add the test directly in the cmd module, since it mainly interacts
with the gogio tool, and also because the code might turn into some sort
of 'gogio test' command in the future. This does add chromedp and ui as
test dependencies to go.mod, but GOPROXY should allow a 'go get' of
gogio to not download their entire source code archives.
We don't replace ui with ../../ui in the go.mod, to ensure that testing
the cmd module works from anywhere without unintended differences.
The test app being used is inside a testdata directory, to ensure it's
not go-gettable, and that it doesn't otherwise affect the cmd module.
Finally, the test itself is pretty simple. The app just paints a red
background, and the test verifies that, once loaded, the background of
the browser viewport is indeed red.
The test does currently require Chrome or Chromium to be installed,
which is fine for now. It may also require a GPU, though I don't have a
headless machine to check for sure. The test uses Chrome in headless
mode though, so it doesn't open up any visible browser window.
All in all, the test succeeds in just over a second on my laptop with
Chromium 77.0.3865.75.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
The `gio` name clashes with a widely deployed GNOME tool.
Rename our tool to `gogio`, "the go tool for gio programs".
Fixes gio#20
Signed-off-by: Elias Naur <mail@eliasnaur.com>
I was seeing an extra newline when some errors were printed, like:
$ gio foo
please specify target
$
The source of the little bug was a trailing newline in the error
messages. Printing the messages already adds a newline.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Use the Go import path to create an appID based on the domain name
plus the last directory location in the import path.
Signed-off-by: Greg Pomerantz <gmp.gio@wow.st>
Since the main README recommends Go 1.13 or later, let's make the go.mod
files reflect that. This will enable starting to use new language
features.
Modules that still build on 1.12 will continue to work on that version
just fine; this line is just a hint to enable new language features for
versions of Go new enough.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
First, vet was upset by two incorrect fmt verbs. One was an extra %x,
when there was just one argument, so remove it. Another was a %p with a
non-pointer. It's a struct, so for now simply use %#v.
Second, staticcheck found some unused or unnecessary bits of code;
remove the obvious ones.
Finally, staticcheck also complained about some error strings which were
capitalized or had periods. Adjust those, which also makes all error
messages more consistent.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
While we're here, split the usage print out to its own function and
don't display the usage when a package is missing.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
If there is an appicon.png file in the main package the gio tool
will use it for Android and iOS apps in buildmode exe.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Daniel Martí