Enhancements

[USLTD]

This discussion is dedicated for ideas and implementations to improve PyTermGUI

[USLTD]

This is just poll to see which is option is preferred. It doesn't mean that developer (@bczsalba) will definitely do this.

Should we change Windows's input handlers to implementation using Win APIs?

[USLTD]

+ 1

@@ UltraStudioLTD @@

[bczsalba]

With my limited ability to code & test on Windows and not a huge amount of time I'm not sure I can do it at the moment. If someone is interested and would be open to doing some of the work it would be hugely appreciated!

[USLTD]

I will try 😁

[bczsalba]

I added it as a test, but don't agree with any of the "issues" it finds. The repo uses a Pylint GitHub action already, and that reports 10.0, which I trust more.

[bczsalba]

And it seems the folks writing Pylint also agree with me here, as while this was an old behavior it has since been removed. See pylint-dev/pylint#1405 and pylint-dev/pylint#2684.

[USLTD]

Those are minor issues. What about security and performance issues? Like about using subprocess? And using + to join strings (which is slower than .format(something) which is slower than f-strings. I don't remember about "%#" % something but it is also slower than f-strings)

[USLTD]

Alright.

[USLTD]

@bczsalba,
Did you considered my advice? About changing PyTermGUI structure and dividing it with Unix and Windows (using WinAPIs) specific drivers?
Reason is that I reviewed your code and it is slowly becoming spaghetti code (type of code that even if it works it becomes almost/totally impossible to maintain). Also please switch every string additions ("string" + "string") to f-strings (f"string") because this will increase speed of string processing

[bczsalba]

Did you considered my advice? About changing PyTermGUI structure and dividing it with Unix and Windows (using WinAPIs) specific drivers?

I did, and decided that at the moment the issue is not of priority. Especially with the recent ANSI parsing support provided by Windows itself, we probably won't need to do it.

Reason is that I reviewed your code and it is slowly becoming spaghetti code

Could you point me to examples of this? IMO the project has become much better organized than it used to be.

Also please switch every string additions ("string" + "string") to f-strings (f"string") because this will increase speed of string processing

Again, please provide examples.

[USLTD]

Reason is that I reviewed your code and it is slowly becoming spaghetti code

About this, looks like I was reviewing old commit 😅

Also please switch every string additions ("string" + "string") to f-strings (f"string") because this will increase speed of string processing

About examples I just tested it in Python environment few days ago but I currently don't have any means to do it (I am on phone currently and my computer is almost dead) so I will send you SO answer:
https://stackoverflow.com/a/38722192/10944855

Result was same as in my case but Idk about later versions

[bczsalba]

https://stackoverflow.com/a/38722192/10944855

I know about this, and was asking about examples in my code.

[USLTD]

I did, and decided that at the moment the issue is not of priority. Especially with the recent ANSI parsing support provided by Windows itself, we probably won't need to do it.

Issue is not ANSI parsing but better handling of events (window resize, mouse, key press and other). Also even if Windows Terminal (not Windows) provides ANSI sequences parsing please remember that not everyone uses Windows 10 or Windows 11 so it's better to add fallback system for ANSI sequences handling (like what colorama did

[bczsalba]

Issue is not ANSI parsing but better handling of events (window resize, mouse, key press and other). Also even if Windows Terminal (not Windows) provides ANSI sequences parsing please remember that not everyone uses Windows 10 or Windows 11 so it's better to add fallback system for ANSI sequences handling (like what colorama did

colorama doesn't handle window resizing beyond getting the current dimensions when doing full screen prints. This is not done using an event anyways.

It also doesn't read input, mouse or other things. Its only purpose is to color text, which it does very well. Even rich recently stopped using it. There is value in supporting legacy windows systems, but as I said it's not of high priority.

In one of the upcoming releases the terminal-interfacing part of the module will be abstracted into its own submodule, so it will be open to be added in.

In terms of our support, getting input characters works perfectly on all Windows systems I've tried, and should be suitable all the way back to the XP days. Mouse input doesn't seem to do much, but once again the upcoming changes to the structure of the ansi submodule will allow support to fit in.

[USLTD]

colorama doesn't handle window resizing beyond getting the current dimensions when doing full screen prints. This is not done using an event anyways.

It also doesn't read input, mouse or other things. Its only purpose is to color text, which it does very well. Even rich recently stopped using it. There is value in supporting legacy windows systems, but as I said it's not of high priority.

I never said that. I only said that colorama would fallback to WinAPIs incase terminal doesn't support ANSI sequences or Virtual Terminal Mode.