~eliasnaur/gio

ref: 284659d3eac9 gio/widget/button.go -rw-r--r-- 3.2 KiB
Programmatic Click function

Signed-off-by: Paulo Melo <paulo.durrer.melo@gmail.com>
gesture,widget: add hovered property

Signed-off-by: Egon Elbre <egonelbre@gmail.com>
op: rename StackOp/Push/Pop to StateOp/Save/Load

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>
all: move Now from system.Config to system.FrameEvent

Then, make layout.Context.Now a field, copied from FrameEvent.Now.

API change:

	gofmt -r 'gtx.Now() -> gtx.Now'

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget: immediately fade out cancelled button press inkwells

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget,gesture: fade out cancelled inkwells

While here, adjust inkwell sizes to match gtx.Constraints.Min.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
gesture,widget: drop press markers on gesture cancel

Signed-off-by: Elias Naur <mail@eliasnaur.com>
ae8a377c — Thomas Bruyelle 1 year, 17 days ago
op: add op.Push and op.Record funcs

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>
widget: Clickable: added support for NumClicks

Clickable.Clicks() now returns the number of clicks.

Signed-off-by: Pierre.Curto <pierre.curto@gmail.com>
widget: make Clickable.Clicked use a pointer receiver

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget: add Button.Clicks for retrieving clicks

An earlier change unexported the Button.Update method that exposed raw pointer
input not available from the boolean Button.Clicked method. Introduce Click
and Button.Clicks to replace it, and implement Clicked in terms of it.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget,widget/material: rename widget.Click to widget.Press

Press tracks pointer presses, not clicks, and we're about to add a Click
type that does.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget,widget/material: only process events in Layout methods

Before this change, events were typically processed twice or more per
widget: once in the Layout method for refreshing the visual state, and
once per method that queries for state changes.

One example is widget.Clickable that processed events in both its Layout
and Clicked method.

This change establishes the convention that events are processed once, in
the Layout method. There are several advantages to that approach:

- Query methods such as Clickable.Clicked no longer need a layout.Context.
- State updates from events only occur in Layout.
- Widgets are simplified because they won't need a separate processEvents
(or similar) method and won't forget to call it from methods other than Layout.
- Useless calls to gtx.Events are avoided (gtx.Events only returns events
for the first call each frame for a given event.Tag).

The disadvantage is that state updates from input events will not appear
before Layout. For example, in the call sequence

	var btn *widget.Clickable

	if btn.Clicked() {...}
	btn.Layout(...)

the Clicked call will not detect an incoming click until the frame after it
happened.

This is ok because

- The Gio event router automatically dispatches an extra frame after events
arrive, bounding the latency from events to queries such as Clicked to
at most one frame (~17 ms).
- The potential extra frame of latency does not apply to Layout methods as long
as they process events before drawing. In other words, the visual feedback
from input events are not delayed because of this change.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
layout: change Widget to take explicit Context and return explicit Dimensions

Change the definition of Widget from the implicit

        type Widget func()

to the explicit functional

        type Widget func(gtx layout.Context) layout.Dimensions

The advantages are numerous:

- Clearer connection between the incoming context and the output dimensions.
- Returning the Dimensions are impossible to omit.
- Contexts passed by value, so its fields can be exported
and freely mutated by the program.

The only disadvantage is the longer function literals and the many "returns".
What tipped the scales in favour of the explicit Widget variant is that type
aliases can dramatically shorten the literals:

	type (
		C = layout.Context
		D = layout.Dimensions
	)

	widget := func(gtx C) D {
		...
	}

Note that the aliases are not part of the Gio API and it is up to each user
whether they want to use them.

Finally the Go proposal for lightweight function literals,
https://github.com/golang/go/issues/21498, may remove the disadvantage
completely in future.

Context becomes a plain struct with only public fields, and its Reset is
replaced by a NewContext convenience constructor.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
layout,widget: transpose Constraints to use image.Points for limits

Instead of

    type Contraints struct {
	    Width, Height Constraint
    }

use

    type Constraints struct {
	    Min, Max image.Point
    }

which leads to simpler use. For example, the Min method is trivally replaced by
the field, and the RigidConstraints constructor is no longer a net win.

API Change. Rewrites:

    gofmt -r 'gtx.Constraints.Min() -> gtx.Constraints.Min'
    gofmt -r 'gtx.Constraints.Width.Min -> gtx.Constraints.Min.X'
    gofmt -r 'gtx.Constraints.Height.Min -> gtx.Constraints.Min.Y'
    gofmt -r 'gtx.Constraints.Height.Max -> gtx.Constraints.Max.Y'
    gofmt -r 'gtx.Constraints.Width.Max -> gtx.Constraints.Max.X'

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget/button,widget/material: introduce Clickable for generic click areas

material.Clickable is useful for adding a click response to any widget
or area.

Rename widget.Button to widget.Clickable to reflect the wider use
spectrum.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget: export Button.Update method for accessing raw gesture events

Document Button while we're here.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget: simplify popping an element from a slice

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget,widget/material: use constraints for setting up hit area

Before this change, the widget.Button.Layout method assumed the caller had set
up the pointer hit area before. Further, the very common rectangular hit
areas needed both an AreaOp and a widget.Button.Layout call.

Make widget.Button less subtle and more useful by setting up a
pointer hit area given by the incoming minimum constraints.

Drop a pointer.AreaOp made redundant by the change.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget: improve Click description

Signed-off-by: Elias Naur <mail@eliasnaur.com>
Next