Gui.cs: ConsoleDrivers don't implement support for Init/Shutdown correctly

[daltskin]

• Start the app
• Double click title bar to go full screen
• Select a screen eg. Editor

The screen opens - but isn't using the full screen width & height.

Related to #683?

[BDisp]

@daltskin this has to do with the Driverresetting by closing and reopen which will reopen with the default length console window. This has happened before too.

[tig]

I will take responsibility for this. I didn't cause it, but I forced it to be an issue by insisting that UI Catalog honor the Application.Init and Application.Shutdown APIs as they were spec'd and intended. Because maintainers of this project used the lame demo.cs as the ONLY tests for this project, bugs in these codepaths were never exposed.

As soon as I wrote UI Catalog to actually use these APIs, the related bugs became apparent.

The right fix is to go into ConsoleDriver and the classes that derive from it and fix how they use the underlying systems such that callers can use Init and Shutdown properly.

[tig]

I will admit the priority of this is pretty low given the use-case driven by UI Catalog forcing it is convoluted and unlikely to appear in a "real app". UI Catalog has mission of providing sample code a 'container' to run it that makes it easy to build new samples. Because of this it tries to provide those samples an environment that is as close to what would happen with a real app and to isolate those samples (Scenarios) from each other and the container.

Thus I'm NOT marking this bug as needed to be fixed for 0.90. It should be fixed for the 1.0 release.

Note @bdisp already fixed the most egregious related bug in Linux in #760 (https://github.com/migueldeicaza/gui.cs/pull/780) with a nice workaround that I think is fine for now.

[BDisp]

@tig can you answer a little question, please? When opening a scenario, the intention is to close the driver on the main page and start the driver in the scenario that opens. When the scenario is closed, the intention is to close the scenario driver and start the driver on the main page. Correct?

[tig]

@tig can you answer a little question, please? When opening a scenario, the intention is to close the driver on the main page and start the driver in the scenario that opens. When the scenario is closed, the intention is to close the scenario driver and start the driver on the main page. Correct?

Good question.

Recall the goals of UI Catalog (#368):

1. Be an easy to use showcase for Terminal.Gui concepts and features.
2. Provide sample code that illustrates how to properly implement said concepts & features.
3. Make it easy for contributors to add additional samples in a structured way.

I think this is how it should work (not saying it does now, but this was my intent):

1. When a Scenario runs, it should get a 'clean' Terminal.Gui environment as though it was a standalone app.
2. A Scenario that wants to, can call Application.Init and/or Application.Shutdown itself (by overriding Scenario.Init and Scenario.Shutdown as needed) but, by default the built-in Scenario scaffolding takes care of that.
3. When a Scenario exits, UI Catalog starts back up as though it were just started fresh. All resources used by the Scenario are cleaned up.

[tig]

Oh, one other thing that I had in mind when I first built it: I wanted to ensure that Scenarios could be invoked from unit tests. For this to work, they needed to be built such that they didn't depend on how UI Catalog invoked them.

Right now the unit tests that invoke Scenarios is pretty lame; it basically will only find egregious regressions (and IDisposable imbalances), but I have ideas on how just a little bit more work will make them even more valuable in finding regressions in specific swaths of the Terminal.gui API.

[BDisp]

@tig I tried to hack this like I did to Unix but couldn't solved like I did in Unix. In practice it's like not closing the Driver.

1. When a `Scenario` runs, it should get a 'clean' Terminal.Gui environment as though it was a standalone app.

A standalone app assumes that there is an exclusive window for that purpose, which is not the case. I think this is not always possible in the same window without avoiding these "strange" (normal) behaviors. Running on independent toplevels there is no problem but always restarting the Driverin the same window will always happen the same, I think. I still thought that there were no problems with WindowsDriverbut after all it also happens. But I would like to hear some discussion about this because I am really very curious.