11 Jun, 2011, donky wrote in the 1st comment:
Votes: 0
Was trawling through the dregs of github for html5 javascript/websocket clients and came across jsterm. It uses canvas and handles telnet negotiation and escape sequences.

I didn't find any posts about this already using the search page.

Pros:
  • Works as advertised, as can be seen on the first linked page.
  • Is liberally licensed with just the provision to include the license and its existing copyright information.
  • Code is very straightforward and readable.

  • Cons:
  • Not user friendly in that it does not support cut and paste due to the use of canvas.

  • Possible ideas are a group project to extend it to serve as a general plug and play MUD client solution. Perhaps chipping in a variety of lightweight server-side libraries that can be attached easily to MUD frameworks to make use of it.
    11 Jun, 2011, Idealiad wrote in the 2nd comment:
    Votes: 0
    donky said:
    Cons: Not user friendly in that it does not support cut and paste due to the use of canvas.


    I think this showed up on a TMC thread a while back as well. Is there no way to get c&p with canvas? I guess it's not a common use case to copy directly from output on a mud anyway if you have a convenient logging facility.
    11 Jun, 2011, Runter wrote in the 3rd comment:
    Votes: 0
    Idealiad said:
    donky said:
    Cons: Not user friendly in that it does not support cut and paste due to the use of canvas.


    I think this showed up on a TMC thread a while back as well. Is there no way to get c&p with canvas? I guess it's not a common use case to copy directly from output on a mud anyway if you have a convenient logging facility.


    I think the solution is moving away from a canvas and treating text as text to the browser instead of imagery.
    11 Jun, 2011, Idealiad wrote in the 4th comment:
    Votes: 0
    I can think of some good uses for the canvas though, why should we always think of the output as a statically styled column of text?
    11 Jun, 2011, Twisol wrote in the 5th comment:
    Votes: 0
    You could overlay text on top of the canvas if you want or something.
    11 Jun, 2011, Idealiad wrote in the 6th comment:
    Votes: 0
    I was thinking more of dynamically styling the text layout itself. On second thought you might be able to get just as much mileage from js/CSS though and not have to worry about canvas in the first place.
    12 Jun, 2011, kiasyn wrote in the 7th comment:
    Votes: 0
    keep in mind canvas is quite slow. you have to redraw the image each time you want to change it
    12 Jun, 2011, Runter wrote in the 8th comment:
    Votes: 0
    Yeah, I don't like canvas for this at all. There's power in treating text as text. Stylistically you should be able to do the same thing as what is being done with canvas. Bliting text on a canvas is a good way to start treating it as an image and lose things like copy and paste.
    12 Jun, 2011, Nathan wrote in the 9th comment:
    Votes: 0
    I'd agree that some kind of CSS seems more appropriate, that being it's' purpose, if the user didn't mind a small reload wait when changing colors/styles. Especially since there's probably a way to refresh a portion of a frame without needing. Copy and paste being most useful in the input, the input could be separated from the canvas. Is there any point in using an image library when the context is text.
    12 Jun, 2011, Runter wrote in the 10th comment:
    Votes: 0
    Nathan said:
    I'd agree that some kind of CSS seems more appropriate, that being it's' purpose, if the user didn't mind a small reload wait when changing colors/styles. Especially since there's probably a way to refresh a portion of a frame without needing. Copy and paste being most useful in the input, the input could be separated from the canvas. Is there any point in using an image library when the context is text.


    It wouldn't require a reload. The Document Object Model can be changed in real time just as the canvas is being written to in real time. Changing the DOM is probably more efficient, and could reproduce exactly what this was being done thus far. The canvas is far more appropriate when you *need* pixel manipulation capabilities. It's a bit interest in the example that it draws ascii art when the point of ascii art is when pixel manipulation isn't available…
    14 Jul, 2011, donky wrote in the 11th comment:
    Votes: 0
    Here's a better alternative, no canvas: shellinabox.
    14 Jul, 2011, donky wrote in the 12th comment:
    Votes: 0
    Also webtty. There's also various other things like anyterm and ajaxterm which apparently do server-side processing and forwarding the result.
    0.0/12