Now, it's possible to compile to Windows (`-target windows`) without
having `windres`. The PNG icon, manifest and version info will be
generated and include using `gogio`.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Similar to the Android, which includes all .jar files into the .apk.
Now, the `gogio -target js` will include all `*_js.js` files
into the resulting `wasm.js`.
That change make possible to adds custom wasm-imports, which might
be used in future versions of Gio.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Now, gogio can build the program for Windows, using the `-target
windows`.
It will build with `-H=windowsgui`, by default. Also, it can compile for
multiple platforms if specified using `-target` (e.g. `-target arm, 386,
amd64`), the executable will have the respective suffix (i.e.
`_386.exe`).
gogio will also attach (any) appicon.png as executable icon resource and
include some information about the file and supported operating system.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
A previous change converted the package argument to gogio to an absolute path.
However, gogio supports all package paths that may appear in Go import statements.
For example, the path "gioui.org/cmd/example/kitchen" should not be converted.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The Fairphone 2 only supports OpenGL ES 2.0, but otherwise seems
capable of running Gio. By lowering the minimum requirement, Gio apps
will be available in the Play Store for Fairphone 2 devices.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before users were limited to only use a appicon.png in the root directory.
Now the user is free to use any png anywhere on the system with the help of the -icon flag.
Signed-off-by: Axel Paulander <axel.paulander@gmail.com>
The Gio GioAppDelegate created the GioViewController programmatically.
When using gogio's -buildmode=archive users may want to use a different
method (for example storyboards) but there can only be one app delegate.
Move the GioAppDelegate to gogio's exe buildmode, and export the
GioViewController for embedding use.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
If the Android NDK is not found in a standard location (e.g. you are
on an F-Droid build server), check the $ANDROID_NDK_ROOT environment
variable.
Signed-off-by: Greg Pomerantz <gmp.gio@wow.st>
First, use wineboot instead of winecfg to set up the WINEPREFIX. It's
the right tool for it.
Second, when initialising WINEPREFIX, use output pipes instead of
CombinedOutput. The latter will wait for *all* output to be copied to a
buffer, including the output from grandchildren processes. Since wine
starts wineserver automatically, and wineserver lingers for three
seconds by default, this is bad. We would waste three seconds waiting
for wineserver doing nothing, and then the next wine call (to start the
app) would need to start wineserver all over.
Instead, with pipes we can get cmd.Run to only wait for the parent
process to finish. wineserver stays running but we don't care. And, when
we start the gio app, we very likely reuse the same wineserver process.
Third, disable wine-gecko and wine-mono. This ensures we don't get stuck
if they're not installed, and speeds up wineboot by avoiding work we
don't need.
The time to set up WINEPREFIX goes down form ~6s to ~1s, and the overall
subtest run-time goes down from ~10s to ~3s.
Finally, copiously document all of the precious data I've gathered above
after hours of debugging.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Fix a long-standing TODO: instead of each sub-test handling its own
output separately, just make each expose its output via an io.Reader.
Then, the shared driverBase code can tell if any of the lines contain
the magic "gio frame ready" string.
Reduces the amount of code a bit, but most importantly, it keeps the "is
a frame ready?" logic in a single place.
In the future, this also enables us to do more with all the e2e test app
output consistently. For example, we might want to add a -debug flag to
always log output lines as they happen.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
This way, if the user has a custom winecfg, it can't possibly affect the
tests. I was encountering this as DXVK does not work on virtual Xorg
servers (which we use), and Gio thus failed to render on such a
combination.
>From the numbers below, it can be seen that setting up a new WINEPREFIX
takes roughly five seconds:
$ rm -rf ~/.cache/gio-e2e-wine
$ go test -run EndToEnd/Windows
PASS
ok gioui.org/cmd/gogio 16.369s
$ go test -run EndToEnd/Windows
PASS
ok gioui.org/cmd/gogio 11.810s
A repeated run still has a slow "wine winecfg /?", for some reason. Add
a TODO since I can see it taking a third of the time on my terminal. I
haven't been able to properly investigate why, unfortunately. As far as
I can tell, winecfg is just faster when run with a terminal instead of
an output buffer. They might use isatty on stdout/stderr.
The overall time to run the wine sub-test is increased from ~5s to ~11s,
but it's worth it to make it run everywhere. It looks like there is
plenty of room as per the TODO above, as winecfg seems to mostly do
nothing. We're also not too worried, as all e2e subtests run in
parallel.
Fixes#106.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
This way, a Gio app's logs can be filtered uniquely, which wasn't
possible before since the tag "gio" would be the same between gio apps.
Since the app ID is supplied at build time, inject it via a variable
with the linker's help. The variable is only used on Android for now,
but that's OK. It might be useful for other platforms or other internal
packages in the future.
Fixes#84.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
While launching an app on Android, the hard-coded theme is used for
the color. That color is by default black, and results in a jarring
transition to the actual app background.
The default Gio color is white, so use that for the theme background
as well.
This change will break for "dark mode" programs and similar. A future
improvement would be to reflect the actual app background in the theme.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Not strictly necessary, but makes embedding a Gio Android Activity
easier; adding
<activity android:name="org.gioui.GioActivity"
android:theme="@style/Theme.GioApp"
android:configChanges="orientation|keyboardHidden"
android:windowSoftInputMode="adjustResize">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
should be enough.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Installing it on Debian was enough, with the only wrinkle that
propagating -race won't work when we're cross-compiling, since
cross-compilation disables CGo by default.
For now, just skip the test in that edge case. If we want to use the
race detector on Windows in the future, we need to get a Windows CI
builder somehow.
Tested on my fork; see https://builds.sr.ht/~mvdan/job/164899.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Since Wine is heavily tied to X11, we build its end-to-end test driver
on top of X11's. We use the same mechanism to start an X server, take
screenshots, and issue clicks.
Its only quirk is that it was difficult to get the screenshots to line
up with Gio's window. The comments cover what we ended up with. The
display dimensions are now part of driverBase, so that methods other
than Start can also use them - this is necessary for the wine driver to
crop screenshots.
We also use a sleep for now; a comment explains why, and a TODO is left
for future Dan to deal with. What we have now works, and I've spent
enough hours on this patch as it is.
Adding Wine to CI, and ensuring that the test passes there, is left for
a follow-up patch.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Elias Naur