Fixes #3692++ - Rearchitects drivers

[tznind]

This is a super set of #3791 and exists to see diff and direction of v2 drivers as discussed in #3821

Fixes

• Fixes Comprehensive Logging and Metrics (Opt in) #3892
• Fixes Refactoring, cleanup, and abstraction for ConsoleDrivers #3692
• Fixes Refactor ConsoleDriver to minimize duplicated code in all drivers #2319
• Fixes Harden EscSeqUtils  #2803
• Fixes Refactor ConsoleDrivers to support ANSI sequences natively (e.g. Virtual Terminal Sequences on Windows) #2610
• Might fix Mouse API makes it way too hard to track button pressed #3312
• Might fix Mouse doubleclick stops continous pressed events. #3404
• Might fix Not always getting Button1Clicked events on Netdriver or CursesDriver #3374

Progress

• Keyboard
  • Exit
  • Typing
  • Backspace
• Views
  • Run/RequestStop
  • MenuBar
• Mouse (see MouseInterpreter)
  • Button 1 click
  • Multi clicks
  • All buttons
  • Scroll wheel
• Other
  • Clipboard

Proposed Changes/Todos

Splits drivers up into logical components, simplifies and centralizes shared code patterns.

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

[tig]

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

[tznind]

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?

[tznind]

Once this is merged and well tested we can have an epic deleting session to remove the old drivers - if we want to that is.

It would mean finally getting rid of the old curses dependency too which would be nice!

[tznind]

@BDisp can you see if you can see why right click context menus are not popping? I guess something about the mouse event(s) in v1 vs v2?

ok looks like Released+Clicked flags together is bad. TG code wants 2 seperate events I think.

Got it, is just about order of events

[BDisp]

ok looks like Released+Clicked flags together is bad. TG code wants 2 seperate events I think.

Got it, is just about order of events

Glad you found the solution but that's really the cause of the bad behavior that was causing the right click wasn't working. Of course that each escape sequence must raise separate events, for them to work as expected. Good work and Happy New Year.

[tznind]

Of course that each escape sequence must raise separate events, for them to work as expected. Good work and Happy New Year.

Happy new year!

There is actually no escape sequence for click so you must in fact create one manually in interpreter:

Input:

�[<0;3;3m
�[<35;3;3m
�[<0;4;4M

We see mouse is moved with no button
Mouse is down (button 35)
Mouse is released (button is back to 0 - also we have 'M' instead of 'm;)

This must currently be translated into 4 events for Terminal.Gui right click menu to work properly:

ReportMousePosition
Button1Pressed
Button1Released
Button1Clicked

So it is not a 1 to 1 mapping between escape codes and events, click is a 'supplemental' event that we inject into the event stream.

Combining flags e.g. Released+Click as one event does not work with current codebase (which is the original thing I was doing).

[tznind]

@BDisp EscSeqUtils.MapKey does not handle backspace. Here is the ConsoleKeyInfo that comes in direct from console when reading with console read:

Apparently:

When working with ConsoleKeyInfo in a console application (e.g., in .NET or similar environments), the behavior you're describing is common. Here's why:
Backspace and 127 (0x7F) Behavior

Historically, many systems followed terminal standards where the Backspace key sent the DELETE (0x7F) control character instead of the Backspace (0x08) character.

When you press the Backspace key, the console might interpret it as sending the 127 (0x7F) code instead of 0x08 (Backspace).

This happens because of differences in how the terminal emulator or console environment maps keyboard keys to control codes.

How is this handled in NetDriver? is MapKey the best place to put this new logic?

[BDisp]

The DEL (127) is handled on the EscSeqUtils.MapConsoleKeyInfo method.

[BDisp]

This code fixes the right button click to popup the context menu.

[tznind]

The DEL (127) is handled on the EscSeqUtils.MapConsoleKeyInfo method.

Great, I have added in call to this function in the new architecture, see aa8bdd7

This code fixes the right button click to popup the context menu.

Right click works for v2 net but not v2 win, I will have to explore your suggestion further when I have some time.

[tznind]

Windows right click working thanks! 6c55e11

[BDisp]

Great, I have added in call to this function in the new architecture, see aa8bdd7

Nice.

Right click works for v2 net but not v2 win, I will have to explore your suggestion further when I have some time.

Works with NetDriver because it rely in the EscSeqUtils API and WindowsDriver don't, and it's needed to point the right way how to handle it. Don't forget to deal with the warning.