Also see Chapter One for a brief overview of ViolaWWW.
One of the most exciting features of ViolaWWW is its client-side scripting capabilities. In a way, Viola can be characterized as a "World Wide Web Toolkit" which can be used to put together Web applications. Thus, viola provides a powerful mechanism for publishing of applications, or "applets", on the web.
The scripting language system allows browser functionality to be extended dynamically. Can dynamically plug-in new tools into the browser toolbar. For example: navigational icons which do not scroll around (possibly out of view) with the document page, or self guiding slideshow presentation tool, etc.
Plus, the extensibility simply lends a lot more flexibility in designing more sophisticated applications. For example: customized order forms, dynamic and continuously updating stock market quote monitors, interactive games, front-end to remote back-ends, etc.
Shown below is a screendump of the latest ViolaWWW (Motif version). A few things to point out: on the left side of the page there's a "sidebar" which in this case is used to show the page topics and can be used as a navigator; the right most three text buttons on the "toolbar" are little applets which are linked to the document.
These are probably the most notable features in the ViolaWWW browser:
Eventually ViolaWWW will implement all of the features specified in the HTML 3.0 DTD standard (which itself is being solidified).
Current HTML support includes:
Aside from a standard Web browser, Viola stands out with its extensibility architecture. blah blah...
To support all the ever inventive and encompassing uses of the web, browsers are called upon to have ever more features. However judiciously browser designers choose the features to implement, a consequence is that many browsers tend to be able to do many things, but also tend to be fairly shallow in each area.
Therefore, the new ViolaWWW browser architecture is designed to be extensible so that the software can hope to dynamically meet the needs to unanticipated future needs. No one can build a browser that has all the features that everybody wants from the outset. The key to dealing with the unknown future is flexibility.
That is, the scripting language allows the system to grow even after the software has been deployed. For example, specialized or customized graphical user interfaces, such as order forms, can be created and published on the web to suit special needs.
Also, extensibility is a good approach to deal with the trend of the web expanding beyond the documentation publishing realm. People will want to use the WWW to implement highly interactive applications. We're alreay seeing evidence of that with input-forms, the click-able images (using ISMAP), and server-side scripting. A vision is that the WWW will be used to publish "applications" as well as "documentation". ViolaWWW's client-side scripting capability is a natural extention toward that direction.
Source and binary can be found in ftp://ftp.ora.com/pub/www/viola.
Platform: Unix/XWindows. Sparc binary is supplied.
Please see the setup notes if the colors are coming out badly.
Both ViolaWWW front-end programs can take the start up document URL as an argument, thusly:
% viola URL % vw URLIf you do not supply any argument, the default URL is taken from the WWW_HOME environment variable. In liu of WWW_HOME, the fall back URL is http://berkeley.ora.com/proj/viola/violaHome.html
If you want to set the initial start up document to an URL, you could do it like this:
Major misfeatures in the current Viola/WWW:
The author is working on these problems... etc... Please report bugs and comments to firstname.lastname@example.org.
For compatibility's sake, the file format used is compatible with 'xmosaic'. ViolaWWW currently writes the information to the file "~/.mosaic-hotlist-default" every time a change occurs (add, delete, edit).