You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I over-engineered Scenario and tried to be both too helpful to devs and too cute. My intent was to make it super easy to create new scenarios. I thought it would be neat if Scenario developers only had to write a Setup override and the "default" logic in Init and Run would do magic for them. I also had UICatalog call Application.Shutdown when the Scenario exited instead of forcing Scenario authors to do this themselves.
This was a bad idea for these reasons:
New developers looking at scenarios as examples don't see what ones supposed to do to setup/teardown a Terminal.Gui app. They don't see the proper way: Call Init, and ensure it's bracketed by a Shutdown, Call Run and make sure the Toplevel used gets disposed.
It led to un-needed complexity in 4 overrides: Init, Setup, Run, and RequestStop. This is confusing to devs and a survey of the existing scenarios shows this confusion.
It makes devs think that Application.Top can't be the actuall main view for the scenario, because Init, by default creates Win and adds it to Top.
My proposal:
Simplify Scenario to have only ONE virtual metods: Main. Developers should treat this just like the standard C# console app int Main (string [] args) method.
Change Init to NOT reset ConfigurationManager. This way whatever was configured in UI Catalog will naturally just pass onto the Scenario.
Change all Scenarios to merge their Init, Setup, and Run overrides into Main.
The Generic Scenario.Main will look like this:
publicoverridevoidMain(){// Init
Application.Init();// Setup - Create a top-level application window and configure it.WindowappWindow=new(){Title=$"{Application.QuitKey} to Quit - Scenario: {GetName ()}",};varbutton=new Button {X= Pos.Center(),Y= Pos.Center(),Text="Press me!"};
button.Accept +=(s,e)=> MessageBox.ErrorQuery("Error","You pressed the button!","Ok");
appWindow.Add(button);// Run - Start the application.
Application.Run(appWindow);
appWindow.Dispose();// Shutdown - Calling Application.Shutdown is required.
Application.Shutdown();}
The text was updated successfully, but these errors were encountered:
tig
changed the title
Here's my thinking on Scenario. I'll either create a new issue/PR to address this or do it here, depending...Scenario is complex, confusing, and causes errors
Mar 25, 2024
I added [ObsoleteAttribute ("This method is obsolete and will be removed in v2. Use Main instead.", false)] to the Scenario fields that will be deleted. Once those are gone from build-spew this Issue can be closed.
I over-engineered
Scenario
and tried to be both too helpful to devs and too cute. My intent was to make it super easy to create new scenarios. I thought it would be neat if Scenario developers only had to write aSetup
override and the "default" logic inInit
andRun
would do magic for them. I also had UICatalog callApplication.Shutdown
when the Scenario exited instead of forcing Scenario authors to do this themselves.This was a bad idea for these reasons:
Init
, and ensure it's bracketed by aShutdown
, CallRun
and make sure theToplevel
used gets disposed.Init
,Setup
,Run
, andRequestStop
. This is confusing to devs and a survey of the existing scenarios shows this confusion.Application.Top
can't be the actuall main view for the scenario, becauseInit
, by default createsWin
and adds it toTop
.My proposal:
Scenario
to have only ONE virtual metods:Main
. Developers should treat this just like the standard C# console appint Main (string [] args)
method.Init
to NOT resetConfigurationManager
. This way whatever was configured in UI Catalog will naturally just pass onto the Scenario.Init
,Setup
, andRun
overrides intoMain
.The Generic
Scenario.Main
will look like this:Originally posted by @tig in #3339 (comment)
The text was updated successfully, but these errors were encountered: