SSH Terminal Emulator: Release 4 is live!

Release 4 is in the store now! Be sure to update through the Store app on your Windows 8/RT device! As a reminder, here are the update notes:

  • Increased speed of terminal, again.
  • Increased VT100/ANSI compatibility, again.
  • Terminals are now resizable.
  • Added AppBar commands to: hide/show server list, reset terminal size, and increase/decrease font size.
  • Added 16pt font to available font sizes.
  • Fixed an issue with keyboard-interactive authentication.
  • Fixed an issue with vim/pico/nano scrolling.
  • Fixed an issue with vttest compatibility.
  • Fixed an issue with .key files not appear in the file picker.
  • Fixed an issue where intranet servers could not be connected.
  • Better landscape and portrait layouts.
Release 4 greatly increases the usability of the terminal to the point that it should be much more usable in a production environment.

Release 5, which is in progress, will include ANSI emulation which should fix the lack of syntax highlighting and cursor issues in programs like vim, pico, and emacs.

Once again, I truly appreciate all the feedback I’ve gotten for this App. Without your kind support and support requests, it would not be where it is today.

14 Responses to “SSH Terminal Emulator: Release 4 is live!”

  1. mitch

    Great work! Any plans to have a fullscreen mode? Stretching the terminal window and hiding the server list is close, but a dedicated mode would be really nice.

    Keep up the great work!

    Reply
    • admin

      Yep! I’m trying to take this stuff one step at a time. I could be totally wrong, but I think people would rather have frequent updates that incrementally increase usability rather than having to wait weeks and weeks for all possible features to be added. Expect fullscreen mode very soon!

      Reply
      • mitch

        I think you’re right regarding the release schedule, perhaps with the exception of the poor guys at MS who have to review all of them :-) I’ve got to admit, I am pretty impressed with how quickly they have been turning these out.

        Reply
    • admin

      Hi there! There is a known issue with vim’s arrow keys not working with vt100 emulated terminals. Try this to see if it will help make the cursor keys work:
      http://viget.com/extend/cursor-keys-in-vim-you-macing-me-crazy

      Fullscreen mode will likely be in the next release. In this release, you can hide the server list and resize the terminal to take up most of the screen. Hide the server list by bringing up the appbar with a right click, or by touch-dragging from the bottom of the screen, and click “Hide List.”

      Let me know if there are any other issues!

      Reply
  2. mitch

    A couple of things that I think warrant mention (though you might already be looking into the root of these problems) are:

    – behavior of the Home and End keys to go to the beginning and end of lines
    – key sequences for controlling screen. Simple example, Ctrl-a, d to detach from a screen. I think taking a targeted look at screen might be a really good idea, since a lot of people that work extensively in the terminal use screen a LOT.

    Just want to stress that I am not trying to breathe down your neck, I’m just trying to get these on your radar if they aren’t already on there. Thanks for all your great work!

    Reply
    • admin

      Hey mitch. I’m currently testing on what will become Release 5 with screen, and I’ve gotten all the basic stuff to work including the commands for splitting a screen. Could you describe more specifically what the issues you’re having with screen might be?

      Reply
      • mitch

        I was having issues getting it to respond to any commands, but having tried it again, it appears to be working just fine. I think it might have been because i was trying to detach from a rather active terminal (it was running an update using the arch linux package manager), and the terminal just wasn’t responding at all. I did take a look at task manager while all this was happening, and it looked like the SSH app was completely pegging the core that it was running on, which doesn’t seem like it should have to be the case. Maybe it would be a good idea to profile it with a really active terminal session? Also, as a result of the really active terminal, scrolling was sluggish to the point that it was borderline unresponsive (though fixing the CPU load issue will probably fix this).

        One more suggestion that I have is to change the cursor style when the terminal window does not have focus, or at least to have some indication for when the terminal does or does not have focus. I mention this because when I connect to a host and resize the terminal window, the terminal loses focus and it doesn’t respond to keystrokes. It took me a while thinking that it was some sort of more serious bug before i realized that the terminal just didn’t have focus.

        Reply
        • admin

          Thanks for the feedback! I think I understand what’s going on, and I’m going to work on the high CPU usage during especially active terminal sessions today.

          Also, in what will become Release 5, I’ve put a gray 1px border around the terminal image when it has focus, and no border when it does not.

          Reply
  3. mitch

    Another feature to think about, though I can only imagine that it would take some doing to get working: SSH tunneling. Sometimes I need to access hosts that need be accessed through a login portal. Usually, using ssh on a linux machine, I set up an ssh config file to set up a tunnel when I connect to the login portal, which allows me to login to other hosts behind the tunnel without having to manually ssh from the portal to the end host. Any chance that you would be willing to incorporate something like this?

    Reply
    • admin

      It’s a possibility, but it’s gonna take some time. That seems to me like a pretty advanced feature to implement and test. I can’t really commit to doing it, but I’ll look into it.

      Reply
      • mitch

        That’s what I expected to hear. Just wanted to get it on your radar, distant though it may be. Thanks!

        Reply
  4. mitch

    minor goofy bug, that should be easy to reproduce: start typing a command into the terminal prompt (like ‘cd’), type space, then hit caps-lock. in zsh, a space appears between the ‘c’ and ‘d’. In bash, the order of the ‘c’ and ‘d’ switches. this particular instance of the bug is really obscure and not important, but it may just be the tip of the iceberg for a larger problem.

    Reply
    • admin

      Got it. Was directly translating some VirtualKeys to bytes and transmitting them to the server. Caps lock was one of those keys, and it’s now been excluded. Release 5 will contain a fix for this.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

     

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>