This change removes the extra frame scheduled when events was delivered
during a frame. This extra frame was intended to paper over state changes
that happen later than the layout depending on it.
However, it is better for programs to never allow such state change skew,
and recent changes allows them to refresh and query state before layout.
This is an API change because programs may rely on the extra frames.
Those programs should ensure that state is updated before relying on it
in layout.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
When a key.InputOp is focused, a key.Event is matched to it and its ancestors.
If there is no focus, every handler is matched.
This change always matches to every handler, after checking the focus and
its ancestors.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
When a key.InputOp is focused, keypresses that it does not explicitly
include in its key set should check for ancestor clip areas that are
interested in them. Previously this check only included ancestors of
the final clip area in the hit tree, and could fail to find ancestors
of the focused key.InputOp because they were in a different branch.
This commit also adds a test to lock in the new behavior.
This can likely be made more efficient by adding a rapid way to map
from the focused key tag to its index in the hit tree. I wasn't sure
whether the complexity was warranted, but I'm happy to do that if
it's desired.
Signed-off-by: Chris Waldon <christopher.waldon.dev@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>
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>
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>
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>
This is a refactor to make it easier to add higher level logic to
focus moves. A follow-up will add automatic scrolling to bring
focused widgets into view.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Like a previous change for pointer ops, process key ops during the
router decode of ops. This is a performance optimization and preparation
for processing future accessibility ops without without another decode
loop.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The op.Save and Load methods exist to support the need for
transformation, clip, pointer area state to behave as stacks. For
example, layout needs to apply an offset to its children but not
subsequent operations.
Before this change, op.Save and Load were used to save and restore the
state:
ops := new(op.Ops)
// Save state.
state := op.Save(ops)
// Apply offset.
op.Offset(...).Add(ops)
// Draw with offset applied.
draw(ops)
// Restore state.
state.Load()
A drawback with the op.Save mechanism is that there is no direct
connection between the state change and the saving and loading of state.
This causes confusion as to when a Save/Load is needed and who is
responsible for performing them, which leads to subtle bugs and over-use
of Save/Loads.
This change gets rid of the general state stack and replaces it with
per-state stacks. There is now a stack for transformation, clip, pointer
areas, and they can only be restored by the code pushing state to them.
The example above now becomes:
ops := new(op.Ops)
// Push offset to the transformation stack.
stack := op.Offset(...).Push(ops)
// Draw with offset applied.
draw(ops)
// Restore state.
stack.Pop()
For convenience, transformation also be Add'ed if the stack operation is
not required.
Simple state such as the current material no longer has a way to be
restored; it is assumed the client of a PaintOp adds their desired
material operation before it.
API change: replace op.Save/Load with explicit Push/Pop scopes for
op.TransformOps, pointer.AreaOps, clip.Ops.
To ease porting, this change retains a version of op.Save/Load that
saves and restores the transformation and clip stacks. It also retains
an Add method for clip.Op.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
key.InputOp and pointer.InputOp handlers are reset on first registration
through a key.FocusEvent{false} or pointer.Cancel, respectively.
However, the mere act of registering a handle shouldn't result in a
redraw. This is particularly true for misconfigured handlers where a new
tag is supplied every frame, resulting in continously redrawing.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The target of FocusOp is too subtle; be explicit instead and remove
any doubt.
Multiple SoftKeyboardOp in a single frame is rare, but if they do occur,
they should behave as if they were from separate frames: the last one
applies.
As a side-effect the key event router can be much simplified.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The semantics were relaxed in a previous commit; this change renames
to operations accordingly.
API change. Use gofmt to adjust your code accordingly:
gofmt -r 'op.Push(a).Pop() -> op.Save(a).Load()'
gofmt -r 'op.Push(a) -> op.Save(a)'
gofmt -r 'v.Pop() -> v.Load()'
gofmt -r 'op.StackOp -> op.StateOp'
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The existing implementation cannot remove the focus of some widget,
doesn't have an option to focus without display the on-screen keyboard
and it automatically focuses the first InputOp, aggressively.
That change aims to make possible: remove focus from any widget. Add
focus without displaying the on-screen-keyboard/soft keyboard. Don't
automatically focus any widget. Don't recover focus when the widget is
visible again.
Fixes gio#180.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Elias Naur