~azzar1/unity/add-show-desktop-key

IVLE - Imported Code (Investigation)

====================================

    Author: Matt Giuca

    Date: 4/12/2007

In this document we look at various libraries and code around the Internet

which we might use in IVLE.

Console

-------

There are a few JavaScript consoles available (written in JS, for JS).

We need one that can handle Python. There are two options here: one that just

works as a terminal to any Unix shell, or one specifically for Python which

might have better command completion like the JavaScript shells.

Our prototype uses WebShell at the moment.

### Discussion: Full terminal vs console emulation ###

There are 2 possibilities open to us: we can either emulate a full terminal

(able to run vim and other curses-style applications), or just a basic console

emulator which only allows for cooked command-line input.

Joshua and friends are basic command-line emulators, while WebShell and

AjaxTerm are full-blown terminal emulators.

The important difference is speed. The full terminal emulators send keystrokes

to the server and get as a response a "diff" of characters on the screen.

*Note that* this means even when you're just typing away, you can't see

what you've typed until the server has processed the text and sent back

the updated screen.

A console emulator would be able to accept a line of user input on the client

side without sending anything to the server. It could then transmit the line

(as string text, not character strokes) and the server could then send back

the response (as string text, not individual character updates). This is a

huge amount faster and I recommend it if we don't need vim and the like.

### Full terminal ###

#### WebShell ####

