From Larry Clapp to ~eliasnaur/gio
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
From Larry Clapp to ~eliasnaur/gio
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
From Larry Clapp to ~eliasnaur/gio
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
From Larry Clapp to ~eliasnaur/gio
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: >
From Larry Clapp to ~eliasnaur/gio-patches
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:
From Larry Clapp to ~eliasnaur/gio
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? > >
From Larry Clapp to ~eliasnaur/gio
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
From Larry Clapp to ~eliasnaur/gio
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
From Larry Clapp to ~eliasnaur/gio
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
From Larry Clapp to ~eliasnaur/gio
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.