An Eclipse based GUI for Scilab

Yves Neisius

December 13, 2007

1

ContentsExecutive Summary 4

Section 1: Interface 5

Interface windows 5History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Current Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Prototype implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Current Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Prototype implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

File browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Current Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Prototype implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Current Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Prototype implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Scilab interface for Java 8Prototype implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Plugin Activation 9Prototype implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Unimplemented features 9Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10GEF to implement Scicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11RCP to have a independent application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Conclusions 12Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Scilab Java interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Split the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Java developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13history, workspace, file browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Java command parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Scicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Section 2: Architecture 14

Plugin.xml 14Plugin information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Source Code 15GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Editors and views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Activator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17JavaSciWrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Internal connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2

Annex 19

Eclipse 19

3

Executive SummaryThe graphical user interface(GUI) of Scilab is dated and unusable by modern standards. In order to showhow a modern Scilab GUI should look, a Scilab plugin for Eclipse was implemented. This plugin has thelook and feel of Eclipse and its main features are inspired by Matlab.

As Eclipse has become a standard for GUI development, such plugins are readily accepted as GUIsolutions. The implemented plugin shows some of the features and the standards that the Scilab GUIshould integrate. The paper also details future work that can and should be done.

• Scilab needs a good interface in order to be more accessible to its users.This GUI includes, at theleast, a console view, a workspace view, a history view, and a file browser.

• Eclipse is an e!ective way to implement the Scilab GUI. It can be used for all required Scilabfeatures and can handle almost every SWT Widget. For instance, Scilab can directly adapt anduse the Eclipse help engine without any coding and Scicos can be integrated into Eclipse.

• The Eclipse plugin described is fully functional on a basic level. In order to advance beyond thispoint, a proper connection between Scilab and Java must be documented and implemented.

• Scilab needs to be split up into a mathematical back-end and a user front-end. A Java/Eclipsedeveloper should work on the GUI and be isolated from the technical back-end. In order for thefront-end/back-end connection to work properly, a Scilab command parser needs to be written forJava.

4

Section 1: InterfaceInterface windows

HistoryThe history keeps previously executed commands handy so the user can easily examine and reuse com-mands.

Current Status

Scilab has implemented a history, but its usage is limited:

• Scrolling through previous commands (with up/down arrows) is possible, but contextual scrolling–showing only the commands that start with a specified string– isn’t.

• The Scilab history is accessed by typing gethistory(), the result of this function is displayed inthe console window. This makes it di"cult for a user to e"ciently find previous commands.

• A history search is possible, but only the first occurrence of a match is shown. Obviously, the searchfunction could be more powerful.

• Commands shown in history cannot be directly executed in the terminal, but instead must be copiedand then pasted.

Prototype implementation

The history is implemented in a separate widget. This widget shows all the commands that whereexecuted by the user. One part of the commands was executed in Scilab itself and the other part wasexecuted in the Eclipse plugin. Those commands are automatically read when the plugin is started. Thecommands are shown in a list that can be scrolled by the user. When the user double clicks a commandthan it is pasted into the console. At this moment the user can modify the command before executing it.On every execution of a command the history widget is updated. The history can also be searched. The

5

search function selects all the commands that have any part matching the search pattern and sets thefocus on the first occurrence. Non-matching commands are still visible in the history in order the showthe context of the highlighted commands.

The main problem with the current history implementation is the need to keep two di!erent historyfiles, one in Scilab and one in the GUI. This makes the management of the history di"cult, but is currentlyunavoidable due to the fact that a Java application cannot add lines directly to the Scilab history.

WorkspaceThe workspace is the collection of user-defined variables. These variables always have a value and type,for instance integer, real, complex, matrix, character, string, etc... They can also have more exotic typessuch as function. The workspace window shows the user all the variables that are currently assigned inthe workspace, along with their current value and type.

Current Status

• The user must type who or whos in the Scilab console in order to see the current variables. Scilabreturns variables to the console, butare not only the user variables but also internal variables usedby Scilab: %pi, home, and Scilab for instance. These variables are not relevant to the user andclutter up the workspace list.

• In order to see the content of a variable its the name must be typed into the console.

• The size of a matrix is shown with the size() function.

• The type of a variable is shown with the type() function which returns the type code of the variable.

• All these functions must be executed to get the information about the current Scilab workspace.For every variable the di!erent steps must be repeated. It is di"cult for the user to get an overviewof the current workspace.

Prototype implementation

A workspace widget was implemented in the

Figure 1: Workspace Window

plugin. This widget contains a table that showsthe user-defined variables. Every variable’s name,value, type, and size is shown. The type is shownin plain text. The size shows how many elementsthe variable has, e.g. if the variable is a matrixwith a height of 2 and a width of 3 the size shows2x3. For a single element variable the size is 1x1.

