Go documentation style for boolean funcs is to say:
// Foo reports whether ...
func Foo() bool
rather than "returns true if" or "returns whether".
Change-Id: I5d01c45a8867b47462ed142a49ad51bf0a319ce1
Reviewed-on: https://go-review.googlesource.com/c/151957
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Horizontal wheel events can come from some tilting scroll wheels, as
well as trackpoints (pointing sticks).
Change-Id: I02be43d44a65123e2d58539e291e9e6ac7e6bff4
Reviewed-on: https://go-review.googlesource.com/24633
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This makes the following program valid:
----
package main
import (
"fmt"
"golang.org/x/mobile/event/size"
)
func foo() size.Event { return size.Event{} }
func main() {
fmt.Println(foo().Bounds())
}
----
Previously, you would get:
./main.go:12: cannot call pointer method on foo()
./main.go:12: cannot take the address of foo()
Change-Id: I2801d18a04d56d1c7496cb008531d078490ccf86
Reviewed-on: https://go-review.googlesource.com/18356
Reviewed-by: David Crawshaw <crawshaw@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>
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>
This is similar to the Event.Bounds method. Some functions in other
packages take an image.Rectangle (i.e. bounds), others take an
image.Point (i.e size).
Change-Id: Ie892a8902992d4e6b9edfbf6d12342297fae4068
Reviewed-on: https://go-review.googlesource.com/14003
Reviewed-by: David Crawshaw <crawshaw@golang.org>
There are several variations on orientation. iOS expposes a little
more orientation information through its basic enum than Android
does, but the more powerful Android API gives you degrees around a
circle, which while strictly more powerful, doesn't tell you easily
where the status bar is.
What I'm thinking with this is the primary use of an orientation
concept is to decide whether or not to lay out a UI for a wide screen.
This gives you that.
Later I hope the sensor API will give far more information about the
physical orientation of the device.
Change-Id: I00ff598853c7ed618cde266729d8d05e1a02a601
Reviewed-on: https://go-review.googlesource.com/13361
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This is analogous to the image.Image's Bounds method.
Change-Id: I2be927f21008107b535cb79e231149cb8d4e8e36
Reviewed-on: https://go-review.googlesource.com/13152
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>
Also add a few missing codes.
Change-Id: I26b6db31067c67107fe4db142ec9f48ff13cc53e
Reviewed-on: https://go-review.googlesource.com/12536
Reviewed-by: Nigel Tao <nigeltao@golang.org>
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>
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>
An example of how to handle multiple concurrent touches using this design:
var touched = map[event.TouchSequenceID]*Widget{}
func touch(t event.Touch) {
if t.Type == event.TouchStart {
if w := widgetAt(t.Loc); w != nil {
touched[t.ID] = w
}
}
if w, ok := touched[t.ID]; ok {
// move/scroll widget, etc
}
if t.Type == event.TouchEnd {
delete(touched, t.ID)
}
}
Change-Id: I79910ef30abe9a41bc0720783022b1af081fbd43
Reviewed-on: https://go-review.googlesource.com/1895
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Burcu Dogan <jbd@google.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Tobias Klauser
Daniel Skinner
Alessandro Arzilli
Nigel Tao
David Crawshaw
Gordon Klaus
David Symonds
Andrew Gerrand
David Crawshaw