From Larry Clapp to ~eliasnaur/gio-patches
ScrollTo: Scroll a list so the given index is visible. PageUp & PageDown: Scroll up and down by the list height. Signed-off-by: Larry Clapp <larry@theclapp.org> --- layout/list.go | 78 ++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 70 insertions(+), 8 deletions(-) Discussion: No tests yet, sorry. ScrollTo is much simpler than in v1, though. diff --git a/layout/list.go b/layout/list.go index a9e2a9e..15ebe63 100644 [message trimmed]
From Larry Clapp to ~eliasnaur/gio-patches
Signed-off-by: Larry Clapp <larry@theclapp.org> --- widget/material/button.go | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) Commentary: Not really v2, just a resend. diff --git a/widget/material/button.go b/widget/material/button.go index ba9c8e6..562cf5e 100644 --- a/widget/material/button.go +++ b/widget/material/button.go @@ -25,6 +25,7 @@ type Button struct { TextSize unit.Value Background color.RGBA [message trimmed]
From Larry Clapp to ~eliasnaur/gio-patches
On Sat, Feb 15, 2020 at 2:08 PM Elias Naur <mail@eliasnaur.com> wrote: > I see now why my idea wasn't any good, sorry for wasting your time. No worries. > However, I'm still not convinced your approach is a good idea. For example, > your method will not support button labels that otherwise fall back to multiple > lines if insets were preserved (e.g. a "Delete now" that displays as > "Delete\nnow" on two lines when squeezed). > > How about adding an Insets field to Button, initialized by the > material.Theme.Button method, and honored in material.Button.Layout? You can > then tweak the insets (possibly to 0) before calling Layout.
From Larry Clapp to ~eliasnaur/gio-patches
On Fri, Feb 14, 2020 at 8:07 AM Elias Naur <mail@eliasnaur.com> wrote: > Sorry for not being clear. I'm wondering whether it would be useful to add this > inset squeezing logic to the layout.Inset.Layout method? More precisely, > layout.Inset can be changed to cope with its child widget overflowing the inset > constraints, by adjusting the final TransformOp So I tried this, and maybe I did it wrong, but I couldn't get it to work. It turns out that a lot of widgets will take whatever space you give them (reasonably enough), so unless you reduce the constraint by the insets, they'll take up that space. And if you *do* reduce the constraints by the insets, then it's impossible for the widget to take up more space than that, so there's
From Larry Clapp to ~eliasnaur/gio-patches
You mean, like, pass inset values (or maybe just an Inset object) into the Layout function? That seemed pretty intrusive. Also, I know we're trying to conform to the Material Design spec (which I think is a good idea, in general), and I assumed that the insets you'd hardcoded conformed to that spec, and (in general) shouldn't be changed. But I also wanted a shorter button, so I made it care about the constraints I gave it. If you meant something else, well, please elaborate. :) — L On Thu, Feb 13, 2020 at 12:07 PM Elias Naur <mail@eliasnaur.com> wrote: >
From Larry Clapp to ~eliasnaur/gio-patches
Constrain button insets to gtx.Constraints. Signed-off-by: Larry Clapp <larry@theclapp.org> --- widget/material/button.go | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/widget/material/button.go b/widget/material/button.go index ba9c8e6..ad78bb8 100644 --- a/widget/material/button.go +++ b/widget/material/button.go @@ -60,7 +60,9 @@ func (b Button) Layout(gtx *layout.Context, button *widget.Button) { col := b.Color bgcol := b.Background [message trimmed]
From Larry Clapp to ~eliasnaur/gio
Key release notifications are used (for example) by Gmail's paged list of emails. You can hold down the "j" key to move the selection down, but it stops when you get to the bottom of the page until you release the key, and only moves to the next page (next email) when you press "j" again. Ditto using the "k" key to go up. Disclaimer: I don't *know* that Gmail actually gets a "key release" notification *per se*, but it certainly behaves as if it does. It may just detect that you have the key held down by the frequency and timing of the key events, I dunno. But certainly, if you wanted to implement a similar behavior in Gio, a key release event would be handy. Come to think of it, I actually have a list in my own app, where going
From Larry Clapp to ~eliasnaur/gio-patches
Done. See v2. On Thu, Feb 6, 2020 at 2:17 AM Elias Naur <mail@eliasnaur.com> wrote: > > On Wed Feb 5, 2020 at 9:52 AM, Larry Clapp wrote: > > - Focused: returns whether editor is focused > > - CaretPos: returns the text line & column number, and the x & y pixel > > coordinates of the caret. > > > > > > Note: Returns them in that order. Which seems odd: line & column is > > basically "y, x", but then the pixel coordinates are x & y. So > > wondering if swapping line & column in CaretPos (and possibly in
From Larry Clapp to ~eliasnaur/gio-patches
- 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> --- widget/editor.go | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/widget/editor.go b/widget/editor.go index 0e41c89..35bac2e 100644 --- a/widget/editor.go +++ b/widget/editor.go [message trimmed]
From Larry Clapp to ~eliasnaur/gio-patches
- Focused: returns whether editor is focused - CaretPos: returns the text line & column number, and the x & y pixel coordinates of the caret. Note: Returns them in that order. Which seems odd: line & column is basically "y, x", but then the pixel coordinates are x & y. So wondering if swapping line & column in CaretPos (and possibly in Editor.layoutCaret which it calls) would be appropriate? - NumLines: returns the number of text lines in the editor Signed-off-by: Larry Clapp <larry@theclapp.org> --- widget/editor.go | 15 +++++++++++++++ 1 file changed, 15 insertions(+) [message trimmed]