This is a suggestion for the architecture of the desktop and application architecture in Warsaw/Moscow. It is intended for discussion on design@berlin-consortium.org. We also have a list of features that we want in Berlin, which you might look at.
In Berlin, each console (which consists of a display, input devices (keyboard, mouse, joystick), and possible audio devices) has a display server attached to it. That display server runs as the user who is sitting at the console. Each application connects to exactly one display server.
A display server consists of a lot of small CORBA objects, widgets etc. All widgets can be replaced to have any look & feel, so that each display server has it's own look & feel. This means that each user will see his/her favorite look & feel when running applications, whereever those applications are running.
It is possible to have multiple consoles on one physical computer, but the display servers attached to those consoles don't share any data. This is made possible by GGI and USB.
When a user sitting at a console on one computer starts a remote application on another computer, the remote application will connect that user's local display server. Other users, even those who run a display server on the remote computer cannot see the remote application, unless they explicitly connect to that same application. To do this, the users will need some kind of mutual agreement, like passwords or some other form of authentication.
Each user, connected to his/her display server, have one or more virtual desktops. This is what the IDL interface desktop is intended for below. The interface desktopEnv, represents the complete desktop environment with lists of all virtual desktops and desktopInhabitants etc. desktopInhabitants can be both applications or applicationDocuments.
The design of Berlin is document centric, which means that documents and the stuff that users work with is in focus, rather than the applications which operate on the documents.
In Berlin, there will be a list of filetypes, which exist in the system. This could be TIFF, JPEG, WAV, DXF, text, HTML or any other type of file. A filetype is represented through the fileType IDL interface defined below.
File types are recognized by file type recognizer components, which have the fileTypeRecognizer interface defined in IDL below. There will be multiple fileTypeRecognizers installed in Berlin. Each application which introduces a new fileformat should for instance provide a fileTypeRecognizer for the format. The fileType for a file is determined by calling recognizeFile in all fileTypeRecognizers installed in Berlin in the order of thier recognitionPriorities, until a fileType is found.
Each filetype can have any number of actions associated with it. These actions could be "view", "edit", "print" or perhaps "open". Such an action is represented as the fileTypeAction interface defined in IDL below.
Every fileTypeAction has a prioritized list of applications for performing the action. The applications associated with the action must all support the type of the file, which the action is associated to. Applications are defined by the applicationClass interface defined in IDL below. It follows from this, that an applicationClass has a list of fileTypes that it supports.
When an action is performed on a file of a certain type, the first application registered for that action should usually be launched. The rest of the list can be used to display a list of all applications registered for this action to the user. When an application which had first priority in an actionlist is uninstalled, the next application in the list automatically becomes the new first priority application for that action.
There is a conversion interface called typeConverter defined in IDL below, which can convert a file from one filetype to another. The lossynessType defined in IDL below, defines the lossyness for the conversion in a typeConversion component.
A conversion manager (not yet written) will be used to find the shortest and least lossy conversion path from one filetype to another. It will be able to do this even if multiple conversions between multiple filetypes are required. No IDL interfaces has been defined for this yet.
Certain kinds of data are known and well defined. This could be a text-document, an image, a soundfile, a 3D object or something else. Berlin will be able to understand many well defined datatypes. To do this, we will need some IDL interfaces to exchange data of the various datatypes. We already have W3C's Document Object Model (DOM) as an interface for textdocuments.
The interfaces for accessing well known datatypes, should also support methods for determining wheter a file is of the correct type for a particular interface or not.
Most applications should be able to operate in 2 modes (perhaps more): MDI (Multiple Document Interface) and "separate documents". This is what the appGUIType datatype is for in the IDL interfaces below.
In MDI mode the dekstop owns an application with a complete GUI. The application has all open documents in windows on top of the application.
When the application is in "separate documents" mode, the application itself is not visible. Only open documents are visible. Each document has a complete application GUI, as if each document were an application which can only have one document opened at the same time.
Here are some miscellaneous IDL interfaces for Warsaw and Moscow. Please note that it has not been compiled with an IDL compiler, so the syntax might be buggy.
interface applicationClass;
interface desktopInhabitant;
interface applicationDocument;
interface application;
interface desktopEnv;
interface virtualDesktop;
interface fileType;
interface fileTypeAction;
interface fileTypeRecognizer;
//For choosing between "Multiple Document Interface" in an application,
//where you see the entire app, and documents in windows on top of the app,
//and "Documents" interface, where each document looks like a complete
//application.
typedef enum appGUIType = { agtMDI, agtDocuments };
exception unsupportedGUIType;
//Normal, minimize etc. screenMaximize means that the application or document
//gets it's own screen (virtual desktop), and windowMaximize just maximizes
//the application or document on top of other applications. splitScreenMaximized
//is for a maximized application or document, which can share a virtual
//desktop with other applications, so that the screen will be split in
//2, 3 or more areas.
typedef enum appGUIState = { normal, windowMaximized, screenMaximized,
splitScreenMaximized, minimized };
//Question: Do we need splitScreenMaximized? We can do this if application
//or document is screenMaximized and it's desktop is splitScreen.
//The type of a virtual desktop
typedef enum desktopType = { windows, fullScreen, splitScreen };
typedef enum lossynessType = { noLoss, littleLoss, muchLoss, extremeLoss };
//This class represents an application registered in Warsaw/Moscow.
//It is used for creating the kind of documents that the application edits.
interface applicationClass
{
applicationDocument createDocument();
//List of filetypes that this application supports
//Question: Should we have a list for both input and output support?
unsigned long fileTypes();
fileType fileTypeAtIndex(in unsigned long index);
};
interface fileType
{
//The name of the type, as displayed for the user
attribute wstring typeName;
//List of filetype actions
unsigned long actions();
fileTypeAction actionAtIndex(in unsigned long index);
};
interface fileTypeAction
{
//The name of the action, displayed for the user
attribute wstring actionName;
//Reference to the fileType that this action is associated to
attribute readonly fileType associatedType;
//List of applications to perform this action, in the order of priority.
unsigned long applications();
applcationClass applicationAtIndex(in unsigned long index);
};
interface fileTypeRecognizer
{
//List of fileTypes that this component recognizes
unsigned long recognizedFileTypes();
wstring recognizedFileTypeAtIndex(in unsigned long index);
//Try to recognize a file. Returns NULL if it is not possible with this component.
wstring recognizeFile(in wstring fileName);
attribute readonly unsigned long recognitionPriority;
};
interface typeConverter
{
attribute readonly wstring inputType;//The type that it converts from
attribute readonly wstring outputType;//The type that it converts to
attribute readonly lossynessType lossyness;
//Perform conversion. NOTE: I think we should use some kind of
// data pipes/streams instead, to allow
// RAM based conversion
void convertFile(in wstring inputFileName, in wstring outputFileName);
};
//This is the interface for things that live on a desktop: documents and apps!
interface desktopInhabitant
{
attribute appGUIType guiType;//The way that the GUI of this inhabitant behave.
//raises unsupportedGUIType, if an application doesn't
//support the requested gui type
//Note: There should be a list of supported GUITypes
attribute appGUIState guiState;
attribute virtualDesktop housedBy;//The desktop which houses this app.
//Will be NULL if guiType == agtDocuments
};
//This is the interface for an application document
interface applicationDocument : desktopInhabitant
{
attribute wstring name;
attribute boolean active;
//Change application in which the document runs???
application inApplication();//Returns the application, in which this document exists.
};
//An application
interface application : desktopInhabitant
{
//If guiType == agtDocuments, then the housedBy attribute will be NULL,
//and guiState will not be used, since the application does not exist
//on the desktop, when guiType == agtDocuments.
unsigned long applicationDocuments();
applicationDocument applicationDocumentAtIndex(in unsigned long index);
};
//This is the interface for the desktop environment
interface desktopEnv
{
//Array of known fileTypes
unsigned long fileTypes();
fileType fileTypeAtIndex(in unsigned long index);
//Array of registered ApplicationClasses
unsigned long applicationClasses();
applicationClass applicationClassAtIndex(in unsigned long index);
//Register new application classes (registry-based?)
void registerApplicationClass(in applicationClass newClass);
//Question: How about remote applications running across a network?
//Array of running desktopInhabitants
unsigned long runningInhabitants();
desktopInhabitant runningInhabitantAtIndex(in unsigned long index);
//Array of virtual desktops
unsigned long virtualDesktops();
virtualDesktop virtualDesktopAtIndex(in unsigned long index);
attribute desktopInhabitant activeInhabitant;//Active virtualDesktop is the one
//housing this one.
attribute appGUIType defaultGUIType;//The GUI behaviour which is the default
//when creating documents.
attribute appGUIState defaultGUIState;//The GUI state which is the default
//when creating documents.
};
//The interface of a virtual desktop
interface virtualDesktop
{
//Array of inhabitants on this virtual desktop
unsigned long housedInhabitants;
applicationInhabitants housedInhabitantAtIndex(in unsigned long index);
attribute desktopType type;
};
//------------------------------------------------
//Just an offtopic radioGroup interface from the discussions on the
//Berlin-list:
interface radioGroup
{
attribute unsigned long buttons;// number of buttons
attribute unsigned long columns;//Quick suggestion for controlling layout
attribute unsigned long selected;//Currently selected
attribute unsgined long highlighted;//Currently highlighted (would be by mouse)
//Suggestion 1 for editing
//Setting up attributes
attribute unsigned long currentEdit;//Controls which radio-button is being
//edited with the methods below
attribute wstring label;
attribute colour fgColour;//Or should it be american "color"? ;)
attribute colour bgColour;
attribute font textFont;
//etc.
//Suggestion 2 for editing
//Edit all radio-buttons at once
attribute sequence<wstring> labels;
attribute sequence<colour> fgColours;
//etc.
//Suggestion 3 for editing
wstring label(in unsigned long index);
void label(in unsigned long index,in wstring newLabel);
colour fgColour(in unsgined long index);
void bgColour(in unsigned long index, newBGColour);
//etc.
//Question: Could these be specified as array attributes? Like:
//attribute wstring label[unsigned long];
};