Andrea Project

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:

1. Server side, which consists in several services like object management, graphic aspect control, fonts and images handling and others.
2. Client side, platform dependent, which runs on the local machine and controls the user inputs and outputs. It provide device drivers and graphic libraries.
3. 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/