~eliasnaur/gio

11 3

blocking app.Main & integration w/ non-full GUI applications

Details
Message ID
<G3YHHEBjCyIpRU0gznQtW68aWJ7cmpP-ko4GXZFFdyW4oT2yYH_eHPivHNdJCuOikz0l5xx0Fux1ZV3xjEoJxrIDPpWxp6XspMfV8j_7-Ow=@sbinet.org>
DKIM signature
missing
Download raw message
hi there,

I am trying to integrate Gioui with a little application of mine that is terminal based.
it's a kind of REPL that can (among other things) display histograms stored in a binary file.
(think of it like a barebones gnuplot)

integrating that -reliably- with Gioui proves to be a bit troublesome:

- the user may want to display from zero to multiple histograms, from 1 to many files.

so my application may request Gioui to display from 0 to n windows.

ie:
- the application should not return when a window displaying an histogram is closed (because there may be others that will still need to be displayed)
- the application should properly return, even if no window was displayed.

with these "requirements" stated, it seems to me there are 3 ways to workaround the current behaviour of a blocking app.Main() (that needs to be on the main goroutine) that will return when the last window has been closed:

- have my application create a "hidden" window that will be closed when the program is instructed to shutdown (ie: ^C or some /quit command at the REPL)
- modify the app.Main function like so (like x/exp/shiny):

func Main(f func() error) error {
    return window.Main(f)
}

- have a way to programmatically shutdown app.Main

what do you think?
is this a valid use case for Gioui?

-s
Details
Message ID
<C3P8IVPGYJ0R.14R6AA3Z67O29@themachine>
In-Reply-To
<G3YHHEBjCyIpRU0gznQtW68aWJ7cmpP-ko4GXZFFdyW4oT2yYH_eHPivHNdJCuOikz0l5xx0Fux1ZV3xjEoJxrIDPpWxp6XspMfV8j_7-Ow=@sbinet.org> (view parent)
DKIM signature
pass
Download raw message
On Tue Jun 23, 2020 at 08:28, Sebastien Binet wrote:
> hi there,
>
> I am trying to integrate Gioui with a little application of mine that is terminal based.
> it's a kind of REPL that can (among other things) display histograms stored in a binary file.
> (think of it like a barebones gnuplot)
>
> integrating that -reliably- with Gioui proves to be a bit troublesome:
>
> - the user may want to display from zero to multiple histograms, from 1 to many files.
>
> so my application may request Gioui to display from 0 to n windows.
>
> ie:
> - the application should not return when a window displaying an histogram is closed (because there may be others that will still need to be displayed)
> - the application should properly return, even if no window was displayed.
>
> with these "requirements" stated, it seems to me there are 3 ways to workaround the current behaviour of a blocking app.Main() (that needs to be on the main goroutine) that will return when the last window has been closed:
>
> - have my application create a "hidden" window that will be closed when the program is instructed to shutdown (ie: ^C or some /quit command at the REPL)
> - modify the app.Main function like so (like x/exp/shiny):
>
> func Main(f func() error) error {
>     return window.Main(f)
> }
>

I find callbacks such as Shiny's a poor match for Go's goroutines, for the same
reason requests for goroutine local variables or IDs are consistently rejected.

> - have a way to programmatically shutdown app.Main
>
> what do you think?
> is this a valid use case for Gioui?
>

Sure. After implementing the multiple windows feature, I found the unblock
behaviour of app.Main awkward but didn't have time to rethink it.

You phrase your question as a request for unblocking of app.Main; I think it's
simpler to remove the magic behaviour of unblocking app.Main when the last
window is closed, leaving exit control in the hands of the program.

WDYT? The only downside is that every Gio program will need an explicit os.Exit
somewhere, at least if they want to behave nicely on desktop OS'es.

