Repository: gui-cs/Terminal.Gui

Issue #2008: Shift+key denied by text field as "control character" on remote systems
Created: 2022-09-13T20:00:49Z
Describe the bug
I cannot type any character with Shift modifier - no uppercase chars, no colon, no nothing. This does not happen on all systems.
To Reproduce
Steps to reproduce the behavior:

Pull the Terminal.GUI
Start the unmodified UICatalog project
Put the cursor in any text input field
Type Shift+a - nothing happens
Type a - a is typed

Expected behavior
I expect A to be typed when pressing Shift+a
Screenshots
It seems like the key is discarded as "control character". So the InsertText (kb) is never reached.

This does not happen on all systems, but on the one I have the debugger running ^^ Either the check should ignore the Shift modifier, or in an earlier step a conversion of Shift+a to uppercase A fails. Not sure how it is supposed to work.
(Note: removing the numlock modifier makes no difference.)
Here is the corresponding KeyEventRecord:

Desktop (please complete the following information):

OS: Windows 11, English UI language, German keyboard language, through RDP session
Version: relatively recent dev version: 3866e65

Additional context
Call stack:
>	Terminal.Gui.dll!Terminal.Gui.TextField.ProcessKey(Terminal.Gui.KeyEvent kb) Line 565	C#
 	Terminal.Gui.dll!Terminal.Gui.View.ProcessHotKey(Terminal.Gui.KeyEvent keyEvent) Line 1881	C#
 	Terminal.Gui.dll!Terminal.Gui.Application.ProcessKeyEvent(Terminal.Gui.KeyEvent ke) Line 431	C#
 	Terminal.Gui.dll!Terminal.Gui.WindowsDriver.ProcessInput(Terminal.Gui.WindowsConsole.InputRecord inputEvent) Line 859	C#
 	Terminal.Gui.dll!Terminal.Gui.WindowsDriver.PrepareToRun.AnonymousMethod__34_0(Terminal.Gui.WindowsConsole.InputRecord e) Line 759	C#
 	Terminal.Gui.dll!Terminal.Gui.WindowsMainLoop.Terminal.Gui.IMainLoopDriver.MainIteration() Line 1881	C#
 	Terminal.Gui.dll!Terminal.Gui.MainLoop.MainIteration() Line 295	C#
 	Terminal.Gui.dll!Terminal.Gui.Application.RunMainLoopIteration(ref Terminal.Gui.Application.RunState state, bool wait, ref bool firstIteration) Line 1014	C#
 	Terminal.Gui.dll!Terminal.Gui.Application.RunLoop(Terminal.Gui.Application.RunState state, bool wait) Line 996	C#
 	Terminal.Gui.dll!Terminal.Gui.Application.Run(Terminal.Gui.Toplevel view, System.Func<System.Exception, bool> errorHandler) Line 1172	C#
 	UICatalog.dll!UICatalog.Scenario.Run() Line 200	C#
 	UICatalog.dll!UICatalog.UICatalogApp.Main(string[] args) Line 111	C#

