Hope you're ok with me updating the title & first post...

Hope you're ok with me updating the title & first post...

No problem! Always appreciate a clear naming

Now we have fledgling support for

• Keyboard
• Mouse
• Screen size

Net (i.e. native dotnet) and Windows (i.e win 32 api) are the two implementations - I assume we can drop curses and don't need to port?

Ok most stuff works and cpu sits at about 0%

Now needs loads of tests, and to round out a few implementations like all the various key translations, double click etc

I think I will add ILogger support so we can see things like ignored ansi codes, record where/if there is slowdown etc. That will be a dependency for ILogger but actual implementation is down to user e.g. NLog / Serilog etc

Ok I need to work a bit on my understanding of how to integrate Application.Run.

The users main entry thread for Program.cs is going to call Application.Init and then Run.

That method will 'block' but it also is the thread that processes Click events e.g. if the user wants to Run another View.

Currently I have 2 main threads

• Input Loop
• Everything else loop (output, timers, layout, draw etc)

But I'm realizing now that that is an issue for integrating with Run. Because Run has to appear to block but still process user event code (e.g. click) and be able to put another Run call onto the csharp call stack.

Any insight into my understanding of things or suggestions would be welcome - especially clarifications on how it is currently working as its a bit opaque.

This is my vision for how v2 will work. At the moment Run just blocks and loops, looking at the state of the coordinator. But that does not work well for starting a nested Run or exiting a nested Run back into the parent Run.

V2 vision of the 3 threads that will make up any Terminal.Gui program

Ok I have got it! Looking at the existing codebase the 'Iterate/Output' loop that I have on its own thread is actually called repeatedly within Run. This means that the entry thread the application has in their program is the one that the UI code is all running on.

That makes sense and is 1 less thread so I'm up for it. Now you can open and close as many scenarios as you want.

So it is more like this: