This is only the first half of physical key event mapping. The
modifiers and hardware key codes will be in a followup CL. I'm
splitting this out because it covers two other parts of the problem:
first is maintaining a JNIEnv pointer for the main routine, the
second is access to the Android unicode key map. The NDK does not have
a method to give us the key mapping, so we get to it via
GoNativeActivity.
Tested with a USB keyboard. I'll attempt an abd-based unit test later,
but I suspect it will be difficult to set a device ID.
Change-Id: Ie93700d1f2a5d382a9b17cdd668cb4acaa6e4bcc
Reviewed-on: https://go-review.googlesource.com/13649
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Also catches any bugs that cause painting to lock up after
rotation (of which there have been many).
Change-Id: I3783030efd2c342afebf2b861e9e9dc32e96f659
Reviewed-on: https://go-review.googlesource.com/13616
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Ran into this while working on keyboard events. I'm a little surprised
this hasn't been a problem so far -- my understanding of the NDK
functions for working with a NativeActivity is that the require you
hold a valid JNI context before calling them.
Change-Id: Ifd322ef5e8406df648d1a8f667e5ce08ffef954d
Reviewed-on: https://go-review.googlesource.com/13648
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
While I'm here, make pixelsPerPt local on android and darwin/amd64.
The one place where it's global is darwin/arm, which has another
similar global (screenScale).
Change-Id: I5897e7e5341afca1976fdf0215fb4f6fe2f411be
Reviewed-on: https://go-review.googlesource.com/13446
Reviewed-by: Nigel Tao <nigeltao@golang.org>
When the generation number is bumped, the <-endPaint case will drop
any old paints. So if a new paint isn't sent to replace it, the app
locks up.
This is a bug that looks like it crept into cl/12533 just before it
was submitted. (Sorry.) I'm working on tests as part of adding
android orientation support.
Change-Id: I6b62bdc6774e090b67a5577c3eae7355e3937894
Reviewed-on: https://go-review.googlesource.com/13445
Reviewed-by: Nigel Tao <nigeltao@golang.org>
There's no need for more than one Android .go file.
Change-Id: I75f5ced5680088b0ddbe5c700981b9a595d9e321
Reviewed-on: https://go-review.googlesource.com/13343
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>
This CL fixes two bugs in the existing app implementation on android.
The first, is it assumed a single NativeActivity instance is created
per process. This is not true. If you open an app, hit the back
button, then open it again, the original activity is destroyed and a
new one is created. So only call main.main in the first onCreate.
The second bug has to do with window lifetimes. Previously we only
processed GL work while the window existed, as part of a paint cycle.
This missed GL events called as part of a lifecycle downgrade when
the window was destroyed. (I.e. the contents of onStop.) This CL
fixes this by making the main android event processing loop last for
the life of the process, not the window.
Fixesgolang/go#11804.
Change-Id: Ia03e464aab5bc10ba75564b7ca11054515cda011
Reviewed-on: https://go-review.googlesource.com/12533
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Also add a few missing codes.
Change-Id: I26b6db31067c67107fe4db142ec9f48ff13cc53e
Reviewed-on: https://go-review.googlesource.com/12536
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The property was only introduced in 10.10, and doesn't offer us
anything more than what the method gives us.
Fixesgolang/go#11827.
Change-Id: I5a9f9b068b9f18acc85a68a37dae11f19df686a1
Reviewed-on: https://go-review.googlesource.com/12552
Reviewed-by: Andrey Petrov <shazow@gmail.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
First cut of events from physical keyboards.
Simple darwin/amd64 implementation.
Change-Id: I6e9d0a253387c841864ca9845ee729ea4f7573c7
Reviewed-on: https://go-review.googlesource.com/11815
Reviewed-by: Nigel Tao <nigeltao@golang.org>
EGL is a poor source of window dimensions. On some fraction of
rotations, it reported the old dimensions. Switch to extracting the
data from ANativeWindow, which appears to be more reliable.
While here, plumb through orientation, and follow the recommendation
in the Android platform docs to block onNativeWindowRedrawNeeded
until the draw is complete.
Fixesgolang/go#11741.
Change-Id: I6b29b6a1e5743c612c9af2a8cce4260c5d7e9ca6
Reviewed-on: https://go-review.googlesource.com/12381
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This is done by moving app.Context to internal/mobileinit,
introducing mobileinit.SetCurrentContext and,
making bind/java depend on it.
TODO: check gomobile bind's proguard rule - context lookup
was implemented through reflection on android.app.AppGlobals class.
Change-Id: Ieb6ad503eeef8c2c1c5836a21c667938c5a701a2
Reviewed-on: https://go-review.googlesource.com/12279
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The gl package is not safe for concurrent use.
Change-Id: Ib0e7908746ea3a6520b2ce2f5d8aa7233ab2642c
Reviewed-on: https://go-review.googlesource.com/12165
Reviewed-by: David Crawshaw <crawshaw@golang.org>
If a frame draw cycle does not end in a blocking GL call,
then the app package may process the <-endDraw before the
final <-gl.WorkAvailable, meaning some GL calls miss the
frame.
So we make sure the final GL call for a frame is blocking.
Fixesgolang/go#11696.
Fixesgolang/go#10688.
Change-Id: I39772a3308c98947b1f0838ad58d1d406a711e7f
Reviewed-on: https://go-review.googlesource.com/12123
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Subclassing NativeActivity makes two things possible. Firstly, we can
implement an InputConnection to offer good support for IMEs,
necessary for good keyboard support. Secondly, we can use it to
overlay WebViews onto the NativeActivity.
But to sublcass NativeActivity, we need to compile Java. To keep the
toolchain go gettable, this is done with go generate.
While here, check the exception after FindClass. Apparently it can
throw an exception.
Updates golang/go#9361.
Updates golang/go#10247.
Change-Id: I672545997f0c9a7580f06988a273c03404772247
Reviewed-on: https://go-review.googlesource.com/11980
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Package app contains some logic that we want to share with
gobind-based libraries. So move it to a new internal package
that both can import.
Long term the log changes should be in the standard library,
but the Go tree is currently frozen.
Fixesgolang/go#11630.
Change-Id: I9ff622fc499bf255bce18df23cb68b03f667947f
Reviewed-on: https://go-review.googlesource.com/11981
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The full set of event.LifecycleStages are now plumbed through.
More user control over the window, in particular it:
- takes focus correctly on start
- can now be closed and minimized
- can be hidden (allowing testing of LifecycleStageAlive)
Flickering during resize has been eliminated by triggering draws from
a second thread. This encouraged the introduction of a dedicated draw
loop in Go, which makes responsibility for GL calls a little more
like android/x11.
Change-Id: I63982f20bd4859601e2a27915f60f6c8083a176f
Reviewed-on: https://go-review.googlesource.com/11733
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Change-Id: Id71acfeb605995d8caf947d996a1375335410e08
Reviewed-on: https://go-review.googlesource.com/11668
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This does not break the dependency on the app package's AndroidContext
for loading assets on android. A potential answer for gobind-based
apps: add a SetAndroidContext method to app.Context. But I'll explore
that separately after the long weekend.
Change-Id: I812f899740e288c379eee7900f42d9d53926d4ce
Reviewed-on: https://go-review.googlesource.com/11675
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Historically, the app package implemented Go runtime initialization.
This was convoluted, so the package was used both by all-Go apps
(currently based on Android's NativeActivity) and bind-based apps.
With Go 1.5 we have -buildmode=c-shared, which does a lot of the work
of the old app package. That code was removed a while back, but both
all-Go and gobind-based apps still used package app. The intermingled
initialization processes led to some strange states.
This CL separates gobind-based apps completely from the app package.
As part of that users are now expected to use System.loadLibrary
themselves. (A future CL may want to make the loadLibrary call part
of the .aar generated by gomobile bind.)
Delete the libhello example, which has been replaced by gomobile bind,
which could do with its own example at some point. Also delete the
libhellojni example, which now has nothing to do with the x/mobile
repository.
Change-Id: I444397f246dbafe81e5c53532eb482c197d26f70
Reviewed-on: https://go-review.googlesource.com/11654
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Change-Id: Ie04a58ac090d8916463586b5fadb14c5539a21dd
Reviewed-on: https://go-review.googlesource.com/11640
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
It is already done in our examples and is missing from the linux/x11
implementation. If memory serves this is just long-standing
debugging cruft.
Change-Id: I1919a8704b11502fe8f402e3840bc5a1cd8b16e3
Reviewed-on: https://go-review.googlesource.com/11655
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Move runtime.LockOSThread from the portable Main to the
platform-specific android main. For darwin, calling LockOSThread in
Main is too late, there has been enough time for the goroutine
calling it to jump off the initial OS thread. For darwin we call
LockOSThread from an init function, which the runtime keeps on the
first thread. For Android we call LockOSThread only to maintain the
thread-local storage for the GL context that is created later, so
it is safe to call it from func main.
Also remove TODOs about starting a gobind app on Android, which
will be simplified in a followup CL.
Tested on darwin/amd64 and android. Not tested on X11.
Change-Id: I34c56abf8b1292959d4d508bfade287d196c0380
Reviewed-on: https://go-review.googlesource.com/11653
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This change will break Darwin. I have only built and tested this on
desktop linux and Android linux. A follow-up CL will fix Darwin.
Currently, OpenGL gets its own thread, and UI C code (e.g. the Android
event loop, or the X11 event loop) gets its own thread. This relies on
multiple system-provided UI-related C libraries working nicely together,
even when running on different threads. Keeping all the C code on the
one thread seems more sound.
As side-effects:
- In package app/debug, DrawFPS now takes an explicit Config.
- In package app, some callbacks now take an explicit Config.
- In package exp/sprite, Render now takes an explicit Config.
- In package event, there are new events (Config, Draw, Lifecycle),
and an event filter mechanism to replace multiple app Callbacks.
- In package geom, the deprecated Width, Height and PixelsPerPt global
variables were removed in favor of an event.Config that is
explicitly passed around (and does not require mutex-locking).
Converting a geom.Pt to pixels now requires passing a pixelsPerPt.
- In package gl, the Do, Start and Stop functions are removed, as well
as the need to call Start in its own goroutine. There is no longer a
separate GL thread. Instead, package app explicitly performs any GL
work (gl.DoWork) when some is available (gl.WorkAvailable).
- In package gl/glutil, Image.Draw now takes an explicit Config.
Callbacks are no longer executed on 'the UI thread'.
Changing the app programming model from callbacks to events (since a
channel of events works with select) will be a follow-up change.
Change-Id: Id9865cd9ee1c45a98c613e9021a63c17226a64b1
Reviewed-on: https://go-review.googlesource.com/11351
Reviewed-by: David Crawshaw <crawshaw@golang.org>
David Crawshaw
Nigel Tao
Hyang-Ah (Hana) Kim