An Eclipse based GUI for Scilab. Yves Neisius December 13, 2007

Transcription

1 An Eclipse based GUI for Scilab Yves Neisius December 13,

2 Contents Executive Summary 4 Section 1: Interface 5 Interface windows 5 History Current Status Prototype implementation Workspace Current Status Prototype implementation File browser Current Status Prototype implementation Console Current Status Prototype implementation Scilab interface for Java 8 Prototype implementation Plugin Activation 9 Prototype implementation Unimplemented features 9 Frontend Backend GEF to implement Scicos RCP to have a independent application Conclusions 12 Eclipse Scilab Java interface Split the project Java developers history, workspace, file browser Java command parser Scicos Section 2: Architecture 14 Plugin.xml 14 Plugin information Dependencies Extensions Perspective Help Source Code 15 GUI Editors and views Activator JavaSciWrapper Internal connection

3 Annex 19 Eclipse 19 3

4 Executive Summary The graphical user interface(gui) of Scilab is dated and unusable by modern standards. In order to show how a modern Scilab GUI should look, a Scilab plugin for Eclipse was implemented. This plugin has the look 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 GUI solutions. The implemented plugin shows some of the features and the standards that the Scilab GUI should 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 the least, a console view, a workspace view, a history view, and a file browser. Eclipse is an effective way to implement the Scilab GUI. It can be used for all required Scilab features and can handle almost every SWT Widget. For instance, Scilab can directly adapt and use 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 this point, 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/Eclipse developer should work on the GUI and be isolated from the technical back-end. In order for the front-end/back-end connection to work properly, a Scilab command parser needs to be written for Java. 4

5 Section 1: Interface Interface windows History The history keeps previously executed commands handy so the user can easily examine and reuse commands. 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 in the console window. This makes it difficult for a user to efficiently find previous commands. A history search is possible, but only the first occurrence of a match is shown. Obviously, the search function could be more powerful. Commands shown in history cannot be directly executed in the terminal, but instead must be copied and then pasted. Prototype implementation The history is implemented in a separate widget. This widget shows all the commands that where executed by the user. One part of the commands was executed in Scilab itself and the other part was executed in the Eclipse plugin. Those commands are automatically read when the plugin is started. The commands are shown in a list that can be scrolled by the user. When the user double clicks a command than 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

6 search function selects all the commands that have any part matching the search pattern and sets the focus on the first occurrence. Non-matching commands are still visible in the history in order the show the context of the highlighted commands. The main problem with the current history implementation is the need to keep two different history files, one in Scilab and one in the GUI. This makes the management of the history difficult, but is currently unavoidable due to the fact that a Java application cannot add lines directly to the Scilab history. Workspace The 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 types such as function. The workspace window shows the user all the variables that are currently assigned in the 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. Scilab returns variables to the console, butare not only the user variables but also internal variables used by Scilab: %pi, home, and Scilab for instance. These variables are not relevant to the user and clutter 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 different steps must be repeated. It is difficult for the user to get an overview of the current workspace. Prototype implementation A workspace widget was implemented in the plugin. This widget contains a table that shows the user-defined variables. Every variable s name, value, type, and size is shown. The type is shown in plain text. The size shows how many elements the variable has, e.g. if the variable is a matrix with a height of 2 and a width of 3 the size shows 2x3. 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 in the popup menu of the table.the SWT Table give Figure 1: Workspace Window also 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 sorted by 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 different types. currently there are no icons ready. This feature was disabled because The most important problem is to get the user variables. The only way to get the Scilab variables is 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 when the plugin was run. The assumption is that these variables are system variables and can thus be hidden. This is however not very reliable because system variables may occur dynamically at times other than startup. For instance when a plot is shown two new variables are added to the workspace and thus appear in the window. 6

7 Another problem is an asynchronous crash of Xlib. This crash occurs always when two threads try to access the Xlib library, which is used to draw plots. When a plot command is executed a new window is opened that contains the diagram. The plot creates new Scilab variables that are used by Xlib. In parallel the workspace is updated after every command. It tries to read the variables that were created by the plot, which means that Xlib and the workspace are accessing those variables in parallel. This parallel access is not permitted by Xlib and will cause a crash of the Java Virtual Machine (JVM). The problem was solved by implementing a Java semaphore that prevents the workspace from updating during a plot command. The plot variables will only appear in the workspace window after the next command is entered. File browser Scilab has the ability to access and navigate the O/S file system. A file browser allows graphically presents the 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.sce is 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 classic file system tree view. The folders can be expanded or collapsed. When the user has found a file, it can be selected which will send the command exec("/foo/bar/script.sce") with the absolute file path to the console. If he double click s on the file the command cd /foo/bar/ is sent to the console. This lets the 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 automatically when a cd /foo/bar/ command is executed from the console. Console The console is the central interface between the user and a mathematical program. The user can type commands 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 which makes it difficult to read them. One single commands can be composed of different functions overy many lines. This sometimes leads to lenghty commands that do not fit well in the window, which makes reading difficult. The console is blocked when Scicos runs. As described above, the up/down arrow keys can be used to cycle though the history but contextual scrolling 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

8 Prototype implementation The prototype console only has some of the original features. This is due to the complexity and the number of functions that the console possesses, which are not easily interfaced externally, i.e. from a java plugin. A proper implementation of all the Scilab console functions must wait for a better Java-Scilab link. Commands are typed in the lower text field of the console and the return key executes them. The executed commands are shown along with thir results in the upper text field of the console. Commands are shown in blue, results in black, and errors in red. The formatting of the results is similar to the classic Scilab console s formatting. The upper text field of the console can scroll to view results that have been pushed off the screen. Every command that is executed is added to the history and any changes made to the Scilab variables are shown in the workspace. As before, the up/down arrow keys are used to cycle though the history but now contextual scrolling is implemented. If a string is first entered by the user before using the arrows, only the history command that begin with this string are shown. In the event that multiple identical commands have been executed in a row, the console returns only one instance of the identical commands before cycling to the next command. The normal way to execute commands is with the string("command") function. But this function does 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 Java The interface to the Scilab engine is the most important part of the Eclipse plugin, it makes the connection between the plugin and the Scilab engine. Prototype implementation At the moment the the interface is based on shared variables between Scilab and Java. Those variables can be uses in Java and in Scilab. They can be modified by Scilab command like gethistory() and 8

