ViolaWWW works great! It has impressed us here. Its fine on decstation and apollo
displays (The crashing HP display was an HP X server problem.) A strange thing is
that it seems to be so fast -- a search in the CERN phone book seems instantaneous
(when done at CERN). Perhaps the line mode browser's critical path is the
time taken for the terminal emulator to display the characters, and Viola is
faster.
We're going to have to standardize (have a competetion for) the WWW icon.
I like the web, though some may be arachnophobic. We use a globe on the NeXT.
I wondered about some combination of an open book and a globe...
The viola changes aren't in www v1.1, but are in the master code for 1.2
(or 1.1a) already.
Now for details about the marking of fields for viola:
>To answer your questions:
>
>> Do I correctly assume that anything which is displayed on the screen
>> surrounded by SI..SO characters can be clicked on and will then be
>> sent to www?
>
>That's correct, for the old version of Viola. This scheme, however, has
>changed in the new version... (see below).
>
> Here are two important things Viola need to interface to www. Both might
> be effected by -viola:
>
>1) A consistant and hopefully unique prompt ending. It should always look
>the same ("::: " or whatever is predictable).
Are you sure it isn't safer to use a non-printable character? That would
be guaranted unique.
> 2) Instead of the old (and limiting) SI..SO scheme, the new scheme is to use
> the \h()\e() combination thusly:
>
> See also CERN copyright[\h(2)\e(2)].
>
> The text within \h(...) is displayed highlited, and text within \e(...)
> is ``embedded'' into the text field for retrieval (when clicked) by Viola
> scripts.
To separate the anchor text (highlished bit) and the meaning is a good idea.
In that case we would highlight the whole phrase: in the underlying mark-up,
the beginning of the anchor is marked as well as the end, although that is not
apparent with the line-mode browser normally. Using your example, this would come
out like
See also \h(CERN copyright)\e(2).
without any [numbers] displayed at all.
Again, the use of printable brackets () is a bit dangerous, as in fact
there will be cases in which unmatche dbrackets appear within the highlighted bit.
-------------
> I'm very interested in producing a usable WWW front-end (the current
> ViolaWWW was a one-nite hack to prove feasibility). I am also thinking
> of incorporating the HHTP code into Viola. Thou I have to look at the
> code more...
>
If you want to look at the code, see whether your text widget can implement the
"Object Building" methods in HText.h. These are the calls made by the www
communications code and parsers to build the hypertext. If you can provide those,
it should be easy. You just call one of the routines in HTAccess.h to
load a document by name, and it calls you back to create and build the document.
>> More qustions:
>> Did you need any mods to viola, or is everything you needed put into
>> the "ht" stack? In other words, was the viola directory a stnadrd
>> release which we can replace with new versions when they come out?
>
> No modification was made to Viola in order to front-end the modified
> www.
Great stuff.
> [...] No problem! Give me a few days, and I may have the new ViolaWWW ready.
> It will have a lot of improvements such as multiple fonts and geometry
> management.
If you really do multiple fonts, that would be great! In that case
you will probably want to combine the www access code with viola itself
in order to get the style changes as a hypertext document is parsed.
That would be really neat. It would remove all this marking of fields with
funny characters, as well.
>> Tim
> -Pei
Tim