go.mod specifies 1.18, due to go.mod behavior and to avoid some issues
with updating the dependencies. However, we can still support older go
version, as long as it compiles with the older version.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
This commit adds exported methods to both LabelState and Editor
allowing callers to locate the text regions representing a range
of runes. This can be used to build interactive subregions of text,
like (for instance) hyperlinks.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit rebuilds the editor and label types on the common
foundation provided by textView. This enables labels to have
optional state that makes them selectable, and allows the
two widgets to share the code for managing cursor positions,
displaying selections, and soforth. Labels now have an additional
Layout function which can be invoked if they have a Selectable.
It accepts a layout.Widget used to paint their contents. Stateless
labels should still use the old Layout method.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit adds a standalone state type for manipulating
and displaying text. It reads text from a minimal interface,
shapes it, tracks valid cursor positions, and provides sizing
and scrolling services to higher-level widgets. My long term
goal with these types is to export them to allow non-core widgets
to build atop them, but I've left them private for now.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit provides a new ReadOnly boolean on the editor. If set, the
editor functions as a selectable label. User interaction cannot change
the contents of the editor (though application code can still use the
API).
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit extends the editor to keep track of its own minimum constraint
and to provide that value to the text shaper for the purpose of aligning
text. Without this, the shaper does not know how much of the width of the
editor to use for alignment purposes.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit unifies all widget text painting to use a single function
and fixes two bugs that could result in visible glyphs failing to be
painted.
The first bug was that we checked whether a particular glyph's
outline was visible within the viewport and terminated iteration the
first time that we found a glyph that wasn't visible. If the very top
of the next line of text was visible within the viewport, taller glyphs
should be painted since part of them is visible. We would stop as soon
as we got to a short glyph, preventing the rest of the line (and any
tall glyphs it contained) from being painted.
I fixed this first problem by using the ascent/descent of the line containing
a glyph to determine whether it's "visible". While this will conclude that
a small glyph is visible when it may be entirely off-screen, the net result
will be that we will paint the entire line containing the glyph rather than
constructing a special version of the line with only the tall glyphs. This
has better path caching performance, as we don't need a bespoke path for when
the line is partially visible.
The second bug was that when the glyph iterator concluded that the
current glyph was out of the viewport, we would immediately terminate
the loop for painting glyphs without painting any buffered glyphs that
had been determined to be visible.
This second bug was easily fixed by ensuring that we always paint all buffered
glyphs when terminating iteration.
As part of this work, I pulled the (fairly complex) logic of buffering and
painting glyphs into the glyph iterator so that label and editor can share
a single implementation.
I was unable to completely encapsulate the array storing buffered glyphs within
the iterator without it being moved to the heap, so the current glyph iteration
API requires the caller to juggle a slice of glyphs. Hopefully someone in
the future can find a structure that the compiler's escape analysis understands.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit restructures the entire text shaping stack to enable lines of shaped text to
have non-homogeneous properties like which font face they belong to and which direction
a segment of text is going.
The text package now provides a concrete type text.Shaper which can be used to convert
strings into sequences of renderable text.Glyphs. At a high level, the API is used
like this:
// Prepare some fonts.
var collection []text.FontFace
// Make a shaper with those fonts loaded.
shaper := text.NewShaper(collection)
// Shape a string.
shaper.LayoutString(text.Parameters{
PxPerEm: fixed.I(12),
}, 0, 100, system.Locale{}, "Hello")
// Iterate the glyphs from that string.
for glyph, ok := shaper.NextGlyph(); ok; glyph, ok = shaper.NextGlyph() {
// Convert the glyph data into a path. In real uses, convert batches of glyphs
// rather than single glyphs to reduce the number of individual paths and offsets
// required to display your text.
shape := shaper.Shape([]text.Glyph{glyph})
// Offset the glyph to the position it declares within its fields. This will
// automatically handle correct bidirectional text glyph positioning.
offset := op.Offset(image.Pt(glyph.X.Floor(), int(glyph.Y))).Push(gtx.Ops)
// Create a clip area from the shape of the glyph.
area := clip.Outline{Path: shape}.Push(gtx.Ops)
// Paint whatever the current color is within the glyph's shape.
paint.PaintOp{}.Add(gtx.Ops)
area.Pop()
offset.Pop()
}
This API will transparently handle both font fallback (choosing appropriate fonts
from those loaded when the primary font doesn't contain a required glyph) and
bidirectional text (mixed left-to-right and right-to-left text). Glyphs are
iterated in order of the input runes, not their visual order, but proper use
of the provided offsets will ensure that text always displays correctly.
Thanks to Elias Naur for suggesting this glyph iterator strategy. It let us cut
through a lot of accumulated complexity from trying to match our old text APIs,
meaning that this change actually is a net negative change in lines of code.
This commit consumes the upstream github.com/go-text/typesetting/shaping API
now that my prior work is merged there, removing the need for the font/opentype/internal
package entirely.
As part of my efforts, I fuzzed both the low-level text shaping stack and the
editor widget extensively. I've committed regression tests found that way into
the appropriate testdata files to ensure the fuzzer re-checks them.
Fixes: https://todo.sr.ht/~eliasnaur/gio/425
Fixes: https://todo.sr.ht/~eliasnaur/gio/211
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit redefines incrementing a combinedPos to either move a single
rune forward, *or* transition from EOL->BOL, *or* both. This allows traversal
of lines without a trailing newline character to reach the position after the
final glyph of content.
Additionally, this commit updates positionGreaterOrEqual to explicitly handle
hard newlines via special-case logic, allowing lines without a hard newline to
avoid the newline-based short-circuit logic that would prevent them from iteratively
reaching the combinedPos following the final glyph on the line.
Fixes: https://todo.sr.ht/~eliasnaur/gio/400
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit adds a test for the seekPosition helper, a function which can
be used to move a combinedPos forward through a body of text until it approaches
a position.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit adds an exhaustive test case for the positionGreaterOrEqual
helper function that our text widgets use to compare locations within
shaped text.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit adds documentation and tests for the clusterIndexFor helper,
making it easier to understand what it does and how to use it safely.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit restructures seekPosition from a complex state-manipulating
loop into a simple loop of iteratively applying an increment operation
to the combinedPos. The increment operation itself is now tested, and
much easier to understand.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit switches the way in which the editor and helper functions check
for RTL text from a heuristic to using the actual text direction.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Before this change, an IME text edit would always have its newlines
replaced with spaces. However, for Editors where Submit is enabled
we want newlines to result in SubmitEvents.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit adds a simple linear-history undo/redo mechanism to
widget.Editor bound to Short-(Shift)-Z as well as tests for this
new feature.
Notes on the implementation:
- using a slice to hold the history does mean that we incur
allocations as the user types, but I hope that the Go slice
growth heuristic means that the number of times we pay this
penalty is very small. We also never shrink the slice in this
implementation, which ensures that undoing work and then making
additional modifications is very efficient, but could be framed
as a memory leak.
- this implementation creates a new history element every time
we call replace(). This means that, on desktop, it's essentially
one per rune of input. Users likely want to be able to undo larger
units of change, so a future improvement could be to coalesce
changes so long as the selection doesn't change between them.
- I think it's possible to store only one of the Apply/Reverse
change contents in the history slice, but it's significantly
more complicated. To implement this, you'd need to add a field
indicating if the modification represented a forward or backward
change, and then rewrite the modification's content as you performed
undo/redo operations.For the time being, I'm not sure it's worth
this complexity.
- Future work could introduce a limit to the number of history
entries stored. If we did this, we should also change the
data structure for storing history. Enforcing such a limit
using a simple slice like this would be extremely inefficient.
Perhaps a ring buffer or a linked list would make more sense?
- Applications will likely want to be able to manipulate undo
history in the future. We may wish to export undo() and redo()
from the editor. Applications will also likely want a mechanism
to save the undo history to disk and restore it (implementing
persistent undo). I'm not sure what the most suitable API for
that is yet, so I decided not to try to tackle it yet.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
The unit.Value is a struct and thus more inconvenient to use than its
underlying float32 type. In addition, most uses don't need a general
value, but rather a specific unit given by the context. This change
replaces unit.Value with two float32 units, Dp and Sp. It also changes
variables and parameters of unit.Value to a specific unit type matching
the context. That is, unit.Dp everywhere except for text sizes which are
in Sp.
Switching to typed float32s has multiple advantages
- They can be constants:
const touchSlop = unit.Dp(16)
- Casting untyped constants is no longer necessary:
insets := layout.UniformInset(16)
- Calculation with values is natural:
func (s ScrollbarStyle) Width() unit.Dp {
return s.Indicator.MinorWidth + s.Track.MinorPadding + s.Track.MinorPadding
}
The main API change is that calls to gtx.Px must be replaced with either
gtx.Dp or gtx.Sp depending on the unit.
Idea by Christophe Meessen.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
op.Offset is a convenience function most often used by layouts. Layouts
usually operate in integer coordinates, and the float32 version of op.Offset
needlessly force conversions from int to float32. This change makes op.Offset
take integer coordinates, to better match its intended use.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Android doesn't distinguish between the arrow keys on a keyboard and the
directional keys on a remote control, so there's no way to move the caret
in an Editor with arrow keys. This change updates the Android port to map
Android's DPAD_* key codes to the arrow key names, fixing caret movement.
The change also updates Editor to only request arrow keys that actually move
the caret, to keep directional focus movement working.
Fixes: https://todo.sr.ht/~eliasnaur/gio/410
Signed-off-by: Mearaj <mearajbhagad@gmail.com>
Prior to this change an editor with no content and a zero minimum
constraint would return itself has having width zero. This
prevented users from being able to see the editor when they
moved focus to it, as it could not display its caret. This
simple change ensures that, at minimum, the editor returns
its dimensions to include the width of a caret.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Before this change, every Event would be passed to the focused InputOp
tag, making it impossible to implement, say, program-wide shortcuts.
This change implements key.Event routing similar to how pointer.Events
are routed: every InputOp describes the set of keys it can handle, and
the router use that information to deliver an Event to the matching
handler.
This is an API change, because every InputOp must now include a filter
matching the keys it wants to handle.
Fixes: https://todo.sr.ht/~eliasnaur/gio/395
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A meaningful clip area for a key handler will matter when we start
auto-scrolling to move focused handlers into view.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit ensures that text.Alignment is intuitive for
the direction of the text being aligned. RTL text with
Alignment Start will be aligned to the right edge of the area,
whereas LTR text with Alignment Start will continue to be
aligned to the left edge. Vice versa for the End alignment.
References: https://todo.sr.ht/~eliasnaur/gio/146
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
These fields are no longer needed with the new text shaper.
Advances is redundant to the glyph information, and Text
should never be used during layout, as you should
traverse the cluster list instead. This commit also removed
the now-unused string field from the path LRU cache key.
References: https://todo.sr.ht/~eliasnaur/gio/146
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit updates material.Editor and material.Label to support the
new text shaper. This requires breaking their assumption that glyphs
of font data map 1:1 to runes of text data.
References: https://todo.sr.ht/~eliasnaur/gio/146
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit introduces a new text shaping infrastructure
powered by Benoit Kugler's Go source-port of harfbuzz.
This shaper can properly display complex scripts and RTL
text. This commit changes the signature of the text.Shaper
function, which is a breaking API change.
The new functionality is available via opentype.ParseHarfbuzz,
which configures a text.Shaper leveraging the new backend.
References: https://todo.sr.ht/~eliasnaur/gio/146
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
We cannot find a way to trigger this flickering
condition anymore, and so we're removing the logic
guarding against it.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
This commit introduces logic to skip painting the
selection rectangle on lines prior to the line
containing the beginning of the selection.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
It's now possible to directly user pointer.Cursor to add to the ops.
pointer.CursorText.Add(gtx.Ops)
This is an API change. Use pointer.Cursor directly instead of CursorNameOp.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
This commit fixes the position returned by Editor.CaretCoords
to account for the scroll position of the editor. Without this
change, the returned coordinates can easily overflow the boundaries
of the editor widget when it has been scrolled on either axis.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
For some reason, widget.Editor had a Seek method that ignored
the supplied offset and always seeked to offset zero. This
made it impossible to use it like any other io.Seeker. This
commit simply honors the requested offset.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Pointer padding was introduced in bfece0beba.
I don't remember why, and its commit message doesn't say. Regardless, adding
padding outside a widget's reported dimensions doesn't seem like a good idea
(see #365), and this change removes it.
Fixes: https://todo.sr.ht/~eliasnaur/gio/365
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We'd like to re-use the Editor.closestPosition seeking for
segmentIterator.Next; this change extracts the state-less logic
into functions.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This change implements reporting of the caret position from Editor, as well
as Windows, macOS, Android support. As a result, the IME composition window
on Windows and macOS is now positioned correctly.
References: https://todo.sr.ht/~eliasnaur/gio/246
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit adds a testcase to catch unexpected panics in the
editor's scroll offset logic introduced by using different
setting combinations that affect editor layout. It also fixes
a panic for single-line editors with alignments other than
text.Start.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Only rune positions are tracked for carets, and they only need adjusting
when changing Editor content, not just for re-layout.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Egon Elbre