ref: 403f01655a367543e25142a32f3ec18c22ad4fd2 gio/widget/material/editor.go -rw-r--r-- 2.1 KiB
widget,widget/material: add selection to the editor

- Allow dragging to be on both horizontal and vertical axes at once.
- Split Editor.caret.pos into caret.start and caret.stop. caret.start is
  the old caret.pos, and is both the position of the caret, and also the
  start of selected text. caret.end is the end of the selected text.
  Start can be after end, e.g. after after Shift-DownArrow.
- Update caret.end after a mouse drag, and various shifted keys
  (Shift-UpArrow, Shift-DownArrow, etc).
- Change Shortcut-C to copy only the selected text, not the whole editor
- Add Shortcut-X to copy and delete selected text, and Shortcut-A to
  select all text.
- The various Insert/Delete/etc functions now overwrite or delete the
  selection, as appropriate.
- Change MoveCaret to accept a distance for selection end, as well.
  Change SetCaret to accept a selection end offset.
- Add SelectionLen to get the selection length, Selection to get
  selection offsets, SelectedText to get the selected text, and
  ClearSelection to clear the selection.
- Add a rudimentary selection unit test, and extend the deleteWord unit
  test with some text selection cases.
- Add SelectionColor to material.EditorStyle, which defaults to

Signed-off-by: Larry Clapp <larry@theclapp.org>
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>
widget/material: better disabled color calculation

Use desaturation in combination with alpha multiplication.

Signed-off-by: Egon Elbre <egonelbre@gmail.com>
widget/material: manage widget colors with Palette type

This introduces a new material.Palette type that captures the color information
necessary to render a widget. This type is embedded in the material.Theme to
make it easier to swap to a different palette for part of the UI by reassinging
the Palette field.

Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
all: use color.NRGBA in public API

color.RGBA has two problems with regards to using it.

First the color values need to be premultiplied, whereas most APIs
have non-premultiplied values. This is mainly to preserve color components
with low alpha values.

Second there are two ways to premultiply with sRGB. One is to premultiply
after sRGB conversion, the other is before. This makes using the API more

Using color.NRGBA in sRGB makes it align with CSS.e

Signed-off-by: Egon Elbre <egonelbre@gmail.com>
widget/material: fix hint when Editor is single-line

Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
internal/f32color: add colorspace-correct function for alpha scaling

Package material's ad-hoc mulAlpha didn't take the sRGB color-space
into account, which meant that alpha-scaled colors were subtly wrong.
Introduce f32color.MulAlpha and convert all uses to it.

Thanks to René Post for finding and debugging the issue.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget/material: add disabled state support to all widgets

This commit configures all remaining widgets to draw themselves in a disabled state
when their layout.Context is disabled. A description of the
strategy employed by each follows:

- Checkbox and RadioButton: Draws the icon component in a lighter color. Currently the label text is left
in its default color.
- ProgressBar: The "progress" color is lightened, but not as much as the background color. This makes the current progress value still readable.
- Editor: The cursor is no longer drawn and the text is lightened.
- Switch: The track is unchanged, but the circular "thumb" component is lightened.

Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
op: change CallOp to be a return value from MacroOp.Stop


	macro := op.Record(ops)



	macro := op.Record(ops)
	call := macro.Stop()


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>
ae8a377c — Thomas Bruyelle 1 year, 3 months 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/material: move widget state object from Layout methods to constructors

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>
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


    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>
material: make theme constructors stand-alone functions

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.

	// 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,


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"


	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>
text: simplify text layout and shaping API

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>
text: make Shaper an interface

And rename out the caching implementation to FontRegistry.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
op: remove operation list argument from MacroOp.Add

The ability to invoke other operation lists belongs in the new CallOp.

While we're here, make MacroOp.Add use a pointer receiver to match the
other methods.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget/material: use theme TextSize for Editors

Thanks to Werner Laurensse for noticing.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
theme/material: add the material theme

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