[WebShell](http://www-personal.umich.edu/~mressl/webshell/).

Based on Ajaxterm.

This is what we use in the PynApple prototype.

Looks a bit heavy (has a clunky iPhone interface - might drop down to its

lowest-common denominator, Ajaxterm).

#### AjaxTerm ####

[AjaxTerm](http://antony.lesuisse.org/qweb/trac/wiki/AjaxTerm) is a nice

lightweight option for the "full terminal emulation" option, but it doesn't

plug into Apache - it runs its own web server. This is unacceptable really.

Says its based on [AnyTerm](http://anyterm.org).

#### AnyTerm ####

[AnyTerm](http://anyterm.org) is very very similar to AjaxTerm but it plugs

into Apache instead. Unfortunately it is written in C++, as an Apache module.

Yuck.

I haven't been able to get it to compile yet.

This isn't really desirable for the end product but we can use it for now to

get a console working quickly.

### Client-side (line) shells ###

#### ajaxPHPterm ####

[ajaxPHPterm](http://sourceforge.net/projects/ajaxphpterm/) is about what

we're looking for. It is a rather simple ajax screen which presents a terminal

using just an HTML text page and a text input box.

It simply sends the text to the server and when the server responds, it prints

it to the screen.

It runs bash but can't run any curses apps. It also can't yet run the Python

interpreter or any interactive apps (try "cat" with no arguments - nothing

happens). This should be easy to fix.

I think we can work from this (possibly rewrite from scratch, in Python, but

based heavily upon this). I would like to change:

* Text field into JavaScript interacting directly with the keyboard, allowing

  us to do tabs and things. (Though this then kills copy+paste).

* Support interactive applications (though only console apps, not curses).

* Support colour and other ANSI codes (currently just prints the ANSI codes

  directly into the HTML).

* Change use of pre into normal text to allow word wrapping. (Not how real

  terminals work but it's nice enough). Question: Do we want a hard 80-char

  wrap like real terminals or is it okay to soften this to a browser-wide word

  wrap?

#### Joshua ####

[Joshua](http://blogrium.com/2006/01/28/joshua/) is a web-based JavaScript

console ([online demo](http://progrium.com/dev/ijs/)). We need a Python one.

#### JavaScript Shell 1.4 ####

[JavaScript Shell](http://www.squarefree.com/shell/shell.html)

Also JavaScript based.

#### Termlib ####

[Termlib](http://www.masswerk.at/termlib/).

Ajax shell, looks very generic (no default language or connection). Has

floating windows.

Restrictive license (noncommercial).

Text Editor

-----------

Two online (JavaScript-based) editors are [CodePress](http://codepress.org)

and [EditArea](http://www.cdolivet.net/editarea/).

We have used EditArea in the prototype. Crunchy uses EditArea.

[Comparison](http://www.virtualroadside.com/blog/index.php/2007/06/08/codepress-vs-editarea/).

It seems like EditArea is superior (and I agree from trying them out). Note

that "AutoComplete" in CodePress is just autocompleting brackets, not

"IntelliSense" style.

Oh, and CodePress doesn't support Python syntax. That's a bit of a

deal-killer.

EditArea seems a bit bulky. Can we trim it down a bit (especially for the

tutorial sheets).

Another one is [CodeMirror](http://marijn.haverbeke.nl/codemirror/). This is

very lightweight but again doesn't support

Python syntax (seems only JavaScript, probably difficult to add other

syntaxes). Also slow to update highlighting.

Subversion Client

-----------------

What we now want is a workspace browser, not a repository browser. This allows

us to have just a single browser for both the students permanent and temporary

files (see design/subversion.txt).

Most web clients are repository browsers, not workspace.

What we need is an interface quite like TortoiseSVN but for the web.

### Polarion ###

We have been using [Polarion](http://www.polarion.org/) [WebClient for

SVN](http://www.polarion.org/index.php?page=overview&project=svnwebclient)

in the prototype.

Apache license.

Nice feature-wise. Backend written in Java. Lots of confusing buttons

everywhere (perhaps not good for entry-level students).

### Our own browser? ###

Considering writing our own browser?

Advantages:

* I haven't yet found a workspace browser for the web.

* We can tailor it to the needs of new students (simple interface, different

  terminology, "file browser" paradigm instead of repository paradigm).

This task is quite distinct from a repository browser. A repository browser

goes in through the svn protocol or something like that. A workspace browser

needs direct access to the file system AND the svn client API.

So we aren't writing an SVN browser at all, but a web-based file browser with

SVN client support.

(Are there any web-based file browsers we can adapt?)

Seems as though writing our own would be simple enough when weighed up against

finding one and augmenting it.

It would be acceptable to do page loads for interactions with the server, but

I'd like viewing (without making changes to the server) to be done using

JavaScript (it wouldn't need to load data from the server).

This means either:

1. We load all the data about the directory tree from the server (ick).

2. We do a page load when the user navigates to another directory.

3. We use Ajax for just one activity: getting data about another directory

    from the server (so we can do an Ajax "ls").

(If we're going to use Ajax for this, might we as well just send data such as

updates via Ajax as well, or is this more complicated somehow?)

### SVN Web Control (SWC) ###

[SVN Web Control](http://svn-web-control.sourceforge.net/) seems to be similar

to what we're looking for - it gives you "webspaces" which are like workspaces

on the web. So this is a SVN workspace browser, not a repository browser.

Implemented in PHP. Awful documentation.

Gives errors when I try to run and the documentation is just API docs, no

installation guide... Scratch this?

Web-based file browser

----------------------

I made a separate category here for web-based file browsers which we can

possibly build into a Subversion workspace client.

There are many online file browsers. We'd prefer one written in Python but I

haven't found any yet.

Alternatively, do we want to use WebDAV? (I'm not familiar enough with WebDAV

to know its limitations).

### Online File Browser ###

[OFB](http://filebrowser.mbsoftware.pl/quick-start). PHP. Live demo available.

MIT license.

Uses Ajax. Looks and feels nice and stable.

Dependency on ["Smarty" template engine](http://smarty.php.net/).

We do not want to use its auth. It can be disabled, but then anyone can use

it. Can we plug in our own user system? How easy would it be to add buttons,

etc?

Crunchy

-------

[Crunchy](http://code.google.com/p/crunchy/) is an interactive Python tutorial

system. We haven't yet used it anywhere in the prototype but it's similar to

our "reference / tutorial" section.

Crunchy goes through a specially-prepared HTML page and augments it with

interactive Python boxes. These let you type single Python commands into an

interactive console (much more limited than the consoles such as Joshua) and

see ther results (it runs Python on the web server). It also provides edit

boxes for more involved samples.

The edit boxes use EditArea.

### Do we want to use this? ###

The console mode could be useful for very small examples. (But for just

"trying things out" a dedicated console is more useful).

For most examples I expect we'll just be using the editor mode of Crunchy. I

feel in this case we might as well just put our own edit boxes on there and

save the overhead of integrating Crunchy.

### Notes ###

Crunchy seems to be intended for an individual to download and run. It sets up

its own web server and behaves like a user application (which happens to run

in the browser), not a web application. For instance, it displays a "close"

button hovering over the top of the screen. May require some modification to

integrate it as a web app.

MIT license.