Duplicate issue #1617: Mouse button clicks by itself on certain Linux distro
Created: 2022-02-25T09:15:45Z
Running this simple application on Debian 11 or Ubuntu 21 happens that the mouse clicks by itself when it is moved on a menu item or a button. Instead the program run fine on Centos 7.
To Reproduce
Using Debian 11 fresh installation I tried on VirtualBox, VMware. On Ubuntu 21.10 using a phisical machine. In all cases the issue happens.
Both Self-contained and Framework-dependent package are affected.
Below the X configuration of the Debian machine running on VirtualBox:
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
Build Operating System: linux Debian
Current Operating System: Linux debian11 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-11-amd64 root=UUID=f1bba9df-a607-496e-931f-1f89956d6b31 ro quiet
Build Date: 16 December 2021  05:08:23PM
xorg-server 2:1.20.11-1+deb11u1 (https://www.debian.org/support) 
Current version of pixman: 0.40.0

The simple program
The program has been wrote using VS2022, framework .NET 6.0 (6.0.2), Terminal.Gui 1.4.0
The issue occurs also on more complex programs.
using Terminal.Gui;
using NStack;

Application.Init();
var top = Application.Top;

// Creates the top-level window to show
var win = new Window("MyApp")
{
	X = 0,
	Y = 1, // Leave one row for the toplevel menu

	// By using Dim.Fill(), it will automatically resize without manual intervention
	Width = Dim.Fill(),
	Height = Dim.Fill()
};

top.Add(win);

// Creates a menubar, the item "New" has a help menu.
var menu = new MenuBar(new MenuBarItem[] {
			new MenuBarItem ("_File", new MenuItem [] {
				new MenuItem ("_New", "Creates new file", null),
				new MenuItem ("_Close", "",null),
				new MenuItem ("_Quit", "", () => { if (Quit ()) top.Running = false; })
			}),
			new MenuBarItem ("_Edit", new MenuItem [] {
				new MenuItem ("_Copy", "", null),
				new MenuItem ("C_ut", "", null),
				new MenuItem ("_Paste", "", null)
			})
		});
top.Add(menu);

static bool Quit()
{
	var n = MessageBox.Query(50, 7, "Quit Demo", "Are you sure you want to quit this demo?", "Yes", "No");
	return n == 0;
}

//Application.UseSystemConsole = true;  // without influence ???
Application.Run();
Application.Shutdown();
Screenshots
As you can see, the mouse button clicks by itself, I never clicked the mouse button.

Thanks
Many thanks to the creators and maintainers of this useful piece of software.
I'm at your disposal for any information.

Closing comment (2022-09-17T13:41:40Z): Do the affected distros have this issue with other ncurses programs?

I've read those that use native library with c or python do not have this issue. But the Terminal.Gui uses the libc, libncurses.dylib, libncursesw.so.6" or libncursesw.so.5, by loading the methods through delegates. First, if Mono is present CursesDriver will obtain the address of the symbols from a dlopen object in the Mono.dlsym, otherwise will obtain in the return CoreCLR.dlsym if is NetCore. If none exist it will obtain in the Linux.dlsym. But if it's only a Terminal.Gui issue, why with the Ubuntu 20.04 distro the mouse move works and in the Debian 90 distro don't. The only reason I see is the Debian works differently. I already read that the Debian team doesn't compile the ncurses with all the necessary arguments. The gpm is needed to compile with mouse library.

Do you mean that ncurses is getting 'bad' code events from the OS? If so is it possible that there is just a change in the structure of those events (e.g. similar to #2008)? Maybe we are expecting some bit code and instead getting different ones?

On Debian 9.0 distro mouse move isn't caught at all and the others events doesn't match the one the Ubuntu receives. With the latest of installable versions of Ubuntu and Debian the ncurses always return always the same code event. So I already removed them. No it's having nothing with the #2008, which we receive correct code an we remap to the correct output values. The issue is we are receiving wrong code from the ncurses itself and there are no way do decode them because they are inconsistent.

Could you explain more about this? It sounds like you have an idea about what is going on? What would a 'database change' look like? and why does it not affect other apps e.g. htop (unless it does!)

I mean about the Termcap and Termunfo databases where can be configured soe keys, mouse and others information on how the terminal will respond to the commands. I don't know on what language htop is developed, but it's with native C the ncurses works well. I think they uses c library that has a correct of a compiled ncurses. But I'm not an expert on Linux. I only starting learning and understanding some ncurses methods with the Terminal.Gui. Perhaps some of the ncurses methods or structs may being badly created and binding in the Terminal.Gui, but in that case it also work badly with all the Linux versions.

I think if we can establish clear definitions of the input code formats that we are seeing in different OS versions it wouldn't be out of the question to build in some 'mapping' classes that translate to the common representation for that version?

I think we can't establish clear definitions of the input code formats that we are seeing in different OS versions without mapping them to a common representation that the Terminal.Gui cans process them.