In commit 929e4dc12, the rules to send pointer.{Enter,Leave}
events were relaxed. Unfortunately, to be able to make use
of them was not straight forward as it required the transfer
target op to use the same handle as the hover one.
This patch eases this by allowing any handle for the target
as well as not requiring the hover op to be defined on the same
clip op as the target (then requiring a PassOp though), making
it much easier to use.
Also added a test for pointer.Enter events not being generated
if the target type does not match the source one.
Signed-off-by: Pierre Curto <pierre.curto@gmail.com>
When a drag and drop gesture is ongoing, let the potential target
handlers receive enter/leave events so that they can react to them (e.g.
highlight themselves when the dragged item is over them).
Fixes#321.
Signed-off-by: Pierre Curto <pierre.curto@gmail.com>
This patch adds internal Drag and Drop support to app.Windows.
The new package io/transfer adds the ability to
define draggable and droppable targets, which
are leveraged by the new widget.Draggable type.
The API is generic and could handle future use
cases, such as external Drag and Drop.
Updates gio#153
Signed-off-by: Pierre Curto <pierre.curto@gmail.com>
Pointer hit areas and paint clip areas are separate concepts, but
similar enough to warrant merging. This change replaces pointer hit
areas with clip areas, so Gio is left with just one area concept (in
package op/clip).
The reason for separating the concepts in the original Gio release was
because of my being unsure general path/stroke hit areas would ever be
implemented, let alone efficient.
This change represents a change of mind, in the sense that it's better
to have an incomplete API than two separate area concepts.
Leave the deprecated pointer.Rect, pointer.Ellipse for temporary
backwards compatibility.
This is an API change. Most existing programs should continue to build
with this change, but may have to adjust to having all clip.Ops participate
in InputOp hit areas.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to make clip.Ops act as pointer areas, in which case we'd
like to contain the effect of PassOp to just pointer InputOps.
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>
For example, ButtonLeft may be the right-most button for a left-handed user.
Rename the button names to match their intended use.
This is an API change. Use the following commands to update your
projects:
$ gofmt -r 'pointer.ButtonLeft -> pointer.ButtonPrimary' -w .
$ gofmt -r 'pointer.ButtonRight -> pointer.ButtonSecondary' -w .
$ gofmt -r 'pointer.ButtonMiddle -> pointer.ButtonTertiary' -w .
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Add support to Router so that the cursor can be changed with CursorNameOp without any mouse movement.
Enter and Leave events are also delivered as areas change.
Signed-off-by: pierre <pierre.curto@gmail.com>
As a follow-up to gioui.org/commit/24f69bf4, this change makes it so
that merely adding a pointer.InputOp doesn't trigger redraws when
the pointer is hovered over its area.
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 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>
Fixes a problem where a touch Release would signal gesture.Click
that it had left just before click would complete.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Replace the pointer.Scroll special case with a new priority that
indicates the foremost handler, checked in gesture.Scroll.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This eliminates needless redraws for handlers that care about drag events and not move events, like gesture.Scroll.
Signed-off-by: Gordon Klaus <gordon.klaus@gmail.com>
The funcs replace stack.Push and macro.Record, which become private.
This makes stack and macro faster to write, in particular for stacks
where you can just write the following line to save and restore the
state :
defer op.Push(ops).Pop()
This usage requires Push to return a pointer (since Pop has a pointer
receiver), or else the code doesn't compile.
For consistancy, I tried to do the same for op.Record, but this implied
to turn all the MacroOp fields into pointers, and this caused some
panics. As a result, op.Record doesn't return a pointer.
An other side effect pointed by Larry Clapp: StackOp and MacroOp are not
re-usable any more, you have to allocate a new one for each usage, using
the described funcs above.
Signed-off-by: Thomas Bruyelle <thomas.bruyelle@gmail.com>
- Drop pointer.Event.Hit in favour of Enter/Leave events.
- Track enter/leaves for each pointer.ID (updates #122). Add test.
- Resolve grabs once.
- Get rid of scratch slice.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Key had an unfortunate association with keyboard input.
This is an API change. The following rewrites were run to fixup
Gio code:
$ gofmt -r 'pointer.InputOp{Key:a} -> pointer.InputOp{Tag:a}' -w .
$ gofmt -r 'pointer.InputOp{Key:a, Grab:b} -> pointer.InputOp{Tag:a, Grab:b}' -w .
$ gofmt -r 'key.InputOp{Key:a} -> key.InputOp{Tag:a}' -w .
$ gofmt -r 'key.InputOp{Key:a, Focus:b} -> key.InputOp{Tag:a, Focus:b}' -w .
$ gofmt -r 'event.Key -> event.Tag' -w .
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit improves the usefulness of the benchmark by automatically
measuring event processing times with a range of values for the complexity
of the UI.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit fixes a bug which concealed test failures when
the actual event sequence was empty but the expected events
were not.
Additionally, this commit adds the following tests:
- a test for when the active input
area disappears while it is still being "hovered".
- a test for when there are two nested input areas that are
being hovered
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Pierre Curto