-- elias
Details
Message ID
<CAE_4BPD1cEgHwXxE4+oJPmyEhizMqBgG-_VkFLGNuzOJxqsQeA@mail.gmail.com>
In-Reply-To
<C3P8IVPGYJ0R.14R6AA3Z67O29@themachine> (view parent)
DKIM signature
missing
Download raw message
On Wed, Jun 24, 2020 at 5:46 AM Elias Naur <mail@eliasnaur.com> wrote:
> On Tue Jun 23, 2020 at 08:28, Sebastien Binet wrote:
> > - have a way to programmatically shutdown app.Main
> >
> > what do you think?
> > is this a valid use case for Gioui?
> >
>
> Sure. After implementing the multiple windows feature, I found the unblock
> behaviour of app.Main awkward but didn't have time to rethink it.
>
> You phrase your question as a request for unblocking of app.Main; I think it's
> simpler to remove the magic behaviour of unblocking app.Main when the last
> window is closed, leaving exit control in the hands of the program.
>
> WDYT? The only downside is that every Gio program will need an explicit os.Exit
> somewhere, at least if they want to behave nicely on desktop OS'es.

Could you close all your windows and restart app.Main later?  Possibly
multiple times?  E.g. in Chrome and iTerm2 on the Mac you can close
all windows, and then open some new ones.  And you can do this as many
times as you want.

Does app.Main really need to exit?

-- Larry
Details
Message ID
<C3PKOHSJ8FS4.21MHCZ9SZ4ND9@themachine>
In-Reply-To
<CAE_4BPD1cEgHwXxE4+oJPmyEhizMqBgG-_VkFLGNuzOJxqsQeA@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
On Wed Jun 24, 2020 at 09:20, Larry Clapp wrote:
> On Wed, Jun 24, 2020 at 5:46 AM Elias Naur <mail@eliasnaur.com> wrote:
> > On Tue Jun 23, 2020 at 08:28, Sebastien Binet wrote:
> > > - have a way to programmatically shutdown app.Main
> > >
> > > what do you think?
> > > is this a valid use case for Gioui?
> > >
> >
> > Sure. After implementing the multiple windows feature, I found the unblock
> > behaviour of app.Main awkward but didn't have time to rethink it.
> >
> > You phrase your question as a request for unblocking of app.Main; I think it's
> > simpler to remove the magic behaviour of unblocking app.Main when the last
> > window is closed, leaving exit control in the hands of the program.
> >
> > WDYT? The only downside is that every Gio program will need an explicit os.Exit
> > somewhere, at least if they want to behave nicely on desktop OS'es.
>
> Could you close all your windows and restart app.Main later?  Possibly
> multiple times?  E.g. in Chrome and iTerm2 on the Mac you can close
> all windows, and then open some new ones.  And you can do this as many
> times as you want.
>
> Does app.Main really need to exit?
>

It doesn't, and that's what I'm proposing: never exit from app.Main (except
where it never blocks: Android), and let the program decide when to os.Exit.

-- elias
Details
Message ID
<NvHk8wjc0Fq2cOl52H-AG7rRAdbFZeglutwT8_7JurJRhOw7Aq_Y4YXf22SUN47WUquW3xkKt2xXS_P0Kp06FBDi2DyIVUdHE2XBm8Swn4Y=@sbinet.org>
In-Reply-To
<C3PKOHSJ8FS4.21MHCZ9SZ4ND9@themachine> (view parent)
DKIM signature
missing
Download raw message




‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, June 24, 2020 9:17 PM, Elias Naur <mail@eliasnaur.com> wrote:

> On Wed Jun 24, 2020 at 09:20, Larry Clapp wrote:
>
> > On Wed, Jun 24, 2020 at 5:46 AM Elias Naur mail@eliasnaur.com wrote:
> >
> > > On Tue Jun 23, 2020 at 08:28, Sebastien Binet wrote:
> > >
> > > > -   have a way to programmatically shutdown app.Main
> > > >
> > > > what do you think?
> > > > is this a valid use case for Gioui?
> > >
> > > Sure. After implementing the multiple windows feature, I found the unblock
> > > behaviour of app.Main awkward but didn't have time to rethink it.
> > > You phrase your question as a request for unblocking of app.Main; I think it's
> > > simpler to remove the magic behaviour of unblocking app.Main when the last
> > > window is closed, leaving exit control in the hands of the program.
> > > WDYT? The only downside is that every Gio program will need an explicit os.Exit
> > > somewhere, at least if they want to behave nicely on desktop OS'es.
> >
> > Could you close all your windows and restart app.Main later? Possibly
> > multiple times? E.g. in Chrome and iTerm2 on the Mac you can close
> > all windows, and then open some new ones. And you can do this as many
> > times as you want.
> > Does app.Main really need to exit?
>
> It doesn't, and that's what I'm proposing: never exit from app.Main (except
> where it never blocks: Android), and let the program decide when to os.Exit.

