Closed scaret closed 10 years ago
A) Performance; It isn't as fast as doing it on the server. Especially if you have more than one terminal open. This problem gets worse and worse as you increase browser (terminal screen) size.
B) Keeping the terminal in sync with the server (e.g. mode settings) becomes very complicated. Especially if you have a client disconnect and reconnect from a different browser. In order for that to work you basically need to have two terminal emulators: One on the server (to keep track of state) and one at the client. Why write two terminal emulators when you really only need one?
C) It limits what you can do to the terminal output (on the server) before sending it to the client. For example, if you want to capture an image/PDF and display it in the terminal you now have send the whole thing to the client before it can be processed (resized-to-fit).
D) You can't act upon terminal output at the server if the client is disconnected. For example, to page someone when a disconnected terminal has output (this has been in my "Plugin TODO" list for some time).
Having said all that, I have on many occasions experimented with offloading various aspects of terminal processing to the client. Everything from converting the screen/text renditions to HTML (which you are proposing) to full-blown terminal emulation.
If I were going to re-write Gate One from scratch today I'd definitely stick with server-side terminal emulation. JavaScript is really a terrible language for text/stream processing. Also, you run into all sorts of wacky limitations on a regular basis (like not being able to easily convert binary data into something usable in any straightforward way).
I've recorded 2 pieces of videos which you may get from:
http://scaret.in/u/f/scaret/IME.avi http://scaret.in/u/f/scaret/IME.mp3
http://scaret.in/u/f/scaret/bold.avi http://scaret.in/u/f/scaret/bold.mp3
I fail to combine the video and audio so you may open them at the same time.
&. thank you for your third comment. For ASCIIart we often copy the article/graph in \033[m from here to there. So maybe it's important that we can copy what we see in a terminal in \033[m format, even a simple one. I tried in the past JavaScript parser too which you can see in: http://scaret.in/dsw/14/WTerm_0.0.1/ in which you can see the source code the \033[m texts. and another in canvas with a little interaction with a textbox hidden behind ( but maybe not suitable for gateone ): http://bbs.sjtu.edu.cn/webterm/
Video #1: I believe this is a bug with Pinyin related to Google Chrome. Someone mentioned this in issue #188 (this, specifically: https://github.com/liftoff/GateOne/issues/188#issuecomment-12654949). If you use Firefox it should work fine. I have no idea what causes it but I'll see what I can do (I highly suspect it is a bug in Chrome itself).
Also, that crashing thing happens in your program (nykz.py) not Gate One. I took a screenshot of that specific moment when it crashed:
Looks like you're trying to use a variable named 'ss' which doesn't exist.
Video #2: This looks like a font rendering or encoding issue but I can't tell for sure. If you post a .golog (Gate One log capture) of a session where display a bunch of ASCII art like that I can figure it out. Please also post screenshots of what the ASCII art is supposed to look like. It may be a bug in the Ubuntu font itself.
If you can't post such a .golog publicly you can send it (or a link to it) to support@liftoffsoftware.com and I'll be able to get it (but not the general public).
I'm so sorry for mis-reporting the bug, which is all my mistake. I write nykz.py file to change encoding in vt100 from GBK to utf-8 because the gateone's setting "encoding" act not so well in both input and output of GBK,Chinese. ( forgive me that the blame is lack of testing where the exact problem is, and it seems that I did not do so well either ╮(╯_╰)╭ )
After your suggestion, I downloaded the latest version of FireFox and had a try. IME work very well in FireFox.
about font rendering, in my commonly used terminal, instead of BOLD, a \033[1;31mA represents a red A with rgb #F00 and a \033[0;31mA another dark red A with #F00. If we use a dark red A in a (dark) red background, it should not been. So maybe it's some difference about the theme of terminal.
Recently I'm hunting for a job so I'm a little busy. I think I can read manually vt100 format well to find the difference, but I need some time. I'll send the report to you some time later.
Since I haven't heard back on this issue I'm going to close it out. Hopefully everything is rendering OK.
Hi I'm using GateOne for a command-line BBS in chinese ( http://nykz.net:8889 )
GateOne is great. In recent years I've tried to create something like GateOne for the command-line bbs, including parsing the CT100 format charachers, socket-to-webosocket agent etc. GateOne has done more than my expectation.
As a Chinese user my questions are: