Build failed because I made use of `TryLock` which is only available
since Go 1.18.

Build failed because my solution makes use of `TryLock` which is only
available since Go 1.18.  

On Jul 12 2022, at 3:47 pm, builds.sr.ht <builds@sr.ht> wrote:

> gio/patches: FAILED in 24m7s
>  
> [app: [X11] fix window destroy/wakeup race condition][0] from [~jackmordaunt][1]
>  
> [0]: https://lists.sr.ht/~eliasnaur/gio-patches/patches/33785
> [1]: jackmordaunt.dev@gmail.com
>  
> ✗ #799925 FAILED  gio/patches/freebsd.yml https://builds.sr.ht/~eliasnaur/job/799925
> ✗ #799926 FAILED  gio/patches/linux.yml   https://builds.sr.ht/~eliasnaur/job/799926

Hello! 

We can set window title by supplying the `app.Title` option to window
creation. However, I have not identified a means to reset the title
after the window is created (maybe I just missed it?). 

I propose we surface the ability to reapply options, or at least the
title option, perhaps by surfacing a `Configure` method on high-level
`app.Window` object. 

I understand that we would be at the mercy of the drivers, and support
for changing options at runtime my not be available for any given drive,
however I remain ignorant of those details at this point.

On Jun 22 2022, at 9:00 pm, Chris Waldon
<christopher.waldon.dev@gmail.com> wrote:

> On Wed, Jun 22, 2022 at 12:55 AM Jack Mordaunt
> <jackmordaunt.dev@gmail.com> wrote:
>> 
>> Hey! This is my retro-active review of the recent skel changes.
> 
> Hi Jack, I guess I should have posted those changes as patches. I thought
> they weren't going to be contentious, and I was eager to use them, so I
> merged them. We can definitely revise them as patches though.
> 

@Chris You raise good points, and I ultimately I agree with your conclusion.
Let's leave it then! Though I would still like to drop the "And" part.
;)

Hey! This is my retro-active review of the recent skel changes.

I noticed that we explicitly internalize the `future` method on the the
skel connection.

I don't like this because:

A) it means no third party can implement the interface
B) it's not a "hard error" to use it, merely a choice for the caller 

I acknowledge that exporting it would avail two ways to do the futures
(dynamic and type-safe) which you could argue makes the API more
complex/confusing, however we can't help that Go hasn't implemented
generic methods which forces us into using a function wrapper.

Hi Andrew, I like this!

I wonder if we can take this further and push the function definitions
into the type constraints. I've read that this is ideal in the current
implementation of generics, since it provides more opportunity for
in-lining.

    func Future[T any, Work WorkFunc[T], Then AndThenFunc[T]](c
Connection, w Work, th Then) 

I'm not even sure that snippet is valid, but you know what I mean. 

Perhaps we can also drop the `And` prefix, `ThenFunc` seems plenty
fine to me.

Small note to make clear how the window behaviour
changes when you call for custom rendering.

Signed-off-by: Jack Mordaunt <jackmordaunt.dev@gmail.com>
---
 app/window.go | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/app/window.go b/app/window.go
index 79899bfb..f958f848 100644
--- a/app/window.go
+++ b/app/window.go
@@ -827,6 +827,10 @@ func NavigationColor(color color.NRGBA) Option {
 
[message trimmed]

In the case where an application schedules from it's own
goroutine we can't guarantee that no work will be submitted
after a connection is closed and disconnected.

This patch guards against this by setting an atomic on the
connection and checking that before attempting to submit
work.

When the connection is marked "closed", any submissions
thereafter will be ignored. The work will not be executed
and no result will be delivered over the (closing or closed)
output channel.

v2: mark the connection as closing prior to disconnection, not
[message trimmed]

In the case where an application schedules from it's own
goroutine we can't guarantee that no work will be submitted
after a connection is closed and disconnected.

This patch guards against this by setting an atomic on the
connection and checking that before attempting to submit
work.

When the connection is marked "closed", any submissions
thereafter will be ignored. The work will not be executed
and no result will be delivered over the (closing or closed)
output channel.

Signed-off-by: Jack Mordaunt <jackmordaunt.dev@gmail.com>
[message trimmed]