~theclapp

Recent activity

[PATCH] layout: add List.ScrollTo 9 days ago

From Larry Clapp to ~eliasnaur/gio-patches

Scroll a list so the given index is visible.

Signed-off-by: Larry Clapp <larry@theclapp.org>
---
 layout/list.go | 35 +++++++++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/layout/list.go b/layout/list.go
index a9e2a9e..db858da 100644
--- a/layout/list.go
+++ b/layout/list.go
@@ -46,6 +46,7 @@ type List struct {
 
 	// maxSize is the total size of visible children.
[message trimmed]

Re: Very tall widgets 14 days ago

From Larry Clapp to ~eliasnaur/gio

On Fri, Jan 03, 2020 at 10:38:54PM +0100, Elias Naur wrote:
> On Fri Jan 3, 2020 at 1:40 PM, Larry Clapp wrote:
> > I set the inner List's max height to be the real window height,
> > but since it's a ScrollToEnd list, that also didn't work. It did
> > work when the output was longish (> one window), but failed when
> > it wasn't (< one window), because the shorter command output
> > always took up a whole window, even though it might only be 111
> > pixels tall.
> >
> 
> Why does the inner child take up the entire window? The outer List
> does pass inf (1e6) for the max height, but you should be able to
> pass 0 as the min height.

Very tall widgets 15 days ago

From Larry Clapp to ~eliasnaur/gio

Yesterday in the GioUI slack channel[1] I mentioned some performance
problems I'm having with my Gio app (macOS).  I fixed one of them (too
many Layouts!), but another has come up: How to display very tall
widgets, e.g. ~248k pixels?

I'm writing something akin to a terminal.  I run commands and display
the output.  Some of the output is, of course, fairly long.  (In Slack
I mentioned "the bash manpage", which is > 4k lines, ~430 kb, and, as
alluded to above, ~248,000 pixels.)

Initially I did the entire output in a single Theme.Body1 widget.
That was great for short commands, but not for longer ones.  As near
as I could tell, the entire widget was rendered, and then clipped to
fit the window.  When the widget is 111 pixels, no problem; when the

[PATCH v7] widget: add some rudimentary exported editing methods a month ago

From Larry Clapp to ~eliasnaur/gio-patches

Editor.Delete
Editor.Move
Editor.Insert

Move the Editor.command method up above all the functions it calls.

Signed-off-by: Larry Clapp <larry@theclapp.org>
---
 widget/buffer.go | 43 ++++++++++++-----------
 widget/editor.go | 88 ++++++++++++++++++++++++------------------------
 2 files changed, 65 insertions(+), 66 deletions(-)

7th time's the charm?  :)
[message trimmed]

[PATCH v6] widget: add some rudimentary exported editing methods a month ago

From Larry Clapp to ~eliasnaur/gio-patches

Editor.Delete
Editor.Move
Editor.Insert

Move the Editor.command method up above all the functions it calls.

Signed-off-by: Larry Clapp <larry@theclapp.org>
---
 widget/buffer.go | 49 +++++++++++++++----------
 widget/editor.go | 95 ++++++++++++++++++++++++++----------------------
 2 files changed, 80 insertions(+), 64 deletions(-)

v6 commentary: Apologies, I forgot to save before committing & emailing.
Whoops.
[message trimmed]

[PATCH v5] widget: add some rudimentary exported editing methods a month ago

From Larry Clapp to ~eliasnaur/gio-patches

Editor.Delete
Editor.Move
Editor.Insert

Move the Editor.command method up above all the functions it calls.

Signed-off-by: Larry Clapp <larry@theclapp.org>
---
 widget/buffer.go | 53 ++++++++++++++++----------
 widget/editor.go | 96 ++++++++++++++++++++++++++----------------------
 2 files changed, 85 insertions(+), 64 deletions(-)

diff --git a/widget/buffer.go b/widget/buffer.go
index 22e8451..98a5d21 100644
[message trimmed]

Re: [PATCH v4] widget: add some rudimentary exported editing methods a month ago

From Larry Clapp to ~eliasnaur/gio-patches

On Sun, Dec 15, 2019 at 08:29:29PM +0100, Elias Naur wrote:
> On Sun Dec 15, 2019 at 12:33 PM Larry Clapp wrote:
> > +func (e *editBuffer) deleteRunes(runes int) {
> > +	if runes == 0 {
> > +		return
> > +	}
> 
> The way you've structured the code, you don't need this check.

I can't guarantee that the current caller (Editor.Delete) will always
be the only caller, though.

> > -func (e *editBuffer) deleteRune() {
> >  	e.moveGap(0)

Re: [PATCH v3] widget: add some rudimentary exported editing methods a month ago

From Larry Clapp to ~eliasnaur/gio-patches

On Fri, Dec 06, 2019 at 01:03:31PM +0100, Elias Naur wrote:
> The unexported methods were tailored for key presses. If we're going
> to export them, let's make them more generally useful:
> 
> 	// Delete runes from the caret position. The sign of runes specify the
> 	// direction to delete: positive is forward, negative mean backward.
> 	func (e *Editor) Delete(runes int)

Done.  See v4.

> > +// Insert inserts text at the caret, moving the caret to the right.
> 
> "right" => "forward" to avoid as much right-to-left language
> confusion as possible.

[PATCH v4] widget: add some rudimentary exported editing methods a month ago

From Larry Clapp to ~eliasnaur/gio-patches

Editor.Delete
Editor.Move
Editor.Insert

Move the Editor.command method up above all the functions it calls.

Signed-off-by: Larry Clapp <larry@theclapp.org>
---
 widget/buffer.go | 53 ++++++++++++++++----------
 widget/editor.go | 96 ++++++++++++++++++++++++++----------------------
 2 files changed, 85 insertions(+), 64 deletions(-)

diff --git a/widget/buffer.go b/widget/buffer.go
index 22e8451..98a5d21 100644
[message trimmed]

Re: Layout help a month ago

From Larry Clapp to ~eliasnaur/gio

This worked perfectly almost as-is.  (The only thing missing was
"float32(height)", i.e. "int(.25 * float32(height))".  Instead I used
"height / 4". :)  Thanks!

I did try doing the Rigid calls in this order before, but it didn't
occur to me to change the constraints in the first call.  I assumed
that I should be able to achieve what I wanted with a Flex and a
Rigid, and that monkeying around with Constraints was overkill and/or
shouldn't be necessary and/or bad style.  But apparently I was wrong!
:)

Thanks again.

Gregory Pomerantz: