Flex.End() returns a FlexChild.  And then you pass a set of
FlexChild(ren) to Flex.Layout().  Is there any reason End() shouldn't
just collect the children internally, leaving Layout() with 0 args?

Maybe you can do something with a FlexChild that I'm unaware of?  Or
maybe wouldn't *necessarily* want to pass all the children to
Layout()???  But in that case, End() could return the child *and
still* keep it internally, and then if you give Layout() 0 args, use
the internal list.

Thoughts?

-- L

On Wed, Aug 21, 2019 at 10:35:02AM +0200, Elias Naur wrote:
> It turned out I wanted the change for my Gophercon UK talk :)

:)  No worries.  Sorry for the delay.

Your patch ended up being more thorough than mine anyway, with the
os_*.go changes.

One thing I want to point out: by making app.windowOptions unexported,
you prohibit other packages from making their own option functions.
Which may be what you want?  (E.g. the go-grpc package does the same
thing.)  Having the only WithWidth function lets you put the panic
earlier in the call chain, so it's a trade-off.

On Mon, Aug 19, 2019 at 4:58 PM Elias Naur <mail@eliasnaur.com> wrote:
> On Mon, Aug 19, 2019 at 7:37 PM Larry Clapp <larry@theclapp.org> wrote:
> > How can I get SourceHut to not send me messages to the Gio mailing
> > list that *I sent*?  Gmail remembers those for me, I don't need
> > another copy.
>
> I don't think I receive copies of sourcehut mail I send. Can you provide me
> with a copy of such copy?

Hmmm.  I take it back.  I think it's either mutt or Gmail.  (Mutt's
sending via Gmail servers.)

Here are the two copies of my initial question.  Neither of which has
SourceHut servers mentioned in its headers.

How can I get SourceHut to not send me messages to the Gio mailing
list that *I sent*?  Gmail remembers those for me, I don't need
another copy.

I looked for a SourceHit mailing list or todo list and couldn't find
one.  As others have noted, the discoverability of stuff at SH isn't
great.

Thanks.

--L

On Mon, Aug 19, 2019 at 09:02:08AM -0400, Gregory Pomerantz wrote:
> Here is an alternative to functional options that does compile-time
> checking to ensure that unsupported options are not sent to
> constructors. The compiler might even provide useful error messages.

Neat idea!

On Mon, Aug 19, 2019 at 05:37:30PM +0200, Elias Naur wrote:
> In other words, this should definitely be supported, but requires
> some thought about the proper design. My instinct suggest a
> specialized text.LabelLayout (or layout.Text) that can only lay out
> text.Labels. In turn, text.Label might need to grow support for
> starting in the middle of a line.
> 
> As you can tell, I haven't thought it through :)
> 
> Please do file an issue so we won't forget.

https://todo.sr.ht/~eliasnaur/gio/23

-- L

On Mon, Aug 19, 2019 at 06:31:13AM +0200, Elias Naur wrote:
> On Mon, Aug 19, 2019 at 3:48 AM Larry Clapp <larry@theclapp.org> wrote:
> > The text widget appears to force its sub-widgets into a slice of
> > lines.  (In HTML parlance, a bunch of "div" widgets.)  That's not
> > what I want.
> 
> I'm not sure what you mean here. How can the text widget
> (text.Label, right?) have sub-widgets?

Perhaps "sub-widgets" was the wrong word.  What I meant was,
text.Label is organized as an array (slice) of Lines, each of which
denotes a bunch of text all the way from the left margin (constraint?)
to the right margin.

I'd like to lay out several bits of text, and build different pop-up
mouse-over text for each bit of text.  A bit might not be a whole
line.  In HTML parlance, I want "span" widgets, to which I will then
attach individualized behavior.

So for example

  [Each of these][ bits of][ bracketed
  text][ gets a different][ popup.]

And given a wide enough window I'd of course like it to be

  [Each of these][ bits of][ bracketed text][ gets a different][ popup.]

On Sun, Aug 18, 2019 at 04:56:17PM -0400, Gregory Pomerantz wrote:
> >    func WithFont(name string) Option {
> > 	  return newFuncOption(func(o Optioner) {
> > 		  if o, ok := o.(*editorOptions); ok {
> > 			  o.fontName = name
> > 		  }
> > 	  })
> >    }
> Looks like this will panic if you send the wrong type of option,
> would much prefer for the compiler to be able to check these.

I don't see how?  It does a type check.

-- L

On Sun, Aug 18, 2019 at 09:28:48AM +0200, Elias Naur wrote:
> Drop or change.

I can do all of those things, but just to clarify: Having an Optioner
interface instead of using the WindowsOptions (or windowsOptions) type
directly was so that different kinds of things could use the same
Options type, and even the same option function.  So e.g. you could
call WithHeight and WithWidth against multiple different kinds of
things that all had height and width, and they'd figure out what
they'd been called on and act accordingly.

As Gregory Pomerantz mentioned in an earlier thread:

> One inconvenience is that the same option for different types