wouldn't this make testing a bit more difficult than it ought to be?
at least it would make it a tad more cumbersome.
but ok.

-s
Details
Message ID
<C3Q07EBLKCJK.2ZW2TCUZ1XGZK@testmac>
In-Reply-To
<NvHk8wjc0Fq2cOl52H-AG7rRAdbFZeglutwT8_7JurJRhOw7Aq_Y4YXf22SUN47WUquW3xkKt2xXS_P0Kp06FBDi2DyIVUdHE2XBm8Swn4Y=@sbinet.org> (view parent)
DKIM signature
pass
Download raw message
On Wed Jun 24, 2020 at 10:48 PM CEST, Sebastien Binet wrote:
>

>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, June 24, 2020 9:17 PM, Elias Naur <mail@eliasnaur.com> wrote:
>
> > On Wed Jun 24, 2020 at 09:20, Larry Clapp wrote:
> >
> > > On Wed, Jun 24, 2020 at 5:46 AM Elias Naur mail@eliasnaur.com wrote:
> > >
> > > > On Tue Jun 23, 2020 at 08:28, Sebastien Binet wrote:
> > > >
> > > > > -   have a way to programmatically shutdown app.Main
> > > > >
> > > > > what do you think?
> > > > > is this a valid use case for Gioui?
> > > >
> > > > Sure. After implementing the multiple windows feature, I found the unblock
> > > > behaviour of app.Main awkward but didn't have time to rethink it.
> > > > You phrase your question as a request for unblocking of app.Main; I think it's
> > > > simpler to remove the magic behaviour of unblocking app.Main when the last
> > > > window is closed, leaving exit control in the hands of the program.
> > > > WDYT? The only downside is that every Gio program will need an explicit os.Exit
> > > > somewhere, at least if they want to behave nicely on desktop OS'es.
> > >
> > > Could you close all your windows and restart app.Main later? Possibly
> > > multiple times? E.g. in Chrome and iTerm2 on the Mac you can close
> > > all windows, and then open some new ones. And you can do this as many
> > > times as you want.
> > > Does app.Main really need to exit?
> >
> > It doesn't, and that's what I'm proposing: never exit from app.Main (except
> > where it never blocks: Android), and let the program decide when to os.Exit.
>
> wouldn't this make testing a bit more difficult than it ought to be?
> at least it would make it a tad more cumbersome.

How so? Can you elaborate?

-- elias
Details
Message ID
<M1DlMhGgfDIVRUOciBdDQjVPIwT9HQB0dVuSHA3okXa3ULQD1FR5J4nb5NetmM8cAkRAtNxHxHrx0g0-CVXkIPkiEpygw94_yzXSBS__c3w=@sbinet.org>
In-Reply-To
<C3Q07EBLKCJK.2ZW2TCUZ1XGZK@testmac> (view parent)
DKIM signature
missing
Download raw message
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, June 25, 2020 9:27 AM, Elias Naur <mail@eliasnaur.com> wrote:

> On Wed Jun 24, 2020 at 10:48 PM CEST, Sebastien Binet wrote:
>
> >
>
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Wednesday, June 24, 2020 9:17 PM, Elias Naur mail@eliasnaur.com wrote:
> >
> > > On Wed Jun 24, 2020 at 09:20, Larry Clapp wrote:
> > >
> > > > On Wed, Jun 24, 2020 at 5:46 AM Elias Naur mail@eliasnaur.com wrote:
> > > >
> > > > > On Tue Jun 23, 2020 at 08:28, Sebastien Binet wrote:
> > > > >
> > > > > > -   have a way to programmatically shutdown app.Main
> > > > > >
> > > > > > what do you think?
> > > > > > is this a valid use case for Gioui?
> > > > >
> > > > > Sure. After implementing the multiple windows feature, I found the unblock
> > > > > behaviour of app.Main awkward but didn't have time to rethink it.
> > > > > You phrase your question as a request for unblocking of app.Main; I think it's
> > > > > simpler to remove the magic behaviour of unblocking app.Main when the last
> > > > > window is closed, leaving exit control in the hands of the program.
> > > > > WDYT? The only downside is that every Gio program will need an explicit os.Exit
> > > > > somewhere, at least if they want to behave nicely on desktop OS'es.
> > > >
> > > > Could you close all your windows and restart app.Main later? Possibly
> > > > multiple times? E.g. in Chrome and iTerm2 on the Mac you can close
> > > > all windows, and then open some new ones. And you can do this as many
> > > > times as you want.
> > > > Does app.Main really need to exit?
> > >
> > > It doesn't, and that's what I'm proposing: never exit from app.Main (except
> > > where it never blocks: Android), and let the program decide when to os.Exit.
> >
> > wouldn't this make testing a bit more difficult than it ought to be?
> > at least it would make it a tad more cumbersome.
>
> How so? Can you elaborate?

in the code I control, I can make sure that a single "usr-main" function centralizes whether one should os.Exit(rc), and decide where it happens.

but in a full suite test setting, where I'd like to also go through the mechanics of app.Main and window creation, (and in a situation where app.Main() blocks forever), I am not sure one would be able to meet the 2 constraints:
- have app.Main() run on the main goroutine
- have the test successfully execute and terminate (w/o calling os.Exit)

(perhaps something could be done by way of installing a protocol between the application to be tested and testing.M. but that sounds like busy work to do for each and every Gio-based application to be tested.)

-s
Details
Message ID
<C3Q0Q1VNRE8O.160RZD9073PDS@testmac>
In-Reply-To
<M1DlMhGgfDIVRUOciBdDQjVPIwT9HQB0dVuSHA3okXa3ULQD1FR5J4nb5NetmM8cAkRAtNxHxHrx0g0-CVXkIPkiEpygw94_yzXSBS__c3w=@sbinet.org> (view parent)
DKIM signature
pass
Download raw message
On Thu Jun 25, 2020 at 9:39 AM CEST, Sebastien Binet wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, June 25, 2020 9:27 AM, Elias Naur <mail@eliasnaur.com> wrote:
>
> > On Wed Jun 24, 2020 at 10:48 PM CEST, Sebastien Binet wrote:
> >
> > >
> >
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Wednesday, June 24, 2020 9:17 PM, Elias Naur mail@eliasnaur.com wrote:
> > >
> > > > On Wed Jun 24, 2020 at 09:20, Larry Clapp wrote:
> > > >
> > > > > On Wed, Jun 24, 2020 at 5:46 AM Elias Naur mail@eliasnaur.com wrote:
> > > > >
> > > > > > On Tue Jun 23, 2020 at 08:28, Sebastien Binet wrote:
> > > > > >
> > > > > > > -   have a way to programmatically shutdown app.Main
> > > > > > >
> > > > > > > what do you think?
> > > > > > > is this a valid use case for Gioui?
> > > > > >
> > > > > > Sure. After implementing the multiple windows feature, I found the unblock
> > > > > > behaviour of app.Main awkward but didn't have time to rethink it.
> > > > > > You phrase your question as a request for unblocking of app.Main; I think it's
> > > > > > simpler to remove the magic behaviour of unblocking app.Main when the last
> > > > > > window is closed, leaving exit control in the hands of the program.
> > > > > > WDYT? The only downside is that every Gio program will need an explicit os.Exit
> > > > > > somewhere, at least if they want to behave nicely on desktop OS'es.
> > > > >
> > > > > Could you close all your windows and restart app.Main later? Possibly
> > > > > multiple times? E.g. in Chrome and iTerm2 on the Mac you can close
> > > > > all windows, and then open some new ones. And you can do this as many
> > > > > times as you want.
> > > > > Does app.Main really need to exit?
> > > >
> > > > It doesn't, and that's what I'm proposing: never exit from app.Main (except
> > > > where it never blocks: Android), and let the program decide when to os.Exit.
> > >
> > > wouldn't this make testing a bit more difficult than it ought to be?
> > > at least it would make it a tad more cumbersome.
> >
> > How so? Can you elaborate?
>
> in the code I control, I can make sure that a single "usr-main" function centralizes whether one should os.Exit(rc), and decide where it happens.
>
> but in a full suite test setting, where I'd like to also go through the mechanics of app.Main and window creation, (and in a situation where app.Main() blocks forever), I am not sure one would be able to meet the 2 constraints:
> - have app.Main() run on the main goroutine
> - have the test successfully execute and terminate (w/o calling os.Exit)
>
> (perhaps something could be done by way of installing a protocol between the application to be tested and testing.M. but that sounds like busy work to do for each and every Gio-based application to be tested.)
>