It is also possible to hide workspace columns.This is done by checking the columns to show inthe popup menu of the table.The SWT Table givealso the possibility to move the columns and resize

them, although by default every column is of the same width. In addition every columns can be sortedby ascending or descending order.

The workspace is automatically updated after every command execution.• At the moment, for matrices only the value in cell (1,1) is displayed.

• The value of functions is not shown because there is no format for doing so.

• It is possible to show distinct icons for the di!erent types. This feature was disabled becausecurrently there are no icons ready.

• The most important problem is to get the user variables. The only way to get the Scilab variablesis by the who function. However this function returns all the variables: both system and user.At the moment the variables are filtered based on whether the variable was in the workspace whenthe plugin was run. The assumption is that these variables are system variables and can thus behidden. This is however not very reliable because system variables may occur dynamically at timesother than startup. For instance when a plot is shown two new variables are added to the workspaceand thus appear in the window.

6

• Another problem is an asynchronous crash of Xlib. This crash occurs always when two threads tryto access the Xlib library, which is used to draw plots. When a plot command is executed a newwindow is opened that contains the diagram. The plot creates new Scilab variables that are used byXlib. In parallel the workspace is updated after every command. It tries to read the variables thatwere created by the plot, which means that Xlib and the workspace are accessing those variablesin parallel. This parallel access is not permitted by Xlib and will cause a crash of the Java VirtualMachine (JVM).The problem was solved by implementing a Java semaphore that prevents the workspace fromupdating during a plot command. The plot variables will only appear in the workspace windowafter the next command is entered.

File browserScilab has the ability to access and navigate the O/S file system. A file browser allows graphically presentsthe file system structure so users can find files, scripts, images, etc.

Current Status

• In order to run such a script file the user need to type exec("/foo/bar.sce"), where /foo/bar/script.sceis the path and file name.

• Common unix file system commands such as ls and cd are available, e.g. cd /foo/bar/, where/foo/bar/ is the directory path.

• This approach is impractical as the user must always type the complete file path.

Prototype implementation

A file browser widget was implemented in the plugin. This widget is a SWT Tree which shows a classicfile system tree view. The folders can be expanded or collapsed. When the user has found a file, it canbe selected which will send the command exec("/foo/bar/script.sce") with the absolute file path tothe console. If he double click’s on the file the command cd /foo/bar/ is sent to the console. This letsthe user execute a script or change the directory of Scilab without having to type the directory path.

While a user can change the tree’s root directory for ease of use, this change is not done automaticallywhen a cd /foo/bar/ command is executed from the console.

ConsoleThe console is the central interface between the user and a mathematical program. The user can typecommands in the console and execute them. If desired, the console can show the results of the command.

Current Status

• The user needs to know all the commands with the exact spelling in order to execute them.

• Mathematical functions can be written. However they are written in normal text format whichmakes it di"cult to read them.

• One single commands can be composed of di!erent functions overy many lines. This sometimesleads to lenghty commands that do not fit well in the window, which makes reading di"cult.

• The console is blocked when Scicos runs.

• As described above, the up/down arrow keys can be used to cycle though the history but contextualscrolling is impossible. In the event that multiple identical commands have been executed in a row,each instance of the command must be cycled through.

7

Prototype implementation

The prototype console only has some of the original features. This is due to the complexity and thenumber of functions that the console possesses, which are not easily interfaced externally, i.e. from a javaplugin. A proper implementation of all the Scilab console functions must wait for a better Java-Scilablink.

Commands are typed in the lower text field of the console and the return key executes them. Theexecuted commands are shown along with thir results in the upper text field of the console. Commandsare shown in blue, results in black, and errors in red. The formatting of the results is similar to the classicScilab console’s formatting. The upper text field of the console can scroll to view results that have beenpushed o! the screen.

Every command that is executed is added to the history and any changes made to the Scilab variablesare shown in the workspace.

As before, the up/down arrow keys are used to cycle though the history but now contextual scrollingis implemented. If a string is first entered by the user before using the arrows, only the history commandthat begin with this string are shown. In the event that multiple identical commands have been executedin a row, the console returns only one instance of the identical commands before cycling to the nextcommand.

• The normal way to execute commands is with the string("command") function. But this functiondoes not work for every command. For instance an assignment will not work in the string("command")function. The problematic commands are assignments, clears, executions, formatting commands,mulit lines commands, scripts, plots, Scicos and navigational commands.

Scilab interface for JavaThe interface to the Scilab engine is the most important part of the Eclipse plugin, it makes the connectionbetween the plugin and the Scilab engine.

Prototype implementationAt the moment the the interface is based on shared variables between Scilab and Java. Those variablescan be uses in Java and in Scilab. They can be modified by Scilab command like gethistory() and

8