9 they can be modified in Java. In order to get a result from the Scilab engine it needs to be converted into string and assigned to a shared variable. This can be done with the following command shared variable = string("command"). A wrapper class was written that manages all the calls to the Scilab engine. This wrapper class is fully synchronized and should prevent concurrent access to the Scilab engine. However the problem of Scilab crashes is still not totally solved. A problem with the current interface is the leak of concurrence management. If two current requests are 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 the plugin or restart the Scilab engine. This makes it very difficult to debug the plugin. Plugin Activation A Eclipse perspective is a group of views that form an application. All the views that are implemented in this plugin are grouped in the Scilab perspective. When a perspective is started it opens the views and places them on there positions. Prototype implementation At the moment the history is placed at the left side of the console and the workspace as well as the file browser are placed at the right side of the console. This may not be the optimal solution but the placement can be easily changed by the user due to the build in feature of Eclipse. This user made change will be consistent over time. When the Scilab perspective is started it needs also to start the console. As the console is an editor this causes problems. The editor are not meant to be opened at the start up of a perspective. This design 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 opened by the user. However the console is not started by the user. This task is accomplished by the views at the moment of data initialization. This is due to the possibility that a view can be opened without a perspective. 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 a central object that manages the start up and the closing of the plugin. This object is called Activator. However the current access on the Activator generates may concurrency problems. Those problems were solved with the synchronization of the methods. Furthermore the request for a Scilab connection of the different views is not treated directly but with a certain delay. This delay can be seen when the plugin starts the data are only show a few seconds after the views are shown. This delay is the time that is needed by the Scilab engine to load it libraries and treat the initialization requests of the history and the workspace. The results are saved in Java data structures (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.this blocking would be interpreted by the Eclipse engine as a crash due to internal timeouts. Which would lead to an partially loaded plugin that is not usable. In order to solve this problem the widgets were decoupling the Scilab engine. The widgets are started independently and in parallel the Scilab initializations. A fourth problem is the complete blocking of the Scilab engine at the time of initialization which may occur randomly. This leads to a complete blocking of the plugin. Unimplemented features Frontend The undo function 9

10 The undo function is well-known in the computing world, but it poses some special problems in technical computing. Normally, an undo function would save the state or the most recent modifications into RAM after every action. However, this is unworkable as Scilab is capable of having incredibly large objects in memory, such as uncompressed image files or large 1,000,000x1,000,000 matrices. Moreover, what would happen in a loop or script where there are thousands, if not tens of thousands or even millions, of commands? Clearly, it simply is impractical to save the state at the end of every command. It is unclear whether this function is necessary as the history would normally allow a user to completely recreate any state as long as the initial variables were the same. Still, we can imagine scenarios where an undo function would come in handy, such as accidentally clearing the workspace when only one variable was intended to be cleared, or reassigning a matrix that was computationally expensive to create. We determined that the best way to implement an undo function would be by saving the workspace infrequently, every minutes, depending on memory requirements, and then timestamping all commands so the user could in effect roll back the clock to an earlier state by choosing a starting point and then redoing all the commands up to the desired moment. In most development circumstances, minutes of user time will be no more than a few seconds of computer time so the 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 outside source is the same data as before. For instance, if a script involved a call to a data acquisition board, then obviously the data would not be the same as the first time. However, in spite of these problems, we think this approach is still the best, and is certainly one of the easiest to implement rapidly and reliably. auto completion / auto extension Auto completion is one of the most interesting features that might be implemented. Eclipse has an auto completion system integrated. This system could be used to realize a Scilab auto completion based on the "Ctrl + Space" keys. In order to implement this an analyzes of the auto completion system of Eclipse must be done. Furthermore a list of command must be created and inserted in the auto completion system of Eclipse. command highlighting Experimented users of Scilab mostly use an Editor to write the Scilab scripts. Such an editor could easily be implemented in Eclipse. The command highlighting is an integrates part of the Eclipse Editors. This highlighting can also be used on the commands typed in the console and in the history. The Eclipse customer editor system needs to be explored. pretty print The pretty print is used to show the Scilab functions in a more adapted way. It should be possible to show the fractions with a fraction bar as well as the exponents as a small number above the concerned number. There are also other mathematical writings that might be interesting. The goal is not to present the function in a absolute correct mathematical form but to help the user to write functions. The system can be implemented as a separate widget. This widget will contain a field where the user can write the Scilab command. When he has finished he hits a button and the well formatted formula is shown in an other field of that widget. If the command is correct the user can transfer 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 that returns them. At the moment this is done by the who function. However this function returns all the variables including the Scilab variables. It is possible to filter some of them by their names but there might dynamically occur new Scilab variables. So a who_user function is needed that only returns the variables that where assigned by the user. Java history access 10

11 It must be possible for a GUI developer to add new elements to the Scilab history. The commands that are executed in Java are not inserted into the Scilab history at the moment. So a function needs to be created that gives the GUI developer the possibility to insert strings into the Scilab history. Furthermore a system needs to be setup that decibels how the timestamping in the Scilab history functions works. The developer needs to know how the timestamp must look like and when and how he must insert them. For instance the timestamps are inserted at the start up and the closing of the Scilab plugin. Furthermore they would contain the same information then the normal timestamps with in addition the string "plugin". Plot and Scicos An other important point is the plot and Scicos execution. At the moment the plot is done in a separate thread and Scicos does not work at all. Furthermore this is only possible in the console not in scripts. It is necessary that the plot and Scicos can be executed in the same way than normal commands. The event loops need to be automatically managed by the Scilab engine. The execution of commands At 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 exceptions must be integrated into the string() function or at least they must be well documented. This documentation would not only include the description of the problem but also a solution to it. An other possibility would be to return directly the normal Scilab value after execution. With this solution special attention needs the be brought to the return format. This must be a standard format for all the Scilab function. The simplest would be a two dimensional array of strings. Plugin stability The stability of the plugin was already much improved by implementing a central wrapper class that is fully synchronized. This class could become a part of the Scilab to Java interface. The Scilab consortium could develop this idea in more detail and test some functions. The idea would be 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 order to achieve the maximal stability. At the moment the problems can not be properly located. Solving them could involve changing the plugin source code or the Scilab code. As Eclipse is heavily multi threaded there might be problems due to the leak of thread control in the Scilab engine. In the end some way must be taught up that will allow the Java developer to know if the problem comes from the Scilab side or the Eclipse side. This could be achieved by a log file system. Those log files must show in what state the Scilab engine is and how it got there. Additionally the log files must be well documented and comprehensible for a foreign developer. command filtering Unfortunately the commands need to filtered in order to treat them right. This is due to the fact that no standard way exists to execute the commands. If this problem is solved there will be no need for command filtering. But until then the filtering is necessary. The filter must allow the developer 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 Scicos GEF is the Graphical Editing Framework for Eclipse. It is closely related to Eclipse. Every major version of Eclipse involves also a new version of GEF. It is a stable framework that is downward compatible to older 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 open source project is BrainBox. BrainBox is implemented as a RCP and its use is similar to Scicos. It would be 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 different algorithms that are easy to implement in Eclipse. Such a widget could be run in a parallel tab with the console and an editor. The main programming idea of GEF is that every object has its own class that describes its graphical appearance. Furthermore the classes contain the data that are linked to that object. Those data can 11

12 be functions or constants or code snippets. The different objects are linked with edges. Those links are saved in a graph that contains the objects. RCP to have a independent application The Rich Client Platform concept is one of the big advantages of Eclipse. It gives the developer the possibility 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 Eclipse is defined by a set of plugins. The Scilab plugin needs some Eclipse plugins to work. However it only needs a subset of the Eclipse plugins. 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 be loaded. Furthermore the menus and toolbars can be customized in a stronger way than it is possible for a plugin. Eclipse build in ability to create RCP applications needs some additional configurations. For instance the required plugins must be identified. The most delicate part in the creation of a Scilab RCP will be the connection to the Scilab engine. Conclusions Eclipse The Eclipse GUI is nicely designed and gives the user the freedom to place the features as he likes. Every features has its own widget. The user can decided which widget to show. Eclipse is a standard for GUIs development. It is flexible, stable, and its use is intuitive. The Eclipse architecture makes it easy to add new features. Almost every SWT application can be fitted to work under Eclipse. The modification to be done are well documented. Further Eclipse puts abstract 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 RCP application is a standalone application that contains only the Eclipse elements that are required by the plugin. 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 is used 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 interface Modern GUI are partly developed by volunteers. This is even more the case for open source projects. In order to be attractive for those GUI developers a good API is needed. Those developers do not worry about the mathematical engine. They use Scilab as a library. So it is very important to provide them a good API. The Scilab programmers are the only ones that can do this. As they are the only ones that have enough knowledge about Scilab. This interface need to be stable and simple to use. Furthermore it needs to be well documented. The way how and which Scilab commands can be executed needs to be discussed. Split the project The Scilab GUI is too important to be developed as an afterthought to the rest of the package. The developers 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 burden this part to the Scilab programmers who need to work on the mathematical side and on the interface side would it be the best to split the project. The GUI part of Scilab can be furnished by independent Java and/or Eclipse programmers if a good Java interface exists. This would lead to a fast development of interfaces in different working domains(toolkits). 12

13 Java developers The Java developers know the modern GUI standards. This knowledge leads to intuitive and commonly know designs. The Scilab consortium is to familiar with the current GUI. This leads to an improved design of the current GUI. However if Scilab wants to be competitive then it will need a whole new interface. This interface can only be furnished by programmers that have no restrictions in mind. history, workspace, file browser This features are standard features of the competitor. Furthermore they give the user a much easier access to Scilab. The immersion into the application is bigger. The user has not the feeling to be lead alone with the console. Java command parser In order to split Scilab in a mathematical and a GUI part the commands need already to be parsed in the Java application. This is due to the fact that the graphical commands, like printf, disp are mangled with the mathematical commands. However there is no need to bother the mathematical engine with the graphical commands. Furthermore the GUI can be made more efficient with a command parser. This parser would be the basis for auto completion and pretty print of commands. Furthermore such a parser would permit to filter commands that need special attention, like plots. Scicos For Eclipse some modeling toolkits exists. Those toolkits where developed in order show graphs as they are used in model driven programming. Those toolkits could be used to implement a Scicos visualization. 13

14 Section 2: Architecture The 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 certain architectural 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 different purposes. Mainly the development of GUI s is simplified by this framework. This simplification is achieved by build in features and by good programming practices. Those good practices are illustrated in examples that can be found on the Eclipse homepage. Plugin.xml An Eclipse plugin is not only defined by its source code, it needs also configuration files. Every Eclipse plugin has a plugin.xml configuration file in its root directory. This is the first file that is read when a plugin is loaded into Eclipse. It is the central point that is used by Eclipse to integrate the different views, editors, help content, perspectives... Plugin information First of all the plugin.xml contains the xml encoding and the version of Eclipse that it needs. Than the name, the id and the version of the plugin follows. The id is a unique string that identifies the plugin. It can have a hierarchical structure similar to a domain name. Every plugin needs to specify an Activator class. The activator is the class that is used when the plugin starts. Dependencies An other important information that can be found in the this file is the requirements. Eclipse is a combination of RCP plugins. Between those plugins some dependencies may occur. Those dependencies are 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 on the local machine. Extensions As Eclipse is the framework the widgets that are written needs to hook onto the platform. Those hook points 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. Furthermore a category may be specified to indicate where the link to the view will be shown. In Eclipse the views can be started under Window->showView->other. There all the views that are available can be found under there respective categories. The Editors are defined similar to the views. They extend editors but they do not have a category because they can not be directly opened by a user. The editors are meant to be opens with a file. As in our case there are no files the extensions attribute is set to "". This means that no file is opened with this editor. Perspective The primary way to start a plugin is to switch to its perspective. The perspective will open all the views that form the Scilab plugin. The perspectives can be found under Window->perspectives->other. A perspective is defined by its name, id and the perspective class. 14

15 Help One feature of Eclipse that needs not source code at all is the help. New help content can be added without programming it. The content needs to be written in HTML. The place where the different HTML pages are inserted in the help is defined in a second xml file. However this file needs to be specified in the plugin.xml under the extension point org.eclipse.help.toc. The content that is added to the help will be shown in the structure of the Eclipse help. It can be searched by the help search engine. This engine will 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 code will interact with the platform. The plugin.xml must be respected. Everything that can be defined in this file should be defined here. Eclipse programming is a combination of source code and configuration files. Source Code Even if the plugin.xml is the central object to manage the plugin the biggest part of the work is the Java source code. But also here Eclipse gives a frame that needs to be respected. The requirements of a plugin are 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 a template for any Eclipse plugin. 15

16 The greed part contains the actual GUI which consists of SWT source code with its connection to Eclipse. 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 views The Eclipse GUI is composed of physically independent part. As of every GUI the upper space contains the menu and the toolbar. The main space however is divided among different widgets. Those widgets can be moved, resized, put into a separate windows, opened and closed separately. There exist two categories 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 opened in connection with a file type. The views are used to put additional features at the disposal of the user. For instance a package manager that shows all the files in a Java project. Or a outline view that show the methods of a Java class. The views can be opened by the user. SWT The different widget can be developed as normal SWT applications. For every part of the GUI a separate widget class needs to be implemented. It would for instance technically be possible to implement the history and the workspace in a single class. However this would have for consequence that Eclipse could not manage them separately and the user must always open the two features. In the diagram the upper 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. This is done by Eclipse with the help of the plugin.xml. However the plugin.xml does not interact directly with the SWT widgets. Eclipse requires classes that implements the IEditorPart interface for an editor or the IViewPart interface for a view. In order to make it simpler to implement those interfaces Eclipse puts abstract classes at the disposal of the developers. The EditorPart and the ViewPart are those abstract classes. They already implement the interfaces to a certain extend. The user still need to furnish some implementation but the new requests are simpler to understand. The EditorPart and the ViewPart implement the default behavior of the IEditorPart and the IViewPart. For instance the IViewPart interface needs the following methods to be implemented getviewsite() 16

17 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, which explains 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 the abstract class the general understanding of GUIs is sufficient. If a developer wants to implement those interface on its own he has to make sure he uses the Eclipse programming practices and respects all its needs. The console is an editor because it is the central part of the plugin. An editor is an Eclipse definition of a SWT widget that is meant to edit files. This leads to save and load methods that are needed in addition to a view. However those methods are not used in Scilab as the Scilab console has not direct source files that need to be edited. This makes an EditorInput necessary. A EditorInput is the description of an Input else than a file. The most impotent part in such an input is the equal method. This method is used to check if an 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 the console. The instances of all the editors and views are managed by the Eclipse engine. Eclipse will search all the already opened editors in order to find an instance of the Console editor. If it cannot find any open instance it will open a new one. However if it finds one it will check the inputs of the already opened instances. If its input is the same as in the requested it will pass this editor back. In our case the equal method of the EditorInput checks only if the inputs are of the same type. This means that all the requests for a console will either create a new console or return the already opened console. This way 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 different views and editor which work independently from each other. So there is no central object that exists during the whole life cycle of the plugin. This is why Eclipse has an AbstractUIPlugin class. It is implemented 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 engine which 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 the start 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 initialized with Scilab content at the start of the plugin. For instance the Scilab history need to be initialized. It will be blocked until the Scilab call has finished. However the Eclipse engine will not tolerate a blocked 17

18 view and after a certain timeout it will try to stop this action. This leads to a undefined state of the Scilab interface and the Eclipse engine. Eclipse many load partially or block totally. The start up of Eclipse is a delicate time. The views and editors must not block at this time. The blocking can occur due the native code access but 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 the constructor of the Activator it might fail as the required information does not yet exists. This failure might block the widgets. JavaSciWrapper A major problem that may occur is the parallel access to the Scilab engine. As every widget has its own thread concurrent access is likely to occur. The initial Java to Scilab interface did not manage concurrent access. Nor the Java code nor the Scilab code had a way to manage such situations. For instance 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 plugin to the Scilab engine. This prevents calls from multiple treads as every widget has its own. The history calls the loadhistory and the gethistory, the console calls the exec methods and the workspace loadsciworkspace and the getworkspace methods. Those are also the most important methods of the Wrapper. All of them are synchronized to prevent concurrent access. Those methods executes all the Scilab commands that are necessary for the different operations. The workspace and history methods are split in two parts. The actual execution and the getter to access the results. 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 returns the saved values. This way it is easy to share the results. For instance the history is used by the history widget 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 current interface is very limited. The default way to execute a Scilab command for Java is to have a shared variable 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 result can be accessed. This way does unfortunately not work for all the commands. Assignments, multilined functions, scripts, clear variables, plots, formatting functions and file system navigation does not work. There are certainly other exceptions. Those exceptions must be treated in unique ways. For instance the multilined commands are temporarily saved in a file and executed like a normal script. The plot function is even more complicated. It leaded to the implementation of a new plot class. The plot runs in a separate thread in order to start the GTK plot. However the coexistence of GTK and Java is not trivial. The GTK may only be controlled by a single thread. This means that when a plot was launched once it need to be controlled by the same thread as long as the Scilab libraries run. Else a asynchronous Xlib error may occur. An other consequence of the fact that not two different threads may access 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 and the workspace accesses those variables two threads access the plot variables and the Xlib crashes. At the moment the error is solved by a Java semaphore. This semaphore prevents the workspace to be updated while 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

19 Internal connection The last part of the architecture is the connections between the Activator and the widgets and the JavaSciWrapper and the widgets. This connection uses listeners. The WrapperReciever interface is used to connect the Activator with the workspace, the history and the console at the time of start up of the plugin. As already described the start up of the plugin is a very delicate time. The Widgets must not block. This is achieved by the recievewrapper mechanism. The Widgets executes the getwrapper method of the Activator during there creation. This method will check if a wrapper already exists. If it is the case the wrapper is directly returned by executing the recievewrapper method of the calling widget. However if the wrapper does not exist yet the requesting widget is saved in a Vector and the JavaSciWrapper is created in a separate thread. This separate thread prevents the method from blocking. Furthermore will it create the wrapper and execute the loadhistory and the loadsciworksapce methods. Those methods need the Scilab engine and will take some time. Then the thread has finished the recievewrapper methods of the widget that are saved in the Vector are executed. They will than take 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 Observer Vector. This leads to the connection between the wrapper and widgets. Always when the exec method of the wrapper is executed the history and the workspace are updated. This is done by executing the update methods of all the objects in the Observer Vector. Annex Eclipse Eclipse is an IDE that was design to help Java developers to write their source code. It possesses many interesting and useful features: the package browser, the outline, the auto compile, the auto correct and the debugger only to cite the most important. Furthermore the whole graphical environment is nicely designed and gives the user the freedom to place the features as he likes. The user can decided with widget 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, for delivering what the project calls "rich-client applications", as opposed to "thin client" browser-based applications. So far this framework has typically been used to develop Integrated Development Environ- 19

20 ments (IDEs), such as the Java IDE called Java Development Toolkit (JDT) and compiler (ECJ) that comes as part of Eclipse (and which are also used to develop Eclipse itself). However, it can be used for other types of client application as well. Eclipse is also a community of users, constantly extending the covered application areas. An example is 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 is now managed by the Eclipse Foundation, an independent not-for-profit consortium of software industry vendors. 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 the rich 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 buffers, text handling, text editors * The Eclipse Workbench - views, editors, perspectives, wizards Eclipse s widgets are implemented by a widget toolkit for Java called SWT, unlike most Java applications, which use the Java standard Abstract Window Toolkit (AWT) or Swing. Eclipse s user interface also leverages an intermediate GUI layer called JFace, which simplifies the construction of applications based on SWT. Eclipse employs plug-ins in order to provide all of its functionality on top of (and including) the rich client platform, in contrast to some other applications where functionality is typically hard coded. This plug-in mechanism is a lightweight software componentry framework. In addition to allowing Eclipse to be extended using other programming languages such as C and Python, the plug-in framework allows Eclipse to work with typesetting languages like L A TEX, networking applications such as telnet, and database management systems. The plug-in architecture supports writing any desired extension to the environment, such as for configuration management. Java and CVS support is provided in the Eclipse SDK. It does not have to be used solely to support other programming languages. The Eclipse SDK includes the Eclipse Java Development Tools, offering an IDE with a built-in incremental Java compiler and a full model of the Java source files. This allows for advanced refactoring techniques and code analysis. The IDE also makes use of a workspace, in this case a set of metadata over a flat filespace allowing external file modifications as long as the corresponding workspace "resource" is refreshed afterwards. Taken from Wikipedia. 20