~eliasnaur/gio

gio/widget/material/label.go -rw-r--r-- 1.8 KiB
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>
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.
	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>
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>
theme/material: add the material theme

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