Please ship WindowsTerminal along with rest of the binary classes

[unix-junkie]

Currently, the version of the library available from the Maven Central lacks WindowsTerminal class.

Please ship WindowsTerminal plus native code for win32/win64 along with the rest of the library.

Additionally, lanterna can have an optional dependency on the native-platform library which already ships the native primitives for all mainstream platforms. WindowsTerminal could be re-implemented via those primitives -- see WindowsConsoleFunctions.java.

[mabe02]

Unfortunately, the native bindings library was more of an experiment and was never 100% functional. As long as it's experimental, I don't think it would be a good idea to distribute it to Maven central.

[avl42]

if people on windows OS would test & PR this module into shape, then things might be different... mabe02 <notifications@github.com> schrieb am So., 18. Aug. 2019, 15:22:

…

Unfortunately, the native bindings library was more of an experiment and was never 100% functional. As long as it's experimental, I don't think it would be a good idea to distribute it to Maven central. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#422?email_source=notifications&email_token=ABIDBMWT3AG3JNNYRQW5FDTQFFEHZA5CNFSM4HWSYNUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4Q76AY#issuecomment-522321667>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABIDBMUQ4PHCLUOULYLI2IDQFFEHZANCNFSM4HWSYNUA> .

[rednoah]

@mabe02 I had a crack at it over the weekend and got it working, after many many hours of debugging.

Since lanterna is already doing Class.forName(...) this can be added as 3rd party library, but you're welcome to merge it into your code base here:
https://github.com/rednoah/lanterna-wincon

They key was figuring out that on Windows the InputStream.available() method of System.in is basically lying, and so our input loop breaks in strange unexpected ways when it randomly starts blocking in code paths that shouldn't be blocking, or never reading anything when there is something to read.

[mabe02]

Interesting! Did you write this from scratch or did you base it off the experimental work we've done in native-integration?

[rednoah]

I started out with your code base to debug the issue. WindowsTerminal itself remains relatively unchanged. The new code is rewriting things to use ReadConsoleInput and GetNumberOfConsoleInputEvents instead of System.in.read() and System.in.available() (which just doesn't work) and to get resize events. Using WriteConsole for output helped with screen flickering and allows for printing Emoji.

[rednoah]

jna-platform now includes the added native bindings as well:
java-native-access/jna@b22f85a

[mabe02]

What would be really nice is if we auto-detect if JNA is available at runtime and only then load the WindowsTerminal class. Not sure if we can use the "optional" dependency feature in Maven for this (on jna) to make it compile at build time. Just want to avoid Lanterna pulling in JNA as a transient dependency when it's really only used in special case.

[rednoah]

I'd make jna-platform a compile time dependency, and then just do catch LinkageError in the createWindowsConsole factory method to account for jna-platform missing from the class path, as well as jnidispatch.dll not working.

I'd probably also change the factory to default to using the Swing Terminal Emulator, even if we have a console window already, instead of the most-likely non-functional Cygwin implementation, and get rid of that use javaw instead error message.

[mabe02]

I've read up on the optional tag and that seems like what we want, as it won't be included as a transitive dependency. Is you code you linked to above in a state where you think we can merge it?

[rednoah]

I've done some testing with FileDialog (the most complex built-in component I could find) and that works perfectly as far as I can tell. Though I'm not using this in "production" yet. Testing is also limited to the latest Windows 10, so it may or may not work well on Windows 7, if that's a concern.

So setting setPreferTerminalEmulator(true) on Windows might be a good idea regardless.

[jrb0001]

You will also need to add a requires static com.sun.jna; to module-info.java and you will need to catch the ClassNotFoundException in case the class isn't available on the classpath or module path (or it is on the classpath while lanterna is on the module path). Also keep in mind that JNA is not compatible with jlink because it is an automatic module so it will always be missing there.

[mabe02]

Ok, here what we'll do. I'll branch of master into release/3.1 and we'll merge this jna code for a future 3.2 release on master.

[mabe02]

@jrb0001 will the requires static com.sun.jna; work even if jna isn't on the classpath? I have really 0 experience with the Java module system.

[jrb0001]

@mabe02 Yes, I tested that with the java.desktop dependency. If the module is on the module path, then it is available. And if not, then it simply doesn't exist. If lanterna is on the module path and JNA on the classpath then the latter applies.

[mabe02]

There, that should do it! I've tested and it seems to work fine.

[reibitto]

Just for confirmation, this feature got merged but there is no published artifact that includes it (including the beta)?

If it's still too experimental at this moment for a release of some kind, I can try building from source and report my findings (though Scala + SBT makes source dependencies kind of tricky... so it's not terribly ideal, but I'll manage).

I'm not sure if anybody is using the Windows terminal yet, but considering it's pretty important for one of my projects I can try helping with any potential bug fixes and testing.

[mabe02]

I thought we had released a beta with this...? Let me check...

[mabe02]

Ah, because I put this on master. But I can make an alpha release of 3.2 for you.

[reibitto]

Thanks. That would be great. 👍

[mabe02]

Having some issues with my gpg key not working with Sonatype, but should be available in a day or two

[mabe02]

Ok, finally. 3.2.0-alpha1 released to Sonatype, should be available shortly on Maven central.

[reibitto]

Thanks! I tried this in my project and it works. All I had to really do is add the JNA dependency: reibitto/command-center#85

I haven't run into any bugs or anything like that so far.