they can be modified in Java. In order to get a result from the Scilab engine it needs to be convertedinto string and assigned to a shared variable. This can be done with the following command sharedvariable = string("command") .

A wrapper class was written that manages all the calls to the Scilab engine. This wrapper class isfully synchronized and should prevent concurrent access to the Scilab engine. However the problem ofScilab crashes is still not totally solved.

• A problem with the current interface is the leak of concurrence management. If two current requestsare send to the Scilab engine it may block or crash.

• A crash in the Scilab engine will result in an Eclipse crash. There is no possibility the recover theplugin or restart the Scilab engine. This makes it very di"cult to debug the plugin.

Plugin ActivationA Eclipse perspective is a group of views that form an application. All the views that are implementedin this plugin are grouped in the Scilab perspective. When a perspective is started it opens the viewsand places them on there positions.

Prototype implementationAt the moment the history is placed at the left side of the console and the workspace as well as thefile browser are placed at the right side of the console. This may not be the optimal solution but theplacement can be easily changed by the user due to the build in feature of Eclipse. This user made changewill be consistent over time.

• When the Scilab perspective is started it needs also to start the console. As the console is an editorthis causes problems. The editor are not meant to be opened at the start up of a perspective. Thisdesign chose of Eclipse can be explained with the fact that Eclipse normally works with projects.A project is generally composed of a multitude of files, like a Java project. Those files are openedby the user.However the console is not started by the user. This task is accomplished by the views at themoment of data initialization. This is due to the possibility that a view can be opened without aperspective. However any Scilab view will always need the console.

• The design of a plugin that is composed of multiple components makes it necessary to have acentral object that manages the start up and the closing of the plugin. This object is calledActivator. However the current access on the Activator generates may concurrency problems.Those problems were solved with the synchronization of the methods. Furthermore the requestfor a Scilab connection of the di!erent views is not treated directly but with a certain delay. Thisdelay can be seen when the plugin starts the data are only show a few seconds after the views areshown. This delay is the time that is needed by the Scilab engine to load it libraries and treatthe initialization requests of the history and the workspace. The results are saved in Java datastructures (Vectors) in order to reduce the access time to the data by the views.This access time is critical as the Eclipse engine does not tolerate views that are blocked.Thisblocking would be interpreted by the Eclipse engine as a crash due to internal timeouts. Whichwould lead to an partially loaded plugin that is not usable. In order to solve this problem thewidgets were decoupling the Scilab engine. The widgets are started independently and in parallelthe Scilab initializations.

• A fourth problem is the complete blocking of the Scilab engine at the time of initialization whichmay occur randomly. This leads to a complete blocking of the plugin.

Unimplemented features

Frontend• The undo function

9

The undo function is well-known in the computing world, but it poses some special problems intechnical computing. Normally, an undo function would save the state or the most recent modi-fications into RAM after every action. However, this is unworkable as Scilab is capable of havingincredibly large objects in memory, such as uncompressed image files or large 1,000,000x1,000,000matrices. Moreover, what would happen in a loop or script where there are thousands, if not tensof thousands or even millions, of commands? Clearly, it simply is impractical to save the state atthe end of every command.It is unclear whether this function is necessary as the history would normally allow a user tocompletely recreate any state as long as the initial variables were the same. Still, we can imaginescenarios where an undo function would come in handy, such as accidentally clearing the workspacewhen only one variable was intended to be cleared, or reassigning a matrix that was computationallyexpensive to create.We determined that the best way to implement an undo function would be by saving the workspaceinfrequently, every 10-15 minutes, depending on memory requirements, and then timestampingall commands so the user could in e!ect roll back the clock to an earlier state by choosing astarting point and then redoing all the commands up to the desired moment. In most developmentcircumstances, 10-15 minutes of user time will be no more than a few seconds of computer time sothe user will not have to wait unreasonable amounts of time.This approach also has some problems, as it provides no way of insuring that data from an outsidesource is the same data as before. For instance, if a script involved a call to a data acquisitionboard, then obviously the data would not be the same as the first time. However, in spite of theseproblems, we think this approach is still the best, and is certainly one of the easiest to implementrapidly and reliably.

• auto completion / auto extensionAuto completion is one of the most interesting features that might be implemented. Eclipse has anauto completion system integrated. This system could be used to realize a Scilab auto completionbased on the "Ctrl + Space" keys. In order to implement this an analyzes of the auto completionsystem of Eclipse must be done. Furthermore a list of command must be created and inserted inthe auto completion system of Eclipse.

• command highlightingExperimented users of Scilab mostly use an Editor to write the Scilab scripts. Such an editor couldeasily be implemented in Eclipse. The command highlighting is an integrates part of the EclipseEditors. This highlighting can also be used on the commands typed in the console and in thehistory. The Eclipse customer editor system needs to be explored.

