Gui.cs: Portable applications must not call initscr() twice

[BDisp]

See here https://pubs.opengroup.org/onlinepubs/007908799/xcurses/initscr.html.

I don't know how to do miracles!

[tig]

There must be a way to adjust the Linux driver to honor both requirements:

1) Present to Application that the console is "fresh" after Shutdown has been called.
2) Not call initscr() twice.

Right?

[BDisp]

There must be a way to adjust the Linux driver to honor both requirements:

1. Present to `Application` that the console is "fresh" after `Shutdown` has been called.

That information is already fresh when it going being to call the Init.

2. Not call `initscr()` twice.

There are no way to avoid that because a endwinwas called on the Endmethod. The only way to do this is really not closing the driver.

Right?

I don't think so. Believe me I already spent hours studying and investigating this and I always read all the same response. I think the Initand Shutdownshould create and close the driver only once. Run, Beginand Endcan be called as many times is needed. So there will be two Disposeprocess. One for each RunStateand another when the application is shutdown. Only Shutdownmethod can call the Driver.End.

[migueldeicaza]

Good catch.

I was never thinking that Application could be started/shut down, but I imagine this is someone's useful scenario.

Because endwin needs to be called, we do need to differentiate Application existing the run loop and an actual shutdown. I am afraid that this distinction will make the code more cumbersome for people that do not care about the scenario of reusing the application over and over.

Is there a reason to support initializing the application multiple times? Almost no UI framework supports this scenario, and it looks like gui.cs is taking on additional duties that might be useful for a few narrow scenarios, but come at the expense of the simpler scenarios.

I would rather make it so that simple scenarios remain simple, and those that want to reinitialize Application multiple times have to use additional APIs to do so. Optimizing for the simpler use case.

[BDisp]

Is there a reason to support initializing the application multiple times?

In my opinion there isn't make sense, as long as the same window is always used, this does not make sense because they are not really standalone applications.

[tig]

There are two use cases that drive wanting to ensure Shutdown actually cleans up as much as possible (and initializing Application more than once):

• UI Catalog such that it's very easy for contributors to build Scenarios that start/stop in a deterministic way. The main app is a "container" for Scenarios which are really mini-Terminal.gui apps.
• Unit tests. The design of Application.Init/Shutdown is either deterministic or it is not. If it is not, then it will be impossible for unit tests to actually test proper behavior.

I do not think what we're talking about makes creating typical Terminal.gui apps any easier or harder. The API you defined originally has not changed in this regard. All we're trying to do is to figure out (as far as possible) to ensure the APIs, as defined, actually work as defined...while also allowing us to actually have test code that proves (within reason) that the code hasn't broken.

If it were possible/reasonable to have UI Catalog and the unit tests create new processes/consoles for each test case, we could go that route. But I looked into it and it will be a TON of work and actually just moves the problem around, esp cross platform.

If the Linux driver can't call endwin more than once, then fine. Just make sure that it does everything it can to reset the rest of its internal state in the call to Shutdown.

[tig]

Is there a reason to support initializing the application multiple times?

In my opinion there isn't make sense, as long as the same window is always used, this does not make sense because they are not really standalone applications.

[BDisp]

You can make standalone apps always within the same window? It's break in WindowsDriver too and I make an workaround but it's ugly.

[BDisp]

I presented the changed unit test and all it's working.

[BDisp]

Every time a scenario is exit it has only toplevel, unless a dialog is show up. Dispose works well too.

[tig]

I think @BDisp solved this correctly in #804. Well done.

[BDisp]

@tig thank you very much for your understanding.

[tig]

I think the back and forth and debate is great. Very healthy.