On Wed, Jun 29, 2022 at 12:30 PM Larry Clapp larry@theclapp.org wrote:
> Could pointer.Event be extended to include the InputOp that triggered it?

I realize now that this is basically a specialization of an idea you
mentioned in your initial email:

> A solution that came to mind is based on how callbacks in C tend to work, accepting and delivering a void* for user data. The Go equivalent would add a UserData interface{} field to pointer.InputOp and pointer.Event. Any UserData provided in the InputUp would be copied to the Event. It would then be possible to use a single tag for many different InputOps and differentiate based on the UserData. Much like the Tag, this would incur no additional allocations as long as the user uses pointers.

:shrug:

-- Larry

Could pointer.Event be extended to include the InputOp that triggered it?

-- Larry

On Wed, Jun 29, 2022 at 11:27 AM Larry Clapp <larry@theclapp.org> wrote:
>
> Another solution that comes to mind is to extend Gio such that if you
> provide a slice of tags, it returns events for any/all of them.  Then
> you could have a "global" tag for all spans, *and also* a unique tag
> per span.  This would also let you group non-contiguous spans, which
> my previous idea wouldn't.
>
> Actually, that brings up a third solution: Combine the two.  For each
> span, generate a pass-through area with the global tag (to see if

Another solution that comes to mind is to extend Gio such that if you
provide a slice of tags, it returns events for any/all of them.  Then
you could have a "global" tag for all spans, *and also* a unique tag
per span.  This would also let you group non-contiguous spans, which
my previous idea wouldn't.

Actually, that brings up a third solution: Combine the two.  For each
span, generate a pass-through area with the global tag (to see if
anything was clicked at all), and then underneath it an area with a
unique tag.

So far, of the three, I like this last one best.

-- Larry

Since pointer events can be marked "pass through", it seems like you
could put a single large pass through area over your entire trace, so
that you know if a span was clicked at all, and only then search the
list of visible spans.

It seems like you could do this recursively and thus have something
similar to a binary- or B-tree search, or failing that use a single
layer of multiple top-level areas to divide up your list of widgets by
some (perhaps variable) factor.

-- Larry

On Tue, Jun 28, 2022 at 5:24 PM Dominik Honnef <dominik@honnef.co> wrote:
>

FWIW, it can also be handy to know that items can be drawn "out of
order", and in particular can be drawn "backwards", i.e. from last to
first, and also that (at least in the current implementation) it draws
visible stuff and then one more that's before whatever that first
actually-visible item is, for tab focus navigation.

-- Larry

p.s. On other fronts, I still hate that this mailing list won't accept
html email, like from Gmail, the 2nd most popular email client in the
world. [Litmus.com, 2021]


On Tue, May 3, 2022 at 2:01 AM Elias Naur <mail@eliasnaur.com> wrote:

Ah, thanks.  Yeah, that seems reasonable to me.

-- Larry

On Mon, May 2, 2022 at 4:24 AM Elias Naur <mail@eliasnaur.com> wrote:
>
> On Sun, 1 May 2022 at 15:32, Larry Clapp <larry@theclapp.org> wrote:
> >
> > See subject.
> >
> > In particular, why is "ctrl" both "Short" and "ShortAlt" on non-macOS?
> >  Both Windows & Linux have and support the "alt" key.  Why wouldn't
> > "ShortAlt" be "alt" on all platforms?
> >

See subject.

In particular, why is "ctrl" both "Short" and "ShortAlt" on non-macOS?
 Both Windows & Linux have and support the "alt" key.  Why wouldn't
"ShortAlt" be "alt" on all platforms?

— Larry

Thanks, Chris, that was helpful.

I'm adding this to my shell app.  Wow, I have a lot of hotkeys.  :)


On Fri, Apr 15, 2022 at 4:29 PM Chris Waldon
<christopher.waldon.dev@gmail.com> wrote:
>
> FYI, I've thrown together a quick example of how to use this new API here:
>
> https://go.dev/play/p/VDQg6sxRyA4

On Fri, Apr 15, 2022 at 11:54 AM Elias Naur <mail@eliasnaur.com> wrote:
> In other words, I didn't implement InputOp.Keys because I particularly like its
> interface, but because there is no way to enforce pure functions in Go.

Fair enough, and thanks for the explanation, I appreciate it.

I guess as I hinted at there's room for optimization.  You could have
a private "initialized" flag, which if it's false then you parse the
string and store all the keys in a map, and then after that it's just
a sync.Mutex.Lock() and a couple of map lookups.  Or something like
that.

Or maybe I could benchmark the parser and satisfy myself that it's
"fast enough" and stop talking outta my ass.  :)  I realized yesterday

I guess it's a good thing you did this yourself, 'cause I would not
have come up with that interface.  Nor did I realize that it should
apply only to key.Event; I thought you wanted it to apply to
key.EditEvent too, which is where I thought it would get really
cumbersome and error prone.

I obviously haven't used this yet, but so far, reading it, I'm not
really a fan.  It seems like you'll have to describe your key filter
twice, once in the tag filter in an ad-hoc DSL, which IIUC is reparsed
for every key event (though I suppose that could be optimized), and
which has literal key names like ⇞ and ⇟ ("what could go wrong?") (or
you can build them out of e.g. key.NamePageUp, I guess), and then once
in Go code in a switch statement.