Developing User Interfaces (UI) for software can be tedious without tools to visualize, modify and test. A Graphical User Interface (GUI) builder could simplify the development process of an UI. In this paper we present Pyramidion, a framework to implement domain-specific editor to show and modify the properties of any objects. We used Pyramidion to generate Pyramid, a GUI builder that can modify the properties of graphical elements that compose an UI. In this paper we will present the general concept behind Pyramidion through the example of Pyramid.
In this paper, we present the following contributions: the definition of a domain-specific editor in Section 2, an example of a domain-specific editor in Section 3, the Pyramidion core architecture in Section 4, how we implemented Pyramidion in Pharo in Section 5, pyramid, the GUI builder created with Pyramidion in Section 6, related works in Section 7, finally we conclude the paper in Section 8.
A domain-specific editor is an application that helps a user to modify or to create a domain-specific
model composed of domain-specific objects. Improving software can be long and tedious [
We developed Pyramidion, a framework to create domain-specific editors. Pyramidion reduces the efort the developers need to make to create a working editor for a specific-domain. They have to specify the accessors and mutators of the model, the associated views, and the needed editor behaviors for the specific-domain.
• On the left (1), a panel that is made of tabs, currently there is one tab named Tree. It shows a kind of inspector for the graphic element tree that is manipulated by the domain-specific editor; the inspector allows the user to select one or several elements of this tree; • On the center (not numbered), a panel to render the trafic light (the domain model view) and the current selection. Any valid change in the graphic element tree is rendered on this panel; • On the right (3), a panel also made of multiple tabs; the tab named Visuals is selected. The associated panel contains a specific editor for the background color property of the currently selected graphic element (2); 1 2 3
In order to edit a particular property (e.g. the background color) of a graphical element inside a tree, a user first selects the targeted graphic element in the tree inspector. Then the property views are updated according to the selected graphic element. Finally, the user can use the specific editor for the background color property to see the current color of the selected elements and change its value. Therefore, a domain-specific editor is made of 3 subsystems: • Panel Builder Manager, to modify and extend the user interface of the editor. • Selection System, to select the elements inside a tree of elements. • Command System, to view and update the properties of the selected elements.
TPlugin + configureBuilder(Builder) + addPanelOn(Panel Builder Manager) + connectOn(Editor) Panel Builder
Manager
Builder + build() : Editor
Editor
create Selection System
Command System
The architecture of Pyramidion is based on the use of plugins. The architecture is shown in Figure 2. In the context of Pyramidion, a plugin is programmed as a class to add specific features to a domain-specific editor. All plugins of a specific editor are managed by a builder. Then, a specific editor consists in a builder and a set of plugins. Any plugin can interact with the 3 subsystems of the specific editor: the Panel Builder Manager, the Selection System and the Command System (in grey in Figure 2).
• MainUIPlugin, a plugin to describe the diferent panels of the UI of our editor. • TreePlugin, a plugin to select the graphical elements.
• BackgroundPlugin, a plugin to display and modify the current value of the background.
Each phase running consists in the sending of a specific message by the builder to its registered plugins. Therefore a plugin class must implement 3 methods: #configureBuilder: for the configuration phase, #addPanelOn: for the panel adding phase and #connectOn: for finalization of the editor building. PyramidionBuilder :Builder
build
configureBuilder: 1 2 3 «Editor» addPanelsOn: connectOn: configureBuilder: «modify» addPanelsOn: connectOn: configureBuilder: addPanelsOn: « create » connectOn: « create » :Panel Builder Manager « extend » « extend » « extend » « extend » « extend » « extend »
The next sections describe how the builder uses theses 3 plugins to construct the domain specific editor. 4.1. Configuration of the builder and creating the view of the editor The view of a domain-specific editor is composed of widgets. The widgets are: the buttons, the lists, the panels, the textfields, the menus etc. The users will use the widgets to see and modify the domainspecific model or to use transversal capabilities (like the undo-redo). Pyramidion uses the widgets of the system to display the UI of the domain-specific editors. The Widget Adaptaters are used as adapters between the widgets of the system and the Pyramidion editor.
The Widget Adaptaters are created by the plugins using the Panel Builders of the Panel Builders Manager (see Figure 4). Then they are added to the Panel Builder that created them.
The Panel Builders Manager contains multiple Panel Builders. Each Panel Builder assembles the diferent widgets inside the Widget Adaptaters to form a panel. Panel Builders Manager uses the panels (that contains the diferent widgets) to create the view of the editors.
There are diferent types of Panel Builder. Each type of Panel Builder depends on the necessary widget types to create the domain-specific editor. If developers want to add a new widget type for its editors, they will have to create a dedicated Panel Builder that creates those new widgets and assembles them in a panel. For our current use of Pyramidion, 4 diferent Panel Builders are defined : • Notebook, where each widget is a new view inside a tab. • Buttons bar, where each widget is a button. • Single panel, where only one widget corresponding to a view is displayed.
• Menu, where each widget is a menu item or a group of menu items.
The method #configureBuilder: of the plugins is used by the builder to configure itself (see phase 1 in Figure 3). Any plugin can change the default Panel Builders Manager of the builder, it also have to define the diferent Panel Builders that will be used to create the editor.
The #addPanelOn: of the plugins is used by the builder to create new widget Adaptaters during phase 2 in Figure 3. Any plugin can add any number of widget Adaptaters to the diferent Panel Builders. The Widget Adaptater comes with a priority value used when multiple widget Adapters want to be added on the same Panel Builders. The priority value will be used to define the order of the widgets on the Panel Builders. This priority value is an arbitrary value defined by the developer of the plugin.
Plugin 0..1
Panel Builders
Manager * creates
* Panel Builder
Widget Adaptater Creates the Widget Adaptaters using the Panel Builder and adds them to the Panel Builder
Notebook Panel
Builder
Buttons Bar Panel
Builder
Single Panel
Builder
Menu Panel Builder
In our example The Panel Builders Manager is created by the MainUIPlugin during the configuration phase (see Figure 3). The Panel Builders Manager has two Notebook Panel Builders to add the widget Adaptaters created by the two other plugins.
The TreePlugin adds a tree inspector view to display and select the diferent graphical elements (see number 1 in Figure 1). The BackgroundPlugin adds a specific editor for colors to display and modify the background of selected graphical element (see number 3 in Figure 1). 4.2. Connect to the subsystems of the editor The method #connectEditor: is used by the Pyramidion builder to link the diferent subsystems of the domain-specific editor to the plugins (see Figure 3).
The TreePlugin will have to update its content and its selection accordingly to the selection system contents and selection. It will also have to change the selection system when the user select a new element in the UI.
The BackgroundPlugin will have to connect to the selection system to display the correct information according to the current selection. It will have to also connect to the command executor (see Figure 5) system to be able to modify the background of the selected graphical elements. 4.2.1. The selection system Access to all the elements of the domain-specific model is necessary to allow the users to understand the structure of the elements and the global properties of the model. Access to a specific subgroup of elements of the model is also necessary to see and modify the detail of the model. Therefore, a domain-specific editor must have 2 collections of objects: • The first level elements, that represent all the roots of the current domain-specific model. • The current selection, that represent a subpart of the domain-specific model.
In the Figure 1 at number 1, the element named A has 3 children named B, C and D. We can see on number 2 that the element D is selected. The first level elements is a list that contains the element A and the current selection is a list that contains the element D. How plugins are dynamically linked ? The first level elements and the current selection are both observable collections. When a modification is made to one of them, a signal is sent to all the objects that observe them. Any plugin can register as an observer of the first level elements or the current selection.
This observer/observable pattern is used by the BackgroundPlugin to update the displayed properties panel when the current selection changes (see number 3 in Figure 1). The TreePlugin can modify the current selection collection and therefore trigger the signal to all the observers of the current selection. 4.2.2. Object modification mechanism We call property the association of a command and an input as depicted in the Figure 5.
The input is a kind of specific editor that are used to display and modify the values of the selected objects. In Figure 1, the element D is selected. The element D has a green background. We can see the property for the background is present and display the green value (number 3 on the figure).
The command is used to retreive the value of the properties to be displayed in the input, mutate the selected objects (change the value of the object) and decide if the input should be visible to the users. For example, we do not want to display the input to change the text of a graphical element if no element in the selection is a text element.
Display the value of the property. When the current selection is updated, each object of the selection is tested by the verification method ( #canBeUsedOn) of the command of each property: • If the verification methods return false for all selected elements, then the property is not displayed. • If only one method return true, then the input for this element is displayed (single selection on
Figure 6). • If multiple methods return true, then the property create multiple inputs (multi selection on
Figure 6).
Change the value of the property. The command is used to mutate the selected objects when the users interact with the inputs of the properties. The input contains a callback that will use the command on the commands executor with the new value of the input as arguments for the command (see the method #useCommandOn of the Command Executor in the Figure 5). The commands executor can be extended by any plugin to add behavior before or after the execution of the command.
Properties Manager
Property
Input Builder 1 Input Model 1 Input Class
Command + getValueOf(Objet element) → Objet + setValueOfWith(Objet element, Objet argument) + canBeUsedOn(Objet element) → Boolean
Point Input Model + val1 → String + val2 → String Point Input Class Command Position Command Size 1
Commands Executor before * + useCCoommmmaannddOconm(mand,
Object argument) after 1 1
Using a builder to create the inputs. The selection system allows the multi-selection of elements as depicted in Figure 6. The property uses an input builder that creates the diferent inputs when one element is selected or in multi-selection. The input builder take an input class and an input model to create the inputs and their associated callbacks.
Single Selection
Multi Selection
There are diferent types of input class: one for the strings, one for the numbers, one for the colors, one for a boolean value, etc. Some inputs can be used in diferent context (like in the Figure 7). For example the position property and the size property expect a Point as an argument, but this point represents two diferent concepts. The position is a coordinate x and y on the screen, the size is a height and a width. To specialized the Point Input we used the associated input model (Point Input Model) to help the users to better understand what is the property they are interacting with.
Constraints manager :Properties Manager Property Position :Property
builder :Input Builder command :CommandPosition
Input :Point Input Class
Model :Point Input Model val1 = x val2 = y
Property Size :Property
builder :Input Builder command :Command Size
Input :Point Input Class
Model :Point Input Model val1 = heigh val2 = width
We validate the Pyramidion architecture by implementing it in Pharo 3, a Smalltalk inspired language. Smalltalk allows the modification of the model at runtime and gives the possibility to the users to see each incremental modification. Therefore it reduces the cost of validation. Pharo is a full Integrated Development Environment (IDE) with plenty of support tools like inspectors and debuggers The editors created with Pyramidion can benefit from these tools.
The plugins in Pharo To create a plugin in our implementation of Pyramidion in Pharo, we use
Traits [
A singleton to centralize all plugins To facilitate the creation of editors by the builder, we created a system to register all plugins into a singleton. The singleton centralizes all the plugins and creates a builder with all the plugins ready to be installed. Therefore, the developers only have to register their plugins to the singleton only one time, and use the builder of the singleton to create an editor. We use the initialization method of the meta-class of the plugins to register them automatically when the class is created in the Pharo image. For example, we can use this behavior to automatically add new plugins after loading the package that contains the plugins from a Git repository.
The Spec2 library to make the UI We chose to use the Spec2 library [
We developed a GUI builder with Pyramidion in Pharo. Some of the plugins we developed ofer transversal capabilities and can be used in diferent domains. This is the case for: • The serialization plugin that allows us to save the current model modifications. • The historialization plugin keeps the state of the elements before the modification allowing the developers to undo their modifications.
• The playground plugin that creates a Pharo Playground inside the editor.
We will present Pyramid, our GUI builder for Bloc in Section 6.1. We will present a selection of the transversal plugins we created in Section 6.2. 6.1. Pyramid: a GUI builder with Pyramidion
We used Pyramidion to develop Pyramid 4: a GUI builder for Pharo. Pyramid is based on Bloc, a UI library for Pharo. Pyramid allows us to modify the properties of BlElements, the graphical elements of Bloc. The Figure 8 shows an example of Bloc graphical elements assembled to create a 3D efect. The dynamic graphical feedback that Pyramid enables makes developing such a complex view easier than writing the script in a workspace, running it, and then observing the result multiple times.
Developers can use Bloc to develop beautiful and complex applications [
The default version of Pyramid is composed of 16 plugins. There are multiple plugins for the properties, there are plugins for the WYSIWYG (What You See Is What You Get) view, etc. At Thales DMS, we created other plugins for our specific needs. For example, we have a plugin to import designs from Figma 5 into Pyramid.
Generally, a GUI builder can only modify applications created with the GUI builder [
The serialization plugin The serialization allows the users to save their current modifications. The serialization plugin will use the first level elements of the selection system as an entry point to generate a string that can be used to recreate similar objects. We chose to use Ston [6, Chapter 9] as the support for the serialization.
The historialization plugin The historialization is important because it is one of the most used
commands in other IDE [
The playground plugin The playground allows to add a Pharo playground in any domain-specific editor. The playground of Pharo allows to send any message to any object. It is a possible entry point to connect any tools of Pharo to the domain-specific model. It can also be used to modify any properties that are not already developed in the domain-specific editor.
Domain-specific tools Moldable debugger [
The Eclipse platform 6 allows the integration of domain-specific tools. The Eclipse platform developer
chooses which tools are installed. With Pyramidion, the developer also chooses which plugins are
installed. The Eclipse platform ofers diferent levels of integration [
Amulet [
We developed Pyramidion, a plugin-based framework that allows developers to create their domainspecific editors. The plugin-based architecture simplifies the development process and permits the reuse of some of the defined behavior between really diferent domains. We then used Pyramidion to create Pyramid, a GUI builder in Pharo.
As discussed in the previous sections, Pyramid cannot modify the behavior of the user interface and dynamic widgets. But thanks to the Pyramidion framework, it will be easier to add new functionality to Pyramid. This would allow Pyramid to create or modify complete applications at runtime with a dedicated UI, allowing us to prototype more quickly.