Add v2 version of fake driver

[tznind]

Fixes

• Fixes Replace FakeDriver with a v2fake or equivalent #3947

Requirements

Support creating Application and Driver level tests for v2.

• Driver level tests are those that use [SetupFakeDriver]
• Application level tests are those that use [AutoInitShutdown]

These tests need:

• To 'work'
• To be able to resize

Implementation

To enable this workflow we first need to pull all the Dependency Injection elements out into a shared provider factory. This lets us create classes but swap out Mocks and fakes as needed.

• Add IComponentFactory for creating system internal classes
  • Input
  • Output
  • WindowSize
  • etc

This lets us inject fakes.

• Todo 1

Test Assumption Changes

Test	Description
Can_Access_Cancel_Property_After_Run	Test seems to want main loop run to detect when you Run multiple views one after the other without first disposing the first. This is not a sensible activity and so part of v2.
Dialog_Opened_From_Another_Dialog	Run causes iteration and we no longer support adhoc calls to LayoutAndDraw so the indexes these check are now staggered

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]

Behold a green tick!

[BDisp]

What's wrong is the test sending a 'f' instead a 'F'. What's differentiate upper from lower case is the shift flag. So, you are doing the same wrong. Only replace the test with 'F'.

[BDisp]

What's wrong is the test sending a 'f' instead a 'F'. What's differentiate upper from lower case is the shift flag. So, you are doing the same wrong. Only replace the test with 'F'.

Sorry, I was wrong by said to replace 'f' to 'F'. We need to understand what is going on here. Only WindowsConsole.InputRecord get the correct key and modifiers. With ConsoleKeyInfo in Windows with VTS enabled or in Unix, the key and modifiers flags aren't available by the input driver. They must be manipulate to return the correct key and modifiers flags, based in cap case or escape sequence. See the images bellow using with the NetDriver.

'f' was pressed and Key is None, KeyChar is 'f' and Modifiers is None:

After internally managed and before sending to Application, Key is F, KeyChar is 'f' and Modifiers is None:

'F' was pressed and Key is None, KeyChar is 'F' and Modifiers is None:

After internally managed and before sending to Application, Key is F, KeyChar is 'F' and Modifiers is Shift:

See that the correct Key (of ConsoleKeyInfo) and Modifiers is sent to the MapKey method. As you can see the map variable has always the upper case if it belong to the A-Z range. In the Key class the AsRune property return the correct Rune based on the Shift flag.

But I agree that when we are sending a set of string, like "Bob.csv" the output must also to be the same as "Bob.csv". What is need is to send the correct ConsoleKeyInfo properties before call the MapKey method.

[BDisp]

The PR tznind#184 leverage the hard coded EscSeqUtils.MapKey and EscSeqUtils.MapConsoleKeyInfo methods, which has already all or almost all the key combinations.

[tznind]

I think iteration is running on more than 1 thread.

I am exploring in my iteration-zero branch. Where i set the post iteration delay to zero.

We can see for any fluent test it can crash in many ways in layout and in draw.

I need to add thread id tracking to main loop to see if it is ever hit from more than 1 thread.

Critically i can trigger the error just running a single test over and over so its not knock on effects of multiple tests at once

See: #4225

I will start by detecting any time iteration is on other thread id, but then also look at layout or draw.

If any of them is running on non main UI thread it is bad.

[BDisp]

One way I used to resolve the fluent unit tests, is in the PR #4210.
Other issue I found with ApplicationV2 unit tests I resolve with the PR #4223, which only was failing on Ubuntu and macOS with the error "Input loop exited during startup instead of entering read loop properly (i.e. and blocking)". The problem here is the _input variable being still null when try to build the v2 driver facade.
You can see that all unit tests are passing but it's important that all main loop iterations are running in the UIThread indeed.

[tig]

@tznind please fix conficts and I'll review.

[tznind]

This work stands alone and is good but will be further extended in #4225 where I deal with all the secret multi threading issues it turns out there are in the fluent test.

Basically any time you do anything on the 'test' thread then you might trip over what is going on in the 'run thread' that the fluent sets up.

I fix that by removing frame limiter on the main loop so it iterates constantly. That is still WIP though.

[tig]

@tznind Please resovle conflicts.

[tznind]

This is subset of iteration-zero #4225 so will close for now as that is better PR to do and has no conflicts