~eliasnaur/gio

gio/widget/material/doc.go -rw-r--r-- 2.0 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>
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>
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>
widget/material: clean up package docs, add license, rename file

Signed-off-by: Elias Naur <mail@eliasnaur.com>
widget/material: document package

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