firessh

[Mime]

Hey everybody!
So exciting to see that there's actually a substantial community
around this :)

Wanted to toss my project into the mix as well, FireSSH, a working SSH
terminal all written in Javascript:
https://addons.mozilla.org/en-US/firefox/addon/firessh/
more info here: http://firessh.mozdev.org/developers.html
CLI code being here: http://www.mozdev.org/source/browse/firessh/src/content/js/etc/cli.js?rev=1.20

The CLI and underlying SSH code were Python libraries that I
translated and modified into Javascript. It currently only works in
Firefox (b/c Firefox is the only browser that supports making sockets
- no, not websockets)

I'm looking forward to hearing about the developments people will be
making!
Cheers!
Mime

[Mime Čuvalo]

2011/5/25 Mime <mimec...@gmail.com>

[Mime Čuvalo]

(Doh, sorry for the blank previous email)

I wanted to hear people's thoughts on their implementations of the CLI.  I've seen a lot of examples using Canvas and that's cool and fast but then you don't get any history :-/

The way I'm implementing it is it keeps a complete history so that you can scroll back.  Maybe, as some of you might have found when working on this, it's tricky to do this b/c your performance will quickly go down as the number of DOM nodes increases and increases.  I've worked around this by only drawing the nodes that are visible at the current time (only works b/c lines are a fixed height) - the history is kept in an array and painted on demand depending on where you are scrolled at.  I think Google Spreadsheets works the same way.  

Anyway, so that's a good way of working around it and allows you to copy/paste and such - but then you can't just hit Ctrl-A and select all b/c the text won't literally be all there - some will be in memory and some will actually be on screen.

Thoughts on working around this limitation?

Mime

2011/5/25 Mime Čuvalo <mimec...@gmail.com>

[Joe Walker]

Editors like Ace/Bespin etc track what text is selected and, when the user hits copy, they quickly stuff the text to be copied into an off-screen text area, select the text, give it focus, and then let the copy action proceed.

A word of warning about your chosen route - Without a large amount of work, your cli won't be accessible, and without a vast amount of work your cli won't be able to properly display all Unicode chars. If you don't care about either, feel free to carry on, but I thought it only fair to warm you!

Joe.

[Mime Čuvalo]

Editors like Ace/Bespin etc track what text is selected and, when the user hits copy, they quickly stuff the text to be copied into an off-screen text area, select the text, give it focus, and then let the copy action proceed.

Hm, I'll have to look more closely at Bespin to see how they do it.  The problem with mine so far is that the user cannot select more than a screenful of text right now - the actual copying/pasting works fine (if you try the extension out you can Copy/Paste with Ctrl-Shift-C and Ctrl-Shift-V (Cmd on Mac).  But maybe what I can do is, if I detect the user is selecting something I can put the cli into a different mode and get rid of the efficient history hiding temporarily...

A word of warning about your chosen route - Without a large amount of work, your cli won't be accessible, and without a vast amount of work your cli won't be able to properly display all Unicode chars. If you don't care about either, feel free to carry on, but I thought it only fair to warm you!

Can you be more specific on what you mean?  Why won't it be accessible?  I would think the Canvas cli's would be less accessible - mine is just HTML...

On the Unicode topic, Boris Zbarsky hinted that to me as well but it seems to be working fine for me so far - I allocate 2 fixed-width character spaces for things like CJK characters.  What am I missing?  Would the height be a problem or would there be something wider than 2 character spaces?

Thanks for your feedback!

Mime

[Steven Wittens]

It all depends on how you are doing the keyboard input. If you simply wait for keydown and charcode events, you will not be able to support complicated input methods.

For example, in Japanese, the user first types out characters phonetically, then hits spacebar to turn their line into Chinese symbols, even allowing for interactive editing of the substitutions in little popups.

Similarly, people who require assistive technology (e.g. screen readers for the blind) rely on software to use standard UI components like input fields which can be predictably scripted.

For TermKit, I realized I did not want to be subject to this limitation, so instead, it actually has a virtual "caret" object that places a chromeless text-field inside the command line. As you type and move around, it moves itself transparently. It tries to maintain its position as long as possible, to allow for things like Japanese input to work. Otherwise, any time input field is changed from JS, the native internal state is destroyed.

Steven 

[Mime Čuvalo]

Thanks for the feedback, Steven!  I'll take it into account in the next version.  What I do now is just wait for keydown events, yes.  But, I think it should be straightforward enough to work on a version that has a chromeless text-field as you've said that is always focused, if that will help accessibility.

Mime

2011/5/28 Steven Wittens <steven....@gmail.com>

[Mime Čuvalo]

I released a new version last week btw that addresses the accessibility and CJK issues.  Thanks again for your suggestions, Steven!

Mime