This change permits gomobile to build iOS applications by properly
set GOOS=ios in the build process. The change is locally tested on
darwin/arm64, and golang.org/x/mobile/example/basic can be build
using the following commands:
gomobile build -target=android -o=basic.apk \
golang.org/x/mobile/example/basic
gomobile build -target=ios -bundleid=org.golang.gomobiletest \
-o=basic.app golang.org/x/mobile/example/basic
The built binaries are also tested on iOS 15 beta7 and Android 12 API31.
Updates golang/go#47952Fixesgolang/go#47238
Change-Id: Ibf40a77933ac957640c78d0dbc1af043477e4b3a
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/346150
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
A paint.Event now has an External field. Whenever a paint event is
sent by the x/mobile/app package, it is marked as external so users
with an active paint loop can ignore them.
Implemented on OS X and Android, with examples updated.
Change-Id: Ibee8d65625c8818ff954936be48257ad30daa147
Reviewed-on: https://go-review.googlesource.com/15480
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
All OpenGL functions are now methods on a Context interface. The
gl.Context matches the one loaded into thread-local storage in C.
For mobile apps, the context is owned by an app.App. For now, it is
provided through the events channel on a lifecycle event. Long-term,
it should probably be available by a method on app.App, but this is
inherently racey with our current use of a channel to deliver events.
Shiny-based programs will have a gl.Context associated with a each
shiny.Window. The expectation is each Window will have different
contexts, allowing them to draw separately.
Change-Id: Ie09986fb74e493129f2ea542a151c95c6fa29812
Reviewed-on: https://go-review.googlesource.com/13431
Reviewed-by: Nigel Tao <nigeltao@golang.org>
It is now the user's job to track the lifetime of a glutil.Image
relative to a (currently implicit, soon to be explicit) GL context.
This is an attempt to move glutil.Image closer to the model for
buffers and textures in shiny. Long-term, I would like to adopt that
model, and this is a step in that direction. It also makes the
introduction of *gl.Context possible, so this is a pre-req for
cl/13431.
Change-Id: I8e6855211b3e67c97d5831c5c4e443e857c83d50
Reviewed-on: https://go-review.googlesource.com/14795
Reviewed-by: Nigel Tao <nigeltao@golang.org>
More than a name change, the painting model changes so that the app, not
the library, is responsible for driving painting. If the app is
animating and wants paint events at 60 Hz, it has to ask for that. If
the app is not animating and doesn't need to update its screen, it
shouldn't get any paint events.
Plenty of TODOs, and this CL doesn't get us to a perfect place, but it
is a checkpoint along the way.
The darwin_*.go code changes were minimal. I don't even have a Mac or
iOS device to test that this even builds. Even so, the TODOs about not
sending paint.Events unconditionally are important TODOs. That's the
whole point of switching to this model. I'll leave the actual
implementation to you (crawshaw).
Out of all the example apps, the change to example/network/main.go is
probably the most interesting.
It seems like there ought to be some way to reduce the copy/paste
between all of the example app code, but I'll leave that for future CLs.
Change-Id: I17e11c06174110c68e17f7183b2d8af19b6a170e
Reviewed-on: https://go-review.googlesource.com/14300
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Higher-level widget or animation libraries should probably work in
geom.Pt, but pixels instead of (1/72s of) inches seems a better fit for
lower-level event libraries. Needlessly converting from (float32) pixels
to (float32) points and back can be lossy and lead to off-by-one errors.
Change-Id: I68102e36f2574b07b44c6a1b7281f4f27f9174cf
Reviewed-on: https://go-review.googlesource.com/13002
Reviewed-by: David Crawshaw <crawshaw@golang.org>
In the long term, a lot of this package should be removed in favor of the
golang.org/x/image/math/f32 package. The latter is the common location for
matrix types shared across graphics libraries. For example, the
golang.org/x/image/draw package refers to golang.org/x/image/math/f64.
Change-Id: I9d7ccd3cb35912e0d9dc5bd46c919516ea840340
Reviewed-on: https://go-review.googlesource.com/11856
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Ashley Mensah
Hajime HoshiandGopher Robot
Russ CoxandGopher Robot
Changkun OuandHajime Hoshi
David Crawshaw
Nigel Tao
Hana Kim