Andrea was a project imagined by me toghetger with my friend and colleague Dragos Acostachioaie, during our fist years of college (1998).
We explored the possiblity of a distributed, object-oriented graphical user interface (GUI), using a client server architecture.
For many reasons, the most important being the lack of time for coding (we were both students and employed), this project
never materialized and remained only in theoretical stage and in our minds.
In 1998, this project was presented at Development and Application Systems Conference,
hosted by Stefan cel Mare University of Suceava (Romania).
The paper was inluded in the official book of the conference and it is my first
(and to the date the only) published paper (ISSN 1222-7234, pages 33-42).
With this paper I have concluded that I will not become a researcher. My nature towards real work applications led
my steps towards administration of computer systems and network. Later on, this path led me towards a career in operational management
of information systems. Dragos eventually publised several books about Linux and teaches Computer Science at
Computer Science Faculty, Alexandru Ioan Cuza University of Iasi (Romania EU).
Andrea
A Distributed, Object-Oriented Window System
by Radu Filip and Dragos Acostachioaie
1998
Abstract
Nowadays, nobody can concept a complex and powerfull application without a user interface. Born
in 1980 at Xerox Parc, the idea of user interfaces was popularized by Apple which developed and marketed
Lisa and Macintosh, in 1984. It was followed by X Windows, NextStep, OpenLook, and so on.
In the near future, computers will learn to hear, to talk, to understand. But as long as 80 percent of
the information received by the human being is performed through eyes, we'll need visual informations, by
user interfaces.
This is about a new window system for UNIX platforms we start working at, in the first place, and
about computer networks in second.
1. Introduction
What makes Andrea something different than other window systems? We'll try to answer to this
question below. But first, let's take a short look through well known user interfaces.
For years, we work on different systems, with different GUIs such as Solaris, X and infamous
Windows. Some of these have some qualities, some have others. But all these have some limits too. And
these limits can be very irritating for people who love freedom, who like to experience, who want to adapt a
GUI to his needs, not to adapt himself to the needs and restrictions of a GUI.
And how must a user interface look like? Like Windows'95? Like Motif? Like OS/2 or Apple
System 7? What is better? None is better! Old greeks said that "colors and taste cannot be discussed". This
is the reason for which no GUI's aspect will not became universal.
And what programming model must be considered at the base of a complex software, such as the
user interfaces are? Could be the classic one, where all is written in standard structured programming and
where applications use a number of documented functions and structures, called API. The problem is that
any change in a routine inside API consists in a change in all existing applications, or in increasing the
complexity of GUI, because for a single feature there are several functions that perform it (try to think of X
Window color handling). It is no the goal of this paper to discuss about the structured programming versus
object-oriented programming. But we consider that it is obsolette to develop a window system using
structured programming and to develop an application using such a system, especially at the end of '90.
The last years showed us that the world of tommorow will be the world of networking. In a world
like this, a non-distributed application is a dead application because, as Sun has already shown us, computer
is the network itself. Java applications reduce the cost of human, material and financial resources by
centralizing the administration and technical support. With classic GUIs nothing is changed because every
workstation needs to be setup and maintained, with a single notable exception: the X Window System. It's
true that there are some tentatives to implement graphic environments based on network, like Netscape
Constellation, Sun HotJava Views and TriTeal SoftNC, but these are based on non-conventional solutions.
All these considerations, limits, restrictions and facts lead us to the idea that it is possible to design
and develop a new graphical user interface that embeds in it as many possible features of classic window
systems, to have a very high level of flexibility and to be poor in limits, both on user and programmer side.
2. Design & implementation
2.1. Concepts and features
Let's take a look at how premises and concepts became features in Andrea:
Open system architecture is "a system that implements sufficient open specifications for interfaces,
services, and supporting formats to enable properly engineered applications software to be ported
across a wide range of systems with minimal changes, to interoperate with other applications on local
and remote systems, and to interact with users in a style which facilitates user portability". (Guide to
the POSIX Open Systems Environment, IEEE POSIX 1003.0). In this way Andrea is completely
transparent. There are no undocumented routines, there are no "tricks", all sources, examples and
documentations are available from The Net. Every idea or improvement is welcome.
Client-Server Architecture is the way to distributed applications. As you can see in figure bellow, the system is
divided in two parts that run on different machines, even on different platforms. A possible situation is
when all these parts are located on the same machine, but this is just a particular situation. Each of these
parts are designed to perform only some services and to intercommunicate one with each other for inputs and
outputs. In that way, increasing the need of hardware performance of one part can be solved not by
upgrading all machines but by increasing only one.
Object Oriented Programming. Maybe there is no other situation where OOP is more proper to use like
user interfaces. Everybody knows how easy it is to develop a general object and then to specialize it
through inheritance, polymorphism and embeding. This mechanism allows to hide complex operations
(as initialization, parametrization) in private part of an object so the only taks of the user (programmer) is
to handle it by public methods. A proper example is the communication mechanism in Andrea (see
below). But it is not the only one. For graphic enviroments there was developed for years many graphic
image formats, many types of fonts, and many other resources. While Andrea is at the beginning there are
no possibilities to support it all. But for the final user or programmer, a new version that add other
particular formats is not a headache. The only change is that he can use more resources than before and
that's all. This simplity is not a trick, it is not a modification of base architecture, is only a feature of
OOP because the handling of resources is a part of Andrea object hierarchy.
Portability is necessary because of the variety of hardware and software in use. But Andrea is not an
example of binary portability, even not source-code portability because it is written in C++ language (not
fully standardized yet) and it uses UNIX systems features like signals and shared memory. Without these
features Andrea is not the only Andrea we dreamed of, but is not Andrea at all. Andrea is portable at
communication level. For the server, it does not matter on what platform run Andrea Desktop while it can
receive the inputs and send outputs through network. So, although Andrea Server will work only on
UNIX systems, it is posible to develop Andrea Desktop on many other platforms while that platform can
be used in graphic mode and can support communication protocols used by Andrea.
Flexibility for a software is to be able to adapt to things that do not exists when it was designed and
implemented and on jobs that designers cannot imagine when they write it. But it is also the ability to be
adapted for the needs of the final user in the way he wants with no restriction or compromises. The key
word for flexibility is simplity. Simplity is flexibility, flexibility is freedom and freedom is power for any
application. Andrea flexibility consist in the capability to work in etherogenous networks using many
protocols, in capability to work with different graphics format, fonts, icons, etc. , in capability to be
configured at detail level, in availability to hack and experience, and not at least in easiness of use.
2.2. Architecture of Andrea
The Andrea Window System has two main parts:
Server side, which consists in several services like object
management, graphic aspect control, fonts and images handling and others.
Client side, platform dependent, which runs on the local
machine and controls the user inputs and outputs. It provide device drivers and
graphic libraries.
A third part exists, the Applications side. This part
consists in Andrea applications and this applications can run on machines
different than server machine and client machine. But this side is not a part of
Andrea System itself, except Andrea Client, discussed bellow.
These three entities are communicating using different channels. All of
them are running from different machines, network transparent. This way, Andrea
is a distributed system.
The following picture present the architecture of Andrea Window System:
2.3. Describing Andrea
Even Andrea has a client-server architecture, client and server are
not monolithic applications. Both client and server consists in
small applications wich perform particular, well defined tasks. This tasks
communicates one with other (see figure), and all of them are independent
processes. This approach enable a high level of flexibility and diversity,
because, users can choose any service (except the main server) in same way he
can choose desired wallpaper image on classic GUIs. All of this services will
always perform the same taks, but in different ways. Interfaces between
services will be always the same and will be controled by the
authors of Andrea for portability and more important, for compatibility reasons.
But this micro-kernel (or micro-server) architecture allows and encourages
developers to write more services for the same task, so the final user has
possibility to choose anytime the one he wants. More than this, the maintance of
the whole system will be more easy.
2.3.1. Component parts
Communication mechanism
Communication is performed by some routines (functions) inside
communication library. No separate process is needed. There are general
routines, used by objects and programs who send, wait and receive messages.
These routines works with particullary routines who implement communication
using shared memory, and network protocols. At this moment only TCP/IP protocol
is supported but adding a new one it is easy and it generates no problem because
general routines remain the same. It is enough to recompile server, client and
applications without any change.
Messages are implemented using classes. This way, events are just
particular cases of messages. There are events for keyboard and events for
mice.
Server side
Andrea Server's main job is the management of objects on
the screen. It controls what is on top, what is hidden and what is partially
covered. When an application creates an object Andrea Server puts it on the
objects table and destroys it when application does that. But how can Server
know when an object is created? If the application and Server run on the same
machine, they share the memory area of the object. But if the application run on
another machine, object's constructor sends to Server, through network, the
objects properties and Server will create a similar object with received
properties. This ability of an object is implemented in root object of Andrea hierarchy so a
programmer is out of any worry.
Another job of Server is to manage user inputs (key pressed and mouse
movement and pointing). It determines the object who will receive these inputs
and puts in its queue some messages. Finally, Andrea Server sends outputs to
Andrea Client using an Aspect Manager.
An Andrea Server will be started for each client connection request.
Aspect Manager's single job is to control aspect of every
object on the screen. When Andrea Server wants to draw an object it does not
perform that directly by communicating with the Desktop. Andrea Server will send
to Aspect Manager the properties of the object (coordinates, text, status, etc.)
and, if Aspect Manager request, enviroment properties like system color, font
size and style, and others. Aspect Manager will decide how the object must look
like and will send to Desktop one or many graphic primitives like points, lines,
fills command, etc. The only condition is not to get over the object area. So it
is possible to develop an Aspect Manager who draws objects like Motif, another
for OpenLook, another for Windows'95 and so on.
Because of graphic primitives, vector images will be more performant than bitmap images. But
Andrea allow a cache mechanism similar to web browsers to decrease the traffic and time of
waiting.
An Aspect Manager will be started for each server started.
Color Server implements Color Management System, designed
to support any color representation model such as RGB and CYMK for example. To
perform it, Andrea defines hardware color, an unsigned four byte integer
to represent a shade of color. The first mode to use colors is to work with this
hardware color itself or with it's text equivalent like "Blue" of "Aquamarine".
Corespondence between several color names and integer values is realized by a
configuration file. More, any application could create its own colors name or
modifing existing one, without affecting other applications. The second way is
to translate a color from a particular representation model to a hardware color
value using proper routines by an application. These routines are not part of
Andrea Color Management System but can be distributed in shared libraries.
Usually, Color Server will be started once, but if a Client desire
another Color Server, this one will be started, if available.
Image Server provide graphic format handling. Handling of
graphic formats is requested by Aspect Maganager and applications. Because the
diversity of graphic file formats, fonts, icons, mouse pointers, etc., Andrea
provides a unique mechanism to load and handle any image. We decided to use the
"lug" library developed by Raul Rivero. There are many, many graphic
formats and Andrea cannot support all of them from the beginning. But like as
communication protocols, new formats can be added to Andrea without any change
in existing software at that moment. This is true also for fonts and other
types of visual resources.
Another feature is there are no restrictions in using images. For an
icon, for example, you can use any available image which will be scaled at icon
size established by the user. No matter if it is a very large one. It's his
problem to wait for scalling and transferring. For backgound he will be able to
use every documents recognized by a viewer. Initially, only few image types will
be recognized, but in the nearly future will be possible to use for background
HTML, PostScript or other formatted documents, or even video sequences like MP3,
FLI, AVI, and so on.
Usually, Image Server will be started once, but if a Client desire
another Image Server, this one will be started, if available.
Font Server provides the same services as Image Server, but
for fonts. Our desire is to be developed servers capable to handle large types
of fonts, like TrueType 1 and 2, Adobe and others.
Client side
Andrea Client does not know anything about applications or
objects. It provides a graphic screen where it draws graphic primitives received
from Aspect Manager. It also sends to Server all user inputs from keyboard and
pointing device like mice. It works with the graphic adapter and monitor using
device drivers and a graphic library.
Andrea Client can be ported to any system that supports graphic displays
and network communications. In environments where proper graphic libraries and
device drivers already exists, only communication library and client are to be
ported. This enable Andrea to be used in etherogenous networks.
Applications side
Applications are servers for the user, and clients for
Andrea Server. Applications used can be run localy or remotely. For Server it is
no difference. This advantage provide to Andrea Window Systems the same features
like Java applications, but with some minor and notable differences.
Applications will run not on the machine used by the final user. It will run on
the Application Server machine, or something like that, or on any other host.
The idea is to implement the model fat server, thin client.
All Java qualities like write once, run anywhere,
zero administration or single upgrade for all users
could be find in this model. In the same way how Java need a Java Virtual
Machine for every particular platform, it is needed a particular Andrea Client
with drivers and graphic library for any platforms.
Andrea Desktop is the first application started by the client. It
provides the desktop, the virtual screens, icons, takbar, launchpad, etc. In
fact, it provides the graphic enviroment that user wants. Anytime, users can
choose the desired one, if available.
It is not necesarry that the Desktop to be installed on the same machine
like client. This allow any user to use preferred enviroment work remotely, like
telnet or rlogin. And this without massive images transfer accors the networks.
2.3.2. An example
In a classic, etherogenous LAN, an usual situation of using Andrea Window
System is suggested by the picture below:
2.4. What things are fixed
From freedom to anarchy it is a very short distance. That is the reason
because allways will exists things impossible to change or customize. But these
restrictions must be as less minimum as possible. In Andrea there are few fixed
things too:
Interfaces between all components of Andrea are designed and controlled by
the authors of Andrea, for compatibility reasons. Anytime, on Andrea Official
Site pages, will exists a list with all accepted servers. This list will not be
imposed, but will be recommended.
Easiness in use cannot be reach without having the same object manipulation
mode. This is the reason because one of inflexible things is the mode how
objects are handled. But if a programmer wish to change that, he can use
inheritance.
Developing another object hierarchy is possible only by inherit of the root
object
Because Andrea objects use UNIX features like shared memory, applications
can be developed only on UNIX systems. In the future, this problem will be
solved by porting communication library
to other platforms.
Andrea Server can run only UNIX machines and there are no intention to
change that.
3. How it works, anyway?
A common session of working with Andrea is described as follows. First, let's suppose that Andrea
is used in a network because working on a single computer is not different like common GUIs. Second, let's
name Server and Aspect Manager machine A, user machine B, and machine with applications C.
After network admin comes to work, he turns the computers on. On machine A he starts Andrea
Server which is a daemon process. Andrea Server will wait for a request for connections from one of Andrea
Clients on the net. Then a user login on machine B (network configure does not matter) and at prompt line
start Andrea Client. Andrea Client determines from local configuration file the address of default Server and
sends a connection request message to it. Andrea Server receives these requests and performs the following
opperations:
Authorize the request
Determine informations:
if to use client settings or server settings
machine B display hardware properties (screen area, color depth, etc.)
desired Aspect Manager (if available; if not it will use Default Aspect Manager)
desired additional services (Color Server, Image Server, Font Server)
user visual configuration
Load Aspect Manager, Color Server, Image Server and Font Server
Send initialization message to Client
Client receive initialization success message and start desired Andrea
Desktop program that create Desktop Object which is created and drawn. Then
initialize the user grahpic enviroment (arrange of icons, colours preferences,
startup apps, taskbars, launchpads, etc.) and draw it.
All drawing opperations are executed sending messages to loaded Aspect Manager. It will send forward to
the Desktop the proper graphics primitives to perform the drawwing message.
Then the user presses keys and handles mouse in two purposes:
to start an application from machine C
to manipulate existing graphical objects on the screen
In the first case, Andrea Server determines from coordonates of mouse pointing or from pressed
keys what application is desired and starts it. The application will create a window and several other objects
(menus, buttons, etc). At the moment of creating each object, object's constructor sends to Server its
properties. Server receives these properties and creates a similar object. Then it determines the object
position and sends to Aspect Manager the information needed to draw it (graphic context). As a result,
Aspect Manager will send to Desktop one or many graphic primitives that describe how to draw the object.
In the second situation, the user wants to handle the existing objects, moving a window for
example, pushing a button, or displaying a menu). His commands will be received by Andrea Server too and this
will determine the object it is addressed to. Then modifying it's state, will:
Redraw the object in new conditions (sending messages to Aspect Manager)
Inform the application about these changes by sending the new properties
When the user wants to exit, he kill the Desktop. Andrea Desktop will send a disconnect request to
Andrea Server. Andrea Server receives that request and performs the following operations:
Close all existing applications used by the user, including Andrea Desktop
which is closed the last
Destroy object table and clear all enviroment
Close Aspect Manager and other servers
Wait for another connection
4. Why use Andrea?
Users will benefit because:
they will be able to configure almost every detail from number size of virtual desktop to size,
font style and color of every object
of possibility to choose prefered aspect by selecting an Aspect Manager
of possibility to choose prefered servers, if aviables.
is easy to use (Andrea object handling is the same independent by Aspect Manager)
can use weak computers connected to network for running powerfull
applications
of possibility to use predefined settings from Server
can use Andrea Desktop on platforms different than UNIX (if for that platform was developed
an Andrea Desktop). No emulator needed. For example in a X window it is possible to have an
entire Andrea Desktop.
of possibility to use the same graphic enviroment from different hosts or
terminals, like telnet or rlogin but in graphic mode.
Programmers will benefit because:
they will concentrate on what application does, not at how it will look,
because their applications will looks different using different Aspect Managers
(but always all objects will have same properties, including size and position
on the screen).
the low-level details such as communications between objects and between GUI components
(Client and Server) are hidden into the objects themselves. Anyway we must
not forget to develop applications as much as possible independent of any GUI, separating data
processing by I/O operations and by interacting modes with users. This will make your software
not only portable on different platforms but also on different GUIs (try to think at
Netscape Navigator).
an application will no longer need to be distributed on every workstation on a LAN. It will be maintained
on a single computer. Upgrade will consist only in changing the old version with a new one.
But, unlike Java applets, an application for Andrea will not be downloaded from server to
client. It will work on its host and will receive and send inputs and outputs to and from
network.
it is possible to develop an application that to display some information on
a machine and some on another. Or to display informations simultanous on several
machines. At this stage of project, cooperative works is not implemented. But it
will be considerated in future.
can handle a large number of image formats, fonts, icons, and other visual resources.
Network administrators will benefit because:
there is no need to install and configure an entire graphic enviroment on every workstation.
The only job will be to set up the Server and eventually to multiply on stations a standard personal
enviroment.
the only machines that must be powerfull (upgraded) will be the server and applications host.
it's possible to monitorize and record all messages sent by Andrea Server to Andrea Desktop and
to Aspect Manager and to see what a user is (was) doing without his knowledge.
5. About authors
Radu Filip is graduate of Highschool of Informatics, Iasi. Currently he studying Computer Science at Alexandru Ioan Cuza University of Iasi, Romania
Dragos Acostachioaie is system programmer and UNIX administrator. Visit him
online at http://www.adt.ro/
![[Andrea Architecture]](images/architecture.gif)
![[Andrea in a classic etherogenous LAN]](images/sample.gif)