I don't think you can test without testing.M today, because even if
app.Main returns, you can't restart it on all platforms (macOS in
particular).

-- elias
Details
Message ID
<wquvlkg4r87_lQxyP2N1J19CBfMoqvDONrjYDxzM523b8SbKybQo1XQmL5VfhMKNUnda6PuzZEcEdCfh1Dlh27lU6YZ4L6q4OLDB4snbTqI=@sbinet.org>
In-Reply-To
<C3Q0Q1VNRE8O.160RZD9073PDS@testmac> (view parent)
DKIM signature
missing
Download raw message

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, June 25, 2020 9:52 AM, Elias Naur <mail@eliasnaur.com> wrote:
[...]
> > > > wouldn't this make testing a bit more difficult than it ought to be?
> > > > at least it would make it a tad more cumbersome.
> > >
> > > How so? Can you elaborate?
> >
> > in the code I control, I can make sure that a single "usr-main" function centralizes whether one should os.Exit(rc), and decide where it happens.
> > but in a full suite test setting, where I'd like to also go through the mechanics of app.Main and window creation, (and in a situation where app.Main() blocks forever), I am not sure one would be able to meet the 2 constraints:
> >
> > -   have app.Main() run on the main goroutine
> > -   have the test successfully execute and terminate (w/o calling os.Exit)
> >
> > (perhaps something could be done by way of installing a protocol between the application to be tested and testing.M. but that sounds like busy work to do for each and every Gio-based application to be tested.)
>
> I don't think you can test without testing.M today, because even if
> app.Main returns, you can't restart it on all platforms (macOS in
> particular).

ah. ok. (not super knowledgeable about all these details, obviously)

anyways, for my particular use-case, having app.Main() always block would be fine, I think.

aesthetically I would have opted for a net/http.ListenAndServe API (that could return an error when a "shutdown" message were to be received), but I defer to your better knowledge about GUIs.

cheers,
-s
Details
Message ID
<ce_O5yg0ExJyapA01TPVKiI49MbK-KFmGzYJhygiTw4ShfRH0yPgFGAz6kvVoacN4KvHZlldnquiIA7Q0hIrhfzoJPdpVLbrdVJVnP3vDBs=@sbinet.org>
In-Reply-To
<wquvlkg4r87_lQxyP2N1J19CBfMoqvDONrjYDxzM523b8SbKybQo1XQmL5VfhMKNUnda6PuzZEcEdCfh1Dlh27lU6YZ4L6q4OLDB4snbTqI=@sbinet.org> (view parent)
DKIM signature
missing
Download raw message
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, June 25, 2020 10:36 AM, Sebastien Binet <s@sbinet.org> wrote:

>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, June 25, 2020 9:52 AM, Elias Naur mail@eliasnaur.com wrote:
> [...]
>
> > > > > wouldn't this make testing a bit more difficult than it ought to be?
> > > > > at least it would make it a tad more cumbersome.
> > > >
> > > > How so? Can you elaborate?
> > >
> > > in the code I control, I can make sure that a single "usr-main" function centralizes whether one should os.Exit(rc), and decide where it happens.
> > > but in a full suite test setting, where I'd like to also go through the mechanics of app.Main and window creation, (and in a situation where app.Main() blocks forever), I am not sure one would be able to meet the 2 constraints:
> > >
> > > -   have app.Main() run on the main goroutine
> > > -   have the test successfully execute and terminate (w/o calling os.Exit)
> > >
> > > (perhaps something could be done by way of installing a protocol between the application to be tested and testing.M. but that sounds like busy work to do for each and every Gio-based application to be tested.)
> >
> > I don't think you can test without testing.M today, because even if
> > app.Main returns, you can't restart it on all platforms (macOS in
> > particular).
>
> ah. ok. (not super knowledgeable about all these details, obviously)
>
> anyways, for my particular use-case, having app.Main() always block would be fine, I think.
>
> aesthetically I would have opted for a net/http.ListenAndServe API (that could return an error when a "shutdown" message were to be received), but I defer to your better knowledge about GUIs.

