We don't need sub-packages.

event.Touch, event.Movement, event.Location sounds better to me.

can we start with listing what "events" we are interested in?

user input events: touch, key (hardware key press)
sensor input events: motion, location

what about interruption caused by notification or phone call, or configuration change events such as orientation change event?

We also need to cover events listed on #10442.

I'd focus on whether we need to share these event types between multiple packages or not. If we have to share, it's better to keep them all under event. If not, event types may live in their particular packages.

The x/mobile/event package has changed since this issue was first opened. Its package doc comment currently says, "This package defines a number of commonly used events... other packages may define their own events".

Other packages include things like what's currently x/mobile/exp/sensor (and third party packages outside of x/mobile), so a 'sensor event' type doesn't necessarily need to live in "package event": the qualified type name could be "sensor.Event" instead of "event.Sensor".

Given that, it might make sense to break up the x/mobile/event packages to push 'core event' types like event.Touch and event.Draw into x/mobile/event/touch and x/mobile/event/draw so that the type's qualified names are "touch.Event" and "draw.Event", consistent with third party "foo.Event". I am already in favor of a separate x/mobile/event/key package so you can say things like "key.Backspace" and "key.AudioVolumeUp", so it might make sense to have "key.Event" too.

OTOH it does mean that the x/mobile/event/draw package will literally be:

package draw
type Event struct{}

plus commentary, which hardly seems worth its own package, but it still might make sense for consistency.

I don't know which way I prefer yet. WDYT?

I would prefer each event to be organized in its own package in order to provide consistent organization for the third parties. But if we create a new package for each event type, we will suffer from the pollution of sub-packages under x/mobile/event. And unfortunately these sub-packages will have to be named after very commonly used words such as touch and draw. It might be a wiser choice to preserve these names for functionality exposed around touch and draw, rather than just exporting event types.

Just some thoughts, before I forget. I still haven't decided which way I fall here.

"package touch" and "package lifecycle" would let you say "touch.Event" and "lifecycle.Event", but also "touch.SequenceID" and "lifecycle.Stage" instead of "event.TouchSequenceID" and "event.LifecycleStage", so while these event/foo packages will be small, they won't all be nothing but a trivial "type Event struct{ etc }". A "package key" certainly won't be trivial if we add names for all the buttons like Backspace, plus modifier masks.

As for the name "draw", there's already an "image/draw" package in the standard library, so it may make sense to rename the event from "draw" to "paint" (or another bikeshed color).

Pros of having touch.Event over event.Touch:

• Third parties can export event types in a consistent way.
• Names are shorter, user code will look less verbose.

Cons:

• Name collisions within the mobile package. If we want to provide utility functions for touch events, we need to find another package name. Since there are numerous events we support and will support in the future, we are reserving numerous good names to export event types.
• Name collisions with the standard library.
• It is not clear to me where the common types (such as Change) are going to live at? x/mobile/event?

I'm now leaning towards package x/mobile/event/touch and touch.Event (and config.Event, key.Event, etc.), and removing the event.Change type back in favor of touch.TypeStart, touch.TypeEnd, key.TypePress, key.TypeRelease, etc.

What's left in the x/mobile/event package would be:

func Filter(event interface{}) interface{}
func RegisterFilter(f func(interface{}) interface{})

These could move to package app, so there is no "package event".

I'm not so concerned about name collisions, apart from s/draw.Event/paint.Event/ as I said above.

Any thoughts, @crawshaw, @hyangah, @rakyll?

SGTM. My experiments with the scribe package (which I'll will return to when done with the machinery for publishing Ivy's source) pushed me towards the same opinion.

SGTM. let's do it before Go1.5

I am fine with leaving the event package though - could be the central place for overview documentation.

SGTM.

CL https://golang.org/cl/12225 mentions this issue.