~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.