On Thu, Jul 7, 2022 at 3:35 AM Elias Naur <mail@eliasnaur.com> wrote:
> This is only a problem on macOS; other platforms only have a "close window"
> shortcut/button and leave the process running. That's the reason for `os.Exit`
> calls such as
>
> https://git.sr.ht/~eliasnaur/gio-example/tree/main/item/kitchen/kitchen.go#L79
>
> It seems to me we should block Cmd-Q from quitting, and leave it to close all
> open windows. A bit more involved but also useful is to add a ClosingEvent
> that can be cancelled. For simplicity, we could cheat a bit and make it a
> key.Event like the Android back button. Then we get cancellation for free.

Hmm. So if we made it an event like any other, an app would have to notice that
and explicitly exit on its own. But I think you're saying, on non-macOS apps,

My Gio app maintains state in a remote server.  I'd like to be able to
tell the remote server that I'm closing, so it can release/close that
state.

I listen for the DestroyEvent, but there's no delay or acknowledgement
that you've processed the event, so Gio sends the event and goes on
with its shutdown process, and frequently seems to exit the process
before I'm done talking to the remote server.  There doesn't seem to
be any way to say "please wait till I'm done with this shutdown
procedure before you exit".

I've added a 2ms sleep at the end of app/os_macos.go's gio_onClose and
that seems to do the trick, at least some of the time.  Obviously
that's a shitty solution but it does give you an idea of the kind of

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