Adds IApplication

[tznind]

Major work in progress

Architecture is:

• Keep existing public static convention e.g. Application.Init
• Add a new singleton class ApplicationImpl
• Static method forwards to ApplicationImpl as IApplication singleton

Public method remains the same:

public static partial class Application
{
[...]
    public static bool Initialized
    {
        get => ApplicationImpl.Instance.Initialized;
        set => ApplicationImpl.Instance.Initialized = value;
    }
[...]
}

Here is the singleton

internal class ApplicationImpl : IApplication
{
    // Private static readonly Lazy instance of Application
    private static readonly Lazy<IApplication> lazyInstance =
        new Lazy<IApplication> (() => new ApplicationImpl ());

    // Public static property to access the instance
    public static IApplication Instance => lazyInstance.Value;

    public bool Initialized { get; set; }

Here is the burgeoning class diagram

Fixes

• Fixes Add IApplication #3863

Proposed Changes/Todos

• Todo 1

Pull Request checklist:

• I've named my PR in the form of "Fixes #issue. Terse description."
• My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

[tznind]

@tig / @BDisp / @dodexahedron please can you confirm you are happy with this approach (static accessors) - before I go too far down this rabbithole

[tznind]

RunState seems to only have a single member which is Toplevel which already exists on Application - can we get rid of this class and its events?

[BDisp]

I really don't know how this will be ended. So I think the best is you continuous showing your point of view and waiting how it fit.

[tig]

RunState seems to only have a single member which is Toplevel which already exists on Application - can we get rid of this class and its events?

We support multiple calls to app.Run. Each has a runstate and Toplevel.

Application.Top points to the runstate.toplevel that is "top" (getting input).

So no.

[tig]

@tig / @BDisp / @dodexahedron please can you confirm you are happy with this approach (static accessors) - before I go too far down this rabbithole

I am good with it!

[tig]

Please read my comments on the issue about toplevel where I justify nuking it as a concept and replacing it with separate concerns for "runnable" (IRunnable) and "overlapped".

I've completed the overlapped work. But haven't gotten to IRunnable. I have not fully thought out IRubbable and view it just as a concept at this point. If, as you add IApplication see how it could be implemented id hug you.

[tznind]

I have read your post on IRunnable

I think there's two concepts going on in Application

• Global scope 'stuff' that largely goes unchanged in process lifecycle (Global keysbindings, events etc)
• State management (boot strap driver/loop, the modal View stack etc)

I think only the state stuff needs refactoring. The rest can stay.

I think that any view should be runnable. Multiple view windows running at once should also just be handled with a single root view e.g. a DesktopView or even, just View base class with multiple draggable window child views

I will see how I can progress down this direction

[tznind]

Going to close this in favour of #3878

There is too much going on in Application to tackle it all at once, I will continue with the 'first principles' approach by just porting Run/Init/Shutdown to IApplication and seeing how far that goes.