Android doesn't distinguish between the arrow keys on a keyboard and the
directional keys on a remote control, so there's no way to move the caret
in an Editor with arrow keys. This change updates the Android port to map
Android's DPAD_* key codes to the arrow key names, fixing caret movement.
The change also updates Editor to only request arrow keys that actually move
the caret, to keep directional focus movement working.
Fixes: https://todo.sr.ht/~eliasnaur/gio/410
Signed-off-by: Mearaj <mearajbhagad@gmail.com>
Prior to this change an editor with no content and a zero minimum
constraint would return itself has having width zero. This
prevented users from being able to see the editor when they
moved focus to it, as it could not display its caret. This
simple change ensures that, at minimum, the editor returns
its dimensions to include the width of a caret.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Updated the documentation for layout.List to include the details about how
drawing is performed for items in it. This gives the user an understanding about
how so many items can be drawn for performance.
Signed-off-by: Thomas Mathews <thomas.c.mathews@gmail.com>
If the currently focused handler don't want the key event, try every
other handler, from top to bottom. This change requires widgets to
only react when focused.
Fixes: https://todo.sr.ht/~eliasnaur/gio/406
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Instead of cmpletely replacing the IME snippet for every update, expand
the old range if there is overlap. This change avoids never-ending
restarts of the IME on Android where snippets are expanded in two
calls, one for expanding before the selection and one for exanding after
the selection.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
It's much simpler to map the Android back button to a key.Event and
let the usual key filtering determine whether to block its default
behaviour.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This change adds key.NameUp/Down/Left/Right and maps the Android TV
remote directional keys to them. As a side-effect a key.InputOp can
now receive directional keys (and block their focus movement).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, Tab and Shift-Tab would always result in focus
movement. This this change, a key.InputOp with a matching Keys set
will block focus movement and deliver the events to it.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, every Event would be passed to the focused InputOp
tag, making it impossible to implement, say, program-wide shortcuts.
This change implements key.Event routing similar to how pointer.Events
are routed: every InputOp describes the set of keys it can handle, and
the router use that information to deliver an Event to the matching
handler.
This is an API change, because every InputOp must now include a filter
matching the keys it wants to handle.
Fixes: https://todo.sr.ht/~eliasnaur/gio/395
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, synthetic events such as scrolling caused by
focus movement would use semantic information to determine potential
receivers. However, there can only be one handler per area so sibling
handlers would not be considered. This change makes the event delivery
traverse the entire tree of handlers, including siblings.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about the express sets of key combinations as <modifiers>-<keys>
where modifiers are separated by dashes as well. To make Modifers.String
useful for expressing key sets, change its separator to "-".
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We already have precedence for word-named keys ("Space") and the new
names are less obscure and matches Modifiers.String.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
OpenGL ES 2.0 doesn't support GL_PACK_ROW_LENGTH, so this change implements
a fallback using a temporary buffer.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We should return as soon as possible from FrameEvent.Frame to allow the main
goroutine to continue processing other tasks. Whereas GPU.Frame may touch
the frame ops, GPU.Present will not, so this change moves Present to after
returning from FrameEvent.Frame.
This is a variant of 38ff78df5d that
works on OpenGL where context locking is required.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We should return as soon as possible from FrameEvent.Frame to
allow the main goroutine to continue processing other tasks.
Whereas GPU.Frame may touch the frame ops, GPU.Present will not,
so this change moves Present to after returning from FrameEvent.Frame.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Clipping all children once to the entire List area is enough. The
change was motivated by #389 where individual child clips would
make it harder for focus scroll heuristics to work.
References: https://todo.sr.ht/~eliasnaur/gio/389
Signed-off-by: Elias Naur <mail@eliasnaur.com>
List was recently changed to include an extra child at each end, to
automatically scroll when reaching the end of a focus direction. However,
if List includes unfocusable children that strategy may fail. This change
adds another fallback where app.Window will scroll a constant amount in
the focus direction, to reveal more children.
For https://github.com/tailscale/tailscale/issues/4278.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Enter/Leave events make sense for mouse pointers, to track hover
status. It doesn't make sense to track hover for touch input, so
this change stops pointer.Enter and pointer.Leave from being
emitted for pointer.Touch sources.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A recent change added automatic scrolling to move focused widgets
into view. This change modifies List to layout an extra child at
each of its ends, to enable focus to move to them and trigger
automatic scrolling of the list.
For https://github.com/tailscale/tailscale/issues/4278.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before, List would only report the remaining scrollable area of the visible
children when positioned close to either end. Now, List always report infinite
scroll bounds *unless* it is positioned at an extremum.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, semantic clicks would be delivered according to
the center of the targeted widget, which could result in a different
widget receiving the click. Or in worst case, no widget in case the
center is not visible because of clipping.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A focused widget may be partially or completely off-screen in which case
the user will have difficulty interacting with it. This change attempts to
scroll the focused widget into view by issuing synthetic scroll events.
For https://github.com/tailscale/tailscale/issues/4278, but doesn't completely
solve it because layout.Lists won't layout focusable widgets outside its visible
bounds. A follow-up change deals with that.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur