Converting
macro := op.Record(ops)
...
macro.Stop()
macro.Add()
to
macro := op.Record(ops)
...
call := macro.Stop()
call.Add(ops)
Which is more general (call.Add can take a different ops than the op.Record
that started it), and enforced the order between Stop and the subsequent Add.
Signed-off-by: Elias Naur <mail@eliasnaur.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>
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>
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>
Instead of, say,
var th *material.Theme
var btn *widget.Clickable
material.Button(th, "Click me").Layout(gtx, btn)
move the widget state objects to the constructor:
material.Button(th, btn, "Click me").Layout(gtx)
The advatage is that several widgets can now be used without
wrapping them in function literals. For example,
layout.Inset{}.Layout(gtx, func(gtx layout.Context) layout.Dimensions {
material.Button(th, "Click me").Layout(gtx, btn)
})
collapses to just
layout.Inset{}.Layout(gtx, material.Button(th, btn, "Click me").Layout)
Signed-off-by: Elias Naur <mail@eliasnaur.com>
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>
Use Inset instead, matching the other buttons.
Redefine Size to apply to the icon size, without padding.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
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>
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>
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>
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>
Setting a ColorOp before calling a widget function is too subtle.
Let the widget manage its color instead.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to introduce the Switch widget that re-uses the same
state type as CheckBox. The Bool name covers both uses.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Similar to the previous change to Enum, expose the current state of
the CheckBox. Rename the Checked method to just Update and get rid
of the SetChecked method.
Fixes gio#100
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The Value method both updated the enum value and returned it.
In order to access the current value withoutm, expose the Value
field of the enum and rename the method to Update. As a bonus we
can get rid of the SetValue method as well.
Updates gio#96
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The multitude of widget methods on Theme is unnecessary coupling in that all
possible widgets either have to be included in package material, or be
different than 3rd party widgets:
var th *Theme
// Core widget, calling a method on Theme.
th.Button(...).Layout(...)
// 3rd party widget, calling a function taking a Theme.
datepicker.New(th, ...).Layout(...)
Another reason for the Theme methods was to enable a poor man's
theme replacement, so that you could use the same code for
compatible themes. For example,
mat.Button(...).Layout(...)
would not need to change if the type of mat changed, as long as
the new type had a compatible method Button.
However, that point misses the fact that the mat variable had to
be declared somewhere, naming the theme package:
var mat *material.Theme (or, say, *cocoa.Theme)
A better and complete way to replace a theme is to use import renaming.
For example, to replace the material theme with a hypothetical Windows
theme, replace
import theme "gioui.org/widget/material"
with
import theme "github.com/somebody/windows
This change moves all Theme widget methods to be standalone functions,
and renames the widget style types accordingly.
For example, instead of the method
func (t *Theme) Button(...) Button
there is now a function
func Button(t *Theme, ...) ButtonStyle
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There is nothing theme-specific about displaying images and icons,
so move the types from the material package to the generic widget
package.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This reverts commit 52ccc183b5.
Reason for revert:
This doesn't seem like a good idea after all. The reason for the change was to
propagate the minimum constraints to the button content. But in the simplest case,
a label, stretching the button will make the label stretch as well, leaving the label
top-aligned.
We'll revisit this issue if a real use-case comes up.
A previous change propagated the minimum layout constraints to Button's
content, which made Button no longer center its label when stretched.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The previous change fixed a regression where minimum constraints larger than 0
would not affect the button. This change moves the minimum constraints one
level lower so the content widget will see them as well. The wrapping
layout.Center ensures that any misbehaving widgets still end up centered.
Add a test to lock in the new behaviour and the previous fix.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Add ButtonLayout for adding button behaviour and style to arbitrary content such
as a combined icon-and-text button.
Fixes#43
Signed-off-by: metaclips <utimichael9@gmail.com>
It was left over from a previous approach to enable the program
to decide the ordering between calls to Layout vs Clicked.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The new field ImageOp.Rect is initialized to cover the entire source
image, but can be modified to draw only a section of it.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
- Focused: returns whether editor is focused
- CaretPos: returns the text line & column numbers of the caret.
- CaretCoords: returns the x & y pixel coordinates of the caret.
- NumLines: returns the number of text lines in the editor
Signed-off-by: Larry Clapp <larry@theclapp.org>
Editor's event processing assumes the cached layout is valid, but
it might not be if the program changed the Editor text between calling
Layout and Events.
Fixes#85 (I think)
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Now that text layout and shaping operate on concrete sizes and not
units, Editor no longer needs to detect scaling changes. Remove it.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
First, replace LayoutOptions with an explicit maximum width parameter. The
single-field option struct doesn't carry its weight, and I don't think we'll
see more global layout options in the future. Rather, I expect options to cover
spans of text or be part of a Font.
Second, replace the unit.Converter with an scaled text size. It's simpler and
allow the Editor and similar widgets to easily detect whether their cached
layouts are stale. Package text no longer depends on package unit, which is
now dealt with at the widget-level only.
Finally, remove the Size field from Font. It was a design mistake: a Font is
assumed to cover all sizes, as evidenced by the FontRegistry disregarding
Size when looking up fonts.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur