What is VisualOberon?

VisualOberon (or short 'VO') is a collection of classes written in the programming language Oberon-2. The classes are designed to let application developer easily build graphical user interfaces for programs written in Oberon-2. VO is distributed under the GNU license.

VisualOberon is not a programming language. While it sound like the Oberon version of VisualBasic, it is not an integrated developement enviroment with build in text editor, builder and that stuff. It is just a library. Nevertheless is can be the basis for such integrated enviroment.

Oberon-2 is an object orientated programming language, a successor of Pascal, designed by the famous Niklaus Wirth. It unites the famous and proofen design of Pascal (strict type system, easy to read code, easy to follow program flow, possibility to naturally structure your source code) with the modularity of Modula-2 and enhances both of them with clean, simple but powerfull object orientated concepts, including inheritance, dynamic type information, virtual methods, various access rules on class and module basis and a build in garbage collector.

VisualOberon uses OOC/oo2c as development tool, but VisualOberon in its design is not limited to that compiler. It fully bases on the language defined by the official language report and thus should be easyly adaptable to other compilers.

Main design criteria for VisualOberon

	Simplicity. VO should give great layouting power to the programmer on the one hand, but also should take away any need to handle low-level GUI things on the other hand. It should also take away any low-level design decisions. In that way it is similar to TeX. You give it a abstract description and it will make it good looking by its own.
	Extensibility and fexibility. The classes should be designed to make them easily extensible. Features missing should be easy to integrate without the need to rewrite huge code sections and without breaking compability.
	Portability. The class library should be portable in that way that the classes share the same interface among different platforms. Programs building an interface under one operating system should be portable without any changes to the code. The class library itself is not portable in that way that it is implemented by making access to a special OS. VO must be adapted to each OS. However, VO tries to build a abstraction layer everywhere where its is possible to hide OS-dependent details.
	VO should give the programmer access to all common GUI features like auto font adapting, resizability, and things like drag and drop... It should be possible to build a complete state of the art GUI.
	The used bazzar style of developing offers quick updates and bugfixes, fast response to problems and good communication and code exchange between developers and users.

About the design...

VO tries to achieve the above mentioned goals by using themeable controls together with a layouting engine.

A layouting engine take an abstract layout description and then calculates position and size of the individual controls using the information given in the description. The concept of layouting engine isn't really new, but while there many proofen advantages most developement enviroments still use so called GUI builders for designing dialogs.

For another developement using layouting engines, see the AWT and Swing packages of the Sun Java implementation. The Java developements have wisly choosen the same solution of exactly the same set of problems.

What is already implemented?

The current implementation is build on top of X11. It was developed under Linux X11R6 and fvwm2. It is very likely to run under other Unix systems running X11, too. Linux, HP and Sun are tested and seem to be working, also using VO via a X11 server on a PC has proven to work.

The current version implements the standard controls available on most plattforms but also features some more advanced controls. See the screen shot pages for some examples.

A Windows port has also been made (80%), but its source is not up to date with the main source line anymore. It took about two weeks to do the port. So, while it takes some time, a port can be handled by only one person in a rather short time. We hope to get the windows port running again later.

Other features

	Gadgets access their data through models using a similar model-viewer concept already used in the various flavours of the OberonSystem.
	A simple but very powerfull method sending system, which enables the programmer to develop automatically driven GUIs but alo develop his own way of event handling, e.g. using event-loop or callback driven code.
	A system for handling keyboard focus and keyboard shortcuts.
	A preferences system for configuration of look and feel of the hole system and individual control types.
	There is also support for drag and drop. Some of the objects already support drag and drop automatically.