The System Amadeus: Tutorial
(This page is under construction)




Base Languages

Macros
System Folders
System Properties

Macros

A set (several sets as well) of macro definitions can be described to facilitate editing.
A macro definition consists of a macro command, a macro body and an optional macro comment.
Any set of macro definitions is given in the last (possible single) branch of some skm-text. This skm-text must be activated by menu function “File->Import macro” to enable invoking macros from this skm-text. Only one skm-text with macro definitions can be active at a time. The activated macros are valid for all frames. While editing, pressing the key "Alt" initiates input of a macro command: all (ordinary, non-space) characters typed until "Alt" is released (i.e. the Alt-sequence) form the macro command to be invoked. When "Alt" is released, corresponding to the typed macro command macro definition is searched in the active
set; if found, the body of macro definition is inserted at current caret: first, it is copied to clipboard and, second, pasted at current caret.
Note. There are no macros with parameters.
Note. Search for macros proceeds downwards in the activated skm-text, so only the first occurrence of macro definitions with the same command is available.
Note. Activated by “File->Import macro” skm-text always appears in a new frame but remains active even after closing the frame.

A sample macro set:

A sample macro set here.

 

The first branch in the macro set depicts the general form of  macro definitions. However, if activated, the Alt-sequence „macroCommand“ would cause insertion of the text „macroBody“ at current cursor. The next three macro commands „c“, „ch“ and „shch“ invoke insertion of  Cyrillic characters given in the bodies of these macro definitions. The next three macro commands „iof“, „sop“ and „newJP“ take care of inserting text fragments and primitives. It should be noticed that comment is used to distinguish between text fragment and one-row primitive: text fragment in macro body (as in „iof“) must not have comment while  one-row primitive (as in „sop“) must have comment („debug info“ in the sample case); comment containing one space character will do also. The last sample macro definition (command „mcl“) demonstrates a larger macro body. For instance, one can start to write his/her skm-Java main class by typing Alt-sequence „mcl“. The sample macro set above does not cover all possible kinds of insertion (e. g. primitive heads).

The sample macro set above does not cover all possible kinds of insertion (e. g. primitive heads).
The detailed algorithm defining insert object for given macro body is outlined at the end of this section. 

Several macro sets can be placed into the last branch of a skm-text as shown in the following general picture:



Defining macro insertion: algorithmic definition

Let B be the branch representing the macro body of an invoked macro. The insertion object which will be
inserted at the current caret is defined as follows:




System Folders



Folder class contains the system properties  file Amadeus.properties, the system class-files, and

packages epsgraphics, jdom in its sub-folder org.


System Properties

System properties are listed in the properties file Amadeus.properties  located in the folder class.

This is a plain text file, in which each line describes a property in the form

       propertyKey = propertyValue

Properties are used to automatically define or re-define some default values every time the system is started.

If some of the properties is not (correctly) given in the file or the file  Amadeus.properties is missing,

the system tries to set  needed values by itself. The following properties may be given:

Property key

Property value

syntax / default

Purpose

Example

Java

Full path

Set path to Java classes

Java = C:\\\"Program Files\"\\Java\\jdk1.5.0_01\\bin\\

AmadeusDirectory

Full path

Set path to

system folders

AmadeusDirectory = D:\\Amadeus2006

defaultOpenDirectory

Full path. Default: current path (.)

Set initial O/I path for UI 

defaultOpenDirectory = D:\\Amadeus2006\\Portfolio

modelsDirectory

Full path. Default: AmadeusDirectory\models\

Set path to models

modelsDirectory = D:\\myModels

tempDirectory

Full path. Default: AmadeusDirectory\temp\

Set path to a temporary folder

tempDirectory = D:\\provisional

startProject

Project description file name

[path]pDfName[.html]

By default path=

AmadeusDirectory\Portfolio\

Project (if given) to be imported initially

startProject = Amadeus2006

iconImageFileName

[path]fname.ftype

By default, path=

AmadeusDirectory\gif\

Set icon image file name

iconImageFileName = collapsed2.gif

 

myMacros

List of elements

[path]fname[.ftype]

By default, path=

AmadeusDirectory\macros\

ftype = html

List files from which macros (if list given) have to be initially imported

myMacros = AltGr Kirillitsa.xml Java.html

defaultFont

name,style,size

style:

0-plain / 1-bold /

2-italic/ 3-bolditalic

Define default font

defaultFont = Times New Roman, 1, 18

 

autoSaveTimePeriod

Positive integer

Default: 1

Gives the period (minutes)

autoSaveTimePeriod = 3

 

locale

ENG | EST | RUS

Default: ENG

Set user interface language

locale = EST

 


Views

Every scheme is assigned a view (a sub-class of the class View) from the set of possible ones.
The view methods are applied for screen planning and drawing while displaying schemes. The appearance on the screen of any scheme is fully determined by its (current) view.

In this  section we will use the abbreviation “view” instead of more precise “View sub-class”.

There exists a view repository where the origins of some (ready-made, debugged and “approved”) views reside.  The location of the repository is defined by URL in the field Default.viewRepository.

Views included into the repository are called the registered views, and are always usable. In addition, users may easily add, develop and debug/try new views.  So, in general, all registered views and a number of non-registered (user-made) views are available at a time. For the purpose of restricting the set of current views, each of the registered views (except the basic view called the Sketchy view) is allowed to be deactivated (and activated later again, if necessary).  Non-registered views can be removed but not deactivated. Adding/removing of (non-registered ) views is possible only in LIFO manner. 

 

View names

All Java identifiers are allowed except “KONST”. For any two names v, w the condition

! v.toUperCase().equals(w.toUpperCase())

must hold.


Set scheme view

Select a scheme. Menu command View->Set displays the list of all currently active views. After selecting one of the list items, the selected scheme (and all of its sub-schemes) will be assigned to this view.

 

Base Languages

Every scheme is assigned to a base language (represented by a sub-class of the class BaseLanguage) from the set of possible ones.
The base language methods perform various conversions of schemes (skm-texts). These conversions are invoked from the Tools menu. As a rule, base language denotes a plain text language, which structured skm-texts are converted from or to. 
For instance, if current plain skm-text psk is assigned to base language bl, then the menu command
Tools->Sketchify invokes bl.sketchify method which transforms psk into a schematic skm-text  sk according to a certain conversion model.  The resulting skm-text sk appears in a new frame. The opposite conversion (sk to psk) is performed by Tools->Textualize.
The system provides several “standard” (registered) base languages, namely Java, LaTeX, ParseTree, None, JavaCC, Java5, LPN, Family. In particular, None stands for empty (missing, undefined) base language. The base language LPN is included just for tutoring purposes.

The plain texts in LPN are just forests written in so-called left parentheses notation. The latter is characterized by the grammar:

            s ::= forestLPN

           forestLPN ::= “(“   treeLPN    (“,”  treeLPN)*    “) “

           treeLPN ::= root [forestLPN]

           root ::= IDENIFIER

The following forest



written in LPN:    (A(B,C(D,E),F),X(Y))

Tree-like structures have straight representations as structured skm-texts. For instance, one particular representation (narrative) could be:
A tree is represented by a sketch which head contains the root and (single) branch contains all sub-trees (as sketches) of the tree; any forest is represented by a branch.
According to this model, the sample tree above will be represented by the following skm-text:


Another particular representation could be formulated (narrative) as follows:
A tree is represented by a sketch which single branch contains the root (as  a primitive member) and all sub-trees (as sketches) of the tree; any forest is a sequence of sub-trees (sketches).
According to this second model, the sample tree above will be represented by the following skm-text:







A conversion model for a base language L establishes how texts in L are mapped to structured skm-texts. In the case of LPN, such model could be expressed (narrative) as follows.

 A tree (treeLPN) is represented by a sketch which head contains the root (IDENTIFIER) and (single) branch contains all sub-trees (as sketches) of the tree; any forest (forestLPN) is represented by a branch.


Add new base language