I have a tentative CL over there:
https://git.sr.ht/~sbinet/gio/commit/e020f4381118b977df2a104e4d7987540b26797c

(for some reason, I can't submit it yet through the web interface, getting an internal server error...)

-s
Details
Message ID
<C3Q8HI44CDBC.2R9IPTFFAYZ6S@testmac>
In-Reply-To
<ce_O5yg0ExJyapA01TPVKiI49MbK-KFmGzYJhygiTw4ShfRH0yPgFGAz6kvVoacN4KvHZlldnquiIA7Q0hIrhfzoJPdpVLbrdVJVnP3vDBs=@sbinet.org> (view parent)
DKIM signature
pass
Download raw message
> diff --git a/app/app.go b/app/app.go
> index 6946809..fa4aa5f 100644
> --- a/app/app.go
> +++ b/app/app.go
> @@ -35,8 +35,8 @@ func DataDir() (string, error) {
>  	return dataDir()
>  }
>  
> -// Main must be called from the program main function. It
> -// blocks until there are no more windows active.
> +// Main must be called from the program main function.
> +// It blocks until os.Exit is called.
> 

While here, let's be complete:

	// Main must be called last from the program main function.
	// On most platforms Main blocks forever, for Android and
	// iOS it returns immediately to give control of the main
	// thread back to the system.


> diff --git a/app/internal/window/os_windows.go b/app/internal/window/os_windows.go
> index aed71ff..d611caa 100644
> --- a/app/internal/window/os_windows.go
> +++ b/app/internal/window/os_windows.go
> @@ -84,11 +80,6 @@ var resources struct {
>  }
>  
>  func Main() {
> -	// Wait for first window
> -	count := <-windowCounter
> -	for count > 0 {
> -		count += <-windowCounter
> -	}

Missing select{}?
Details
Message ID
<bJjWeinUfqGGcNzj1_cd3Fr55Wv1EEjeHqFRrnXiVie_2PRp_hZyTgmGHh7sNQWsUvIHlX3pujUtYnPCbxv1rE3yk3M0sEcaCss4Q9XBfOE=@sbinet.org>
In-Reply-To
<C3Q8HI44CDBC.2R9IPTFFAYZ6S@testmac> (view parent)
DKIM signature
missing
Download raw message




‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, June 25, 2020 3:57 PM, Elias Naur <mail@eliasnaur.com> wrote:

> > diff --git a/app/app.go b/app/app.go
>
> > index 6946809..fa4aa5f 100644
> > --- a/app/app.go
> > +++ b/app/app.go
> > @@ -35,8 +35,8 @@ func DataDir() (string, error) {
> > return dataDir()
> > }
> > -// Main must be called from the program main function. It
> > -// blocks until there are no more windows active.
> > +// Main must be called from the program main function.
> > +// It blocks until os.Exit is called.
>
> While here, let's be complete:
>
> // Main must be called last from the program main function.
> // On most platforms Main blocks forever, for Android and
> // iOS it returns immediately to give control of the main
> // thread back to the system.

done.

>
> > diff --git a/app/internal/window/os_windows.go b/app/internal/window/os_windows.go
> > index aed71ff..d611caa 100644
> > --- a/app/internal/window/os_windows.go
> > +++ b/app/internal/window/os_windows.go
> > @@ -84,11 +80,6 @@ var resources struct {
> > }
> > func Main() {
> >
> > -   // Wait for first window
> > -   count := <-windowCounter
> > -   for count > 0 {
> > -       count += <-windowCounter
> >
> >
> > -   }
>
> Missing select{}?

oops. thanks.

(I didn't handle macOS. someobody more knowledgeable about that platform/ObjC should tackle that)
Export thread (mbox)