• pretty printThe pretty print is used to show the Scilab functions in a more adapted way. It should be possibleto show the fractions with a fraction bar as well as the exponents as a small number above theconcerned number. There are also other mathematical writings that might be interesting. The goalis not to present the function in a absolute correct mathematical form but to help the user to writefunctions. The system can be implemented as a separate widget. This widget will contain a fieldwhere the user can write the Scilab command. When he has finished he hits a button and the wellformatted formula is shown in an other field of that widget. If the command is correct the user cantransfer it to the console or eventually to the editor.

Backend• user variables

In order to be able to show only the user variables a Scilab function needs to be created thatreturns them. At the moment this is done by the who function. However this function returns allthe variables including the Scilab variables. It is possible to filter some of them by their names butthere might dynamically occur new Scilab variables. So a who_user function is needed that onlyreturns the variables that where assigned by the user.

• Java history access

10

It must be possible for a GUI developer to add new elements to the Scilab history. The commandsthat are executed in Java are not inserted into the Scilab history at the moment. So a functionneeds to be created that gives the GUI developer the possibility to insert strings into the Scilabhistory. Furthermore a system needs to be setup that decibels how the timestamping in the Scilabhistory functions works. The developer needs to know how the timestamp must look like and whenand how he must insert them. For instance the timestamps are inserted at the start up and theclosing of the Scilab plugin. Furthermore they would contain the same information then the normaltimestamps with in addition the string "plugin".

• Plot and ScicosAn other important point is the plot and Scicos execution. At the moment the plot is done in aseparate thread and Scicos does not work at all. Furthermore this is only possible in the consolenot in scripts. It is necessary that the plot and Scicos can be executed in the same way than normalcommands. The event loops need to be automatically managed by the Scilab engine.

• The execution of commandsAt the moment the result of the commands are returned over shared variables and the string()function. However this function has many exceptions that do not work. So either those exceptionsmust be integrated into the string() function or at least they must be well documented. Thisdocumentation would not only include the description of the problem but also a solution to it. Another possibility would be to return directly the normal Scilab value after execution. With thissolution special attention needs the be brought to the return format. This must be a standardformat for all the Scilab function. The simplest would be a two dimensional array of strings.

• Plugin stabilityThe stability of the plugin was already much improved by implementing a central wrapper classthat is fully synchronized. This class could become a part of the Scilab to Java interface. TheScilab consortium could develop this idea in more detail and test some functions. The idea wouldbe to write a tutorial for developers who wants to add there own functions in the wrapper class.The main goal of this tutorial would be to show how new methods need to be implemented in orderto achieve the maximal stability.At the moment the problems can not be properly located. Solving them could involve changingthe plugin source code or the Scilab code. As Eclipse is heavily multi threaded there might beproblems due to the leak of thread control in the Scilab engine. In the end some way must betaught up that will allow the Java developer to know if the problem comes from the Scilab side orthe Eclipse side. This could be achieved by a log file system. Those log files must show in whatstate the Scilab engine is and how it got there. Additionally the log files must be well documentedand comprehensible for a foreign developer.

• command filteringUnfortunately the commands need to filtered in order to treat them right. This is due to the factthat no standard way exists to execute the commands. If this problem is solved there will be noneed for command filtering. But until then the filtering is necessary. The filter must allow thedeveloper to extract certain commands out of scripts and allow the categorization of commands.So that the every command an specific way of execution can be implemented.

GEF to implement ScicosGEF is the Graphical Editing Framework for Eclipse. It is closely related to Eclipse. Every major versionof Eclipse involves also a new version of GEF. It is a stable framework that is downward compatible toolder versions. It can be used to show graphs. This makes it interesting in order to implement Scicos.GEF is mature and many open source examples exists. A good example for the use of GEF is an opensource project is BrainBox. BrainBox is implemented as a RCP and its use is similar to Scicos. It wouldbe a good starting point for anyone who wants to pursue this track.

GEF has some interesting build in features. The edges of the graph can be routed with di!erentalgorithms that are easy to implement in Eclipse. Such a widget could be run in a parallel tab with theconsole and an editor.

The main programming idea of GEF is that every object has its own class that describes its graphicalappearance. Furthermore the classes contain the data that are linked to that object. Those data can

11

be functions or constants or code snippets. The di!erent objects are linked with edges. Those links aresaved in a graph that contains the objects.

RCP to have a independent applicationThe Rich Client Platform concept is one of the big advantages of Eclipse. It gives the developer thepossibility to create a stand alone application from any Eclipse plugin.

Eclipse itself is a RCP application. An RCP application is composed a platform and some plugins.The platform is able to run the plugins and the plugins define the behavior of the application. So Eclipseis defined by a set of plugins.

The Scilab plugin needs some Eclipse plugins to work. However it only needs a subset of the Eclipseplugins. In a RCP application only the plugins that are really needed are incorporated in the application.This makes an RCP application smaller in size and faster in loading as not all the plugins need to beloaded. Furthermore the menus and toolbars can be customized in a stronger way than it is possible fora plugin.

Eclipse build in ability to create RCP applications needs some additional configurations. For instancethe required plugins must be identified. The most delicate part in the creation of a Scilab RCP will bethe connection to the Scilab engine.

Conclusions

EclipseThe Eclipse GUI is nicely designed and gives the user the freedom to place the features as he likes. Everyfeatures has its own widget. The user can decided which widget to show. Eclipse is a standard for GUIsdevelopment. It is flexible, stable, and its use is intuitive.

The Eclipse architecture makes it easy to add new features. Almost every SWT application can befitted to work under Eclipse. The modification to be done are well documented. Further Eclipse putsabstract classes to the disposal of the developers. Those classes implement already the default behavior.Which makes it easy to get started.

The plugin can be run as part of a normal Eclipse or a minimal Eclipse of about 35 megabyte.Furthermore the plugin can be part of a so called Rich Client Platform(RCP) application. A RCPapplication is a standalone application that contains only the Eclipse elements that are required by theplugin. An RCP can be further customized and is smaller than a copy of Eclipse with a plugin.

In the end the Eclipse project is base on well known design patterns and good programming practices.This is very important especially for the GUI domain.

The developers can create a GUI with the look and feel of Eclipse. This is interesting as Eclipse isused by many people in various domains. Java, C, C++ development, Latex editor, download manager...Many Eclipse users check first if some free Eclipse plugin exists for there needs.

Scilab Java interfaceModern GUI are partly developed by volunteers. This is even more the case for open source projects. Inorder to be attractive for those GUI developers a good API is needed. Those developers do not worryabout the mathematical engine. They use Scilab as a library. So it is very important to provide them agood API. The Scilab programmers are the only ones that can do this. As they are the only ones thathave enough knowledge about Scilab. This interface need to be stable and simple to use. Furthermoreit needs to be well documented. The way how and which Scilab commands can be executed needs to bediscussed.

Split the projectThe Scilab GUI is too important to be developed as an afterthought to the rest of the package. Thedevelopers most interested in mathematical coding are usually those least interested in GUI programing.The development of a GUI is time consuming and may go in a wrong direction. In order not to burdenthis part to the Scilab programmers who need to work on the mathematical side and on the interfaceside would it be the best to split the project. The GUI part of Scilab can be furnished by independentJava and/or Eclipse programmers if a good Java interface exists. This would lead to a fast developmentof interfaces in di!erent working domains(toolkits).

12

Java developersThe Java developers know the modern GUI standards. This knowledge leads to intuitive and commonlyknow designs. The Scilab consortium is to familiar with the current GUI. This leads to an improveddesign of the current GUI. However if Scilab wants to be competitive then it will need a whole newinterface. This interface can only be furnished by programmers that have no restrictions in mind.

history, workspace, file browserThis features are standard features of the competitor. Furthermore they give the user a much easieraccess to Scilab. The immersion into the application is bigger. The user has not the feeling to be leadalone with the console.

Java command parserIn order to split Scilab in a mathematical and a GUI part the commands need already to be parsed in theJava application. This is due to the fact that the graphical commands, like printf, disp are mangledwith the mathematical commands. However there is no need to bother the mathematical engine with thegraphical commands.

Furthermore the GUI can be made more e"cient with a command parser. This parser would be thebasis for auto completion and pretty print of commands. Furthermore such a parser would permit tofilter commands that need special attention, like plots.

ScicosFor Eclipse some modeling toolkits exists. Those toolkits where developed in order show graphs as theyare used in model driven programming. Those toolkits could be used to implement a Scicos visualization.

13

Section 2: ArchitectureThe architecture of this prototype is very clear this is due to the following facts.

• First Eclipse is a framework and in opposition to a simple library it demands to respect certainarchitectural aspects.

• Second this prototype does not only intend to show how a modern GUI for Scilab should look like,but it also shows how a Eclipse plugin should look like.

Eclipse is an open source project that can fit for many di!erent purposes. Mainly the development ofGUI’s is simplified by this framework. This simplification is achieved by build in features and by goodprogramming practices. Those good practices are illustrated in examples that can be found on the Eclipsehomepage.

Plugin.xmlAn Eclipse plugin is not only defined by its source code, it needs also configuration files. Every Eclipseplugin has a plugin.xml configuration file in its root directory. This is the first file that is read whena plugin is loaded into Eclipse. It is the central point that is used by Eclipse to integrate the di!erentviews, editors, help content, perspectives...

Plugin informationFirst of all the plugin.xml contains the xml encoding and the version of Eclipse that it needs. Than thename, the id and the version of the plugin follows. The id is a unique string that identifies the plugin. Itcan have a hierarchical structure similar to a domain name. Every plugin needs to specify an Activatorclass. The activator is the class that is used when the plugin starts.

DependenciesAn other important information that can be found in the this file is the requirements. Eclipse is acombination of RCP plugins. Between those plugins some dependencies may occur. Those dependenciesare specified in the required section. This can be compared to the build path of a normal Java application.In fact it is important not to use the build path for a plugin because the build path will only work onthe local machine.

ExtensionsAs Eclipse is the framework the widgets that are written needs to hook onto the platform. Those hookpoints are called extensions points. The most important extension points are the views and the editors.The views are defined by there name, id and the path to the class that implements the view. Furthermorea category may be specified to indicate where the link to the view will be shown. In Eclipse the viewscan be started under Window->showView->other. There all the views that are available can be foundunder there respective categories. The Editors are defined similar to the views. They extend editors butthey do not have a category because they can not be directly opened by a user. The editors are meant tobe opens with a file. As in our case there are no files the extensions attribute is set to "". This meansthat no file is opened with this editor.

PerspectiveThe primary way to start a plugin is to switch to its perspective. The perspective will open all the viewsthat form the Scilab plugin. The perspectives can be found under Window->perspectives->other. Aperspective is defined by its name, id and the perspective class.

14

HelpOne feature of Eclipse that needs not source code at all is the help. New help content can be added withoutprogramming it. The content needs to be written in HTML. The place where the di!erent HTML pagesare inserted in the help is defined in a second xml file. However this file needs to be specified in theplugin.xml under the extension point org.Eclipse.help.toc. The content that is added to the help willbe shown in the structure of the Eclipse help. It can be searched by the help search engine. This enginewill search automatically the content of all the help files that are inserted.

As you can see the main element of a Eclipse plugin is the plugin.xml. It defines how the source codewill interact with the platform. The plugin.xml must be respected. Everything that can be defined inthis file should be defined here. Eclipse programming is a combination of source code and configurationfiles.

Source CodeEven if the plugin.xml is the central object to manage the plugin the biggest part of the work is the Javasource code. But also here Eclipse gives a frame that needs to be respected. The requirements of a pluginare divides in the following parts.

• The structure of the plugin.

• The implementation of Eclipse interfaces and abstract classes.

• The respect of good programming practices.

The following diagram shows the structure of the Scilab plugin. However this structure can be used as atemplate for any Eclipse plugin.

15

The greed part contains the actual GUI which consists of SWT source code with its connection toEclipse.

The red part contains the plugins behavior on start up.The blue part contains the connection to the Scilab engine.The two black boxes contain the connection between the Scilab engine and the GUI.

GUI

Editors and viewsThe Eclipse GUI is composed of physically independent part. As of every GUI the upper space containsthe menu and the toolbar. The main space however is divided among di!erent widgets. Those widgetscan be moved, resized, put into a separate windows, opened and closed separately. There exist twocategories of widgets: the editors and the views.

The editor is the center of and Eclipse plugin. It contains some text that is edited by the user.Historically the editor was used to edit Java source code files. This is why today the editors are openedin connection with a file type.

The views are used to put additional features at the disposal of the user. For instance a packagemanager that shows all the files in a Java project. Or a outline view that show the methods of a Javaclass. The views can be opened by the user.

SWT The di!erent widget can be developed as normal SWT applications. For every part of the GUI aseparate widget class needs to be implemented. It would for instance technically be possible to implementthe history and the workspace in a single class. However this would have for consequence that Eclipsecould not manage them separately and the user must always open the two features. In the diagram theupper four classes represent the SWT implementation of the console, file browser, history and workspace.

Connection with Eclipse The Widgets need to be instantiated and initialized by some mean. Thisis done by Eclipse with the help of the plugin.xml. However the plugin.xml does not interact directlywith the SWT widgets. Eclipse requires classes that implements the IEditorPart interface for an editoror the IViewPart interface for a view. In order to make it simpler to implement those interfaces Eclipseputs abstract classes at the disposal of the developers.

The EditorPart and the ViewPart are those abstract classes. They already implement the interfacesto a certain extend. The user still need to furnish some implementation but the new requests are simplerto understand. The EditorPart and the ViewPart implement the default behavior of the IEditorPartand the IViewPart.

For instance the IViewPart interface needs the following methods to be implemented

• getViewSite()

16

• init(ViewSite)

• init(ViewSite, IMemento)

• saveState(IMemento)

The abstract ViewPart however only needs

• createPartControl(Composit) It creates the widget and sets it into the Composit frame, whichexplains why the Widgets need to extend Composit.

• setFocus() It defines what happens when the focus is given to the widget.

• dispose() It defines what happens when the widget is closed.

The in order to implement the interface a deep understanding of the Eclipse engine is required. As for theabstract class the general understanding of GUIs is su"cient. If a developer wants to implement thoseinterface on its own he has to make sure he uses the Eclipse programming practices and respects all itsneeds.

The console is an editor because it is the central part of the plugin. An editor is an Eclipse definitionof a SWT widget that is meant to edit files. This leads to save and load methods that are needed inaddition to a view. However those methods are not used in Scilab as the Scilab console has not directsource files that need to be edited.

This makes an EditorInput necessary. A EditorInput is the description of an Input else than afile. The most impotent part in such an input is the equal method. This method is used to check ifan editor has the same input than an other editor. This check is needed when an editor is requested.For instance when the history wants to send a command to the console it will need the instance of theconsole. The instances of all the editors and views are managed by the Eclipse engine. Eclipse will searchall the already opened editors in order to find an instance of the Console editor. If it cannot find anyopen instance it will open a new one. However if it finds one it will check the inputs of the alreadyopened instances. If its input is the same as in the requested it will pass this editor back. In our casethe equal method of the EditorInput checks only if the inputs are of the same type. This means thatall the requests for a console will either create a new console or return the already opened console. Thisway Eclipse makes sure to have only opened each file once.

Activator

An other big issue of a Eclipse plugin is the start. As already said a plugin is composed of di!erentviews and editor which work independently from each other. So there is no central object that existsduring the whole life cycle of the plugin. This is why Eclipse has an AbstractUIPlugin class. It is imple-mented by a class that is usually called Activator. Its methods are start(), stop(), and getDefault().They are executed then the plugin starts, stops and when the Activator is requested.

In our case however the Activator is more complex. This is due to the fact that we work with Scilab.Scilab is interfaced to Java via the JNI interface. Those so called native calls use the native Scilab enginewhich is written in C. When a first command is send to the Scilab engine it needs to be initialized first.This means that the Scilab libraries need to be read from the hard disk and loaded into the memory.This takes a considerable among of time. This takes even more time when it happens in parallel with thestart of the Eclipse plugin.

This does not only slow down the start but it can also crash the plugin. If a view needs to be initializedwith Scilab content at the start of the plugin. For instance the Scilab history need to be initialized. Itwill be blocked until the Scilab call has finished. However the Eclipse engine will not tolerate a blocked

17

view and after a certain timeout it will try to stop this action. This leads to a undefined state of theScilab interface and the Eclipse engine. Eclipse many load partially or block totally. The start up ofEclipse is a delicate time.

The views and editors must not block at this time. The blocking can occur due the native code accessbut also due to access onto functions that are not jet loaded. For instance the getStateLocation()function returns the path to the working directory of he plugin. If this function is executed in theconstructor of the Activator it might fail as the required information does not yet exists. This failuremight block the widgets.

JavaSciWrapper

A major problem that may occur is the parallel access to the Scilab engine. As every widget hasits own thread concurrent access is likely to occur. The initial Java to Scilab interface did not manageconcurrent access. Nor the Java code nor the Scilab code had a way to manage such situations. Forinstance when the history and the workspace were updated the Scilab functions were accessed in parallel.In order to prevent those situations some implementation choices where taken.

First of all a wrapper class was created. This class groups all the possible calls from the pluginto the Scilab engine. This prevents calls from multiple treads as every widget has its own. The his-tory calls the loadHistory and the getHistory, the console calls the exec methods and the workspaceloadSciWorkspace and the getWorkspace methods. Those are also the most important methods of theWrapper. All of them are synchronized to prevent concurrent access.

Those methods executes all the Scilab commands that are necessary for the di!erent operations. Theworkspace and history methods are split in two parts. The actual execution and the getter to access theresults. This is done to prevent the widgets from waiting until the call to the Scilab engine is finished.The actual execution is done in the load methods where the results are saved .The getter only returnsthe saved values. This way it is easy to share the results. For instance the history is used by the historywidget and also by the console when the up and down arrows are pressed.

The detailed implementation of the of those methods is a result of the Scilab interface. The currentinterface is very limited. The default way to execute a Scilab command for Java is to have a sharedvariable between Java and Scilab. With a Scilab command shared variable = string("command")the result of the of the command is passed to the shared variable. Through the shared variable the resultcan be accessed. This way does unfortunately not work for all the commands.

Assignments, multilined functions, scripts, clear variables, plots, formatting functions and file systemnavigation does not work. There are certainly other exceptions. Those exceptions must be treated inunique ways. For instance the multilined commands are temporarily saved in a file and executed like anormal script.

The plot function is even more complicated. It leaded to the implementation of a new plot class. Theplot runs in a separate thread in order to start the GTK plot. However the coexistence of GTK andJava is not trivial. The GTK may only be controlled by a single thread. This means that when a plotwas launched once it need to be controlled by the same thread as long as the Scilab libraries run. Else aasynchronous Xlib error may occur. An other consequence of the fact that not two di!erent threads mayaccess the Xlib is an error produced by the workspace.

This error occurs during the update after a plot function is called. As the plot creates variables andthe workspace accesses those variables two threads access the plot variables and the Xlib crashes. At themoment the error is solved by a Java semaphore. This semaphore prevents the workspace to be updatedwhile a plot is active. This error shows the limits of the concurrency control only based on the Java level.The Java developer should able to concentrate only on the GUI.

18

Internal connection

The last part of the architecture is the connections between the Activator and the widgets and theJavaSciWrapper and the widgets. This connection uses listeners. The WrapperReciever interface isused to connect the Activator with the workspace, the history and the console at the time of start up ofthe plugin. As already described the start up of the plugin is a very delicate time. The Widgets mustnot block. This is achieved by the recieveWrapper mechanism. The Widgets executes the getWrappermethod of the Activator during there creation. This method will check if a wrapper already exists. Ifit is the case the wrapper is directly returned by executing the recieveWrapper method of the callingwidget. However if the wrapper does not exist yet the requesting widget is saved in a Vector and theJavaSciWrapper is created in a separate thread. This separate thread prevents the method from block-ing. Furthermore will it create the wrapper and execute the loadHistory and the loadSciWorksapcemethods. Those methods need the Scilab engine and will take some time. Then the thread has finishedthe recieveWrapper methods of the widget that are saved in the Vector are executed. They will thantake the data from the wrapper to initialized them self’s.

Furthermore they add them self as listener to the wrapper where they are stored in the ObserverVector. This leads to the connection between the wrapper and widgets. Always when the exec methodof the wrapper is executed the history and the workspace are updated. This is done by executing theupdate methods of all the objects in the Observer Vector.

AnnexEclipseEclipse is an IDE that was design to help Java developers to write their source code. It possesses manyinteresting and useful features: the package browser, the outline, the auto compile, the auto correct andthe debugger only to cite the most important. Furthermore the whole graphical environment is nicelydesigned and gives the user the freedom to place the features as he likes. The user can decided withwidget to show. However now Eclipse is much more than only a Java IDE.

Eclipse is an open-source, platform-independent software framework, written primarily in Java, fordelivering what the project calls "rich-client applications", as opposed to "thin client" browser-basedapplications. So far this framework has typically been used to develop Integrated Development Environ-

19

ments (IDEs), such as the Java IDE called Java Development Toolkit (JDT) and compiler (ECJ) thatcomes as part of Eclipse (and which are also used to develop Eclipse itself). However, it can be used forother types of client application as well.

Eclipse is also a community of users, constantly extending the covered application areas. An exampleis the recently created Eclipse Modeling Project, covering most areas of Model Driven Engineering.

Eclipse was originally developed by IBM as the successor to its VisualAge family of tools. It isnow managed by the Eclipse Foundation, an independent not-for-profit consortium of software industryvendors. Many software tool vendors have embraced Eclipse as a future framework for their IDEs.

The basis for Eclipse is the Rich Client Platform (RCP). The following components constitute therich client platform:

* Core platform - boot Eclipse, run plug-ins* OSGi - a standard bundling framework* the Standard Widget Toolkit (SWT) - a portable widget toolkit* JFace - file bu!ers, text handling, text editors* The Eclipse Workbench - views, editors, perspectives, wizardsEclipse’s widgets are implemented by a widget toolkit for Java called SWT, unlike most Java appli-

cations, which use the Java standard Abstract Window Toolkit (AWT) or Swing. Eclipse’s user interfacealso leverages an intermediate GUI layer called JFace, which simplifies the construction of applicationsbased on SWT.

Eclipse employs plug-ins in order to provide all of its functionality on top of (and including) the richclient platform, in contrast to some other applications where functionality is typically hard coded. Thisplug-in mechanism is a lightweight software componentry framework. In addition to allowing Eclipseto be extended using other programming languages such as C and Python, the plug-in framework al-lows Eclipse to work with typesetting languages like LATEX, networking applications such as telnet, anddatabase management systems. The plug-in architecture supports writing any desired extension to theenvironment, such as for configuration management. Java and CVS support is provided in the EclipseSDK. It does not have to be used solely to support other programming languages.

The Eclipse SDK includes the Eclipse Java Development Tools, o!ering an IDE with a built-in in-cremental Java compiler and a full model of the Java source files. This allows for advanced refactoringtechniques and code analysis. The IDE also makes use of a workspace, in this case a set of metadata overa flat filespace allowing external file modifications as long as the corresponding workspace "resource" isrefreshed afterwards.

Taken from Wikipedia.

20