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>
