Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

DSDP/MTJ/UI Designers

< DSDP‎ | MTJ

General Comments

In release 1.0 UI Designers are supposed to cover eSWT and LCDUI - Rauno Seppälä

Create New Container

BRIEF DESCRIPTION

The user can create a new UI design by creating a new base container.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to create a new UI design for a new container.
B2. The user selects the new visual class wizard.
a) The wizard lists all supported container types.
b) The wizard asks the user for the container package, class name, type and any other needed information.
c) The system creates the new base container code.
d) The system opens the new container code in a new UI designer.

Alternative flow'

Alternative flow 1: The user creates a new code file for the container in a code editor or with the new class wizard
A1. If the user creates a new code file for the container by hand, he can open the container in the UI designer by selecting the file/class and opening it.
Alternative flow 2: The code file cannot be created
A2. The user is informed about the error and container creation is cancelled.
Alternative flow 3: The user gives an invalid value for the mandatory property
A3. The system warns the user about the error and the user is asked again for a valid value.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS


POSTCONDITIONS

A new UI design is opened for the container<b The system opens a new UI designer for the base container. The user can start adding components to the container.

The code is created for the new container<b A new file is created for the new container and the required code is added to the file.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Modify New Container

BRIEF DESCRIPTION

The user modifies the container in the UI designer to change the outfit of the UI designer.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to modify the container.
B2. The user selects the container that he wants to modify.
B3. The user opens the property list for the container.
B4. The user selects the property to modify.
a) The property editor is enabled, allowing the user to alter the property value.
B5. The user modifies the property value and accepts the change.
a) The system modifies the code according to the changes.
b) The system validates the new property value.
c) The system updates the property for the container.
d) The system redraws the container and components included within it when needed.

Alternative flows

Alternative flow 1: In-place editing
A1. The user can activate in-place editing for certain properties (e.g. text) when a single container is selected. When in-place editing is activated, the editor for a property opens in the UI designer and the user can edit the property directly in the UI editor.
Alternative flow 2: Multi selection
A2. The user can select multiple containers and modify their common properties. When multiple containers are selected, only the properties that are common for those containers are selectable and editable. After editing the property, the new property value is updated for all of the selected container elements.
Alternative flow 3: The user gives an invalid new value for the property
A3. If the user gives an invalid new value for the property being altered, the system will warn the user about the invalid value and reverts the property back to its original value.
Alternative flow 4: The code file cannot be modified
A4. If the system cannot open the code file to modify it, the user is warned about the error and the modification is cancelled.
Alternative flow 5: Eclipse refactoring
A5. If the user performs Eclipse refactoring while the UI designer is open, the system will inform the user that refactoring was performed and components in the designers have been updated accordingly.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

The UI designer is running and has one or more containers<b Container properties can only be altered when the UI designer is running.


POSTCONDITIONS

The property of the selected component is changed<b The modified property value is visible in the property list. If the property affects a component UI, then the component will be redrawn according to the new property values.

The undo feature is available<b The undo feature allows the user to undo the changes made.


Extension Points

Special Requirements

Additional Information



Comments:


Remove New Container

BRIEF DESCRIPTION

The user can remove a container from the UI design.


FLOW OF EVENTS

Basic Flow of Events

B1. The user selects the container he wants to remove.
B2. The user removes the container from the UI designer.
a) The system updates the code by removing the generated code for the container. The removed code contains the code for child elements and the code for events. Imports are not removed.
b) The system removes the container and all of its components from the UI designer.
c) The UI designer UI is redrawn to match the changes.

Alternative flows

The user removes the container from the code
A1. If the user removes the container in the code editor, the system notices the code has been changed and re-parses the code for design. This effectively removes the container from the UI designer.
The code file cannot be deleted
A2. If the code file cannot be removed, the user is informed of this and container deletion is cancelled. This can happen, e.g. when some other program has locked the code file.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

The UI designer is open for a main container<b The UI designer is opened for the base container that includes a container the user wants to remove. The base container has one or more sub-containers.


POSTCONDITIONS

The sub-container is removed from the parent container<b The removed container and all of its components will no longer be visible in the UI designer and all associated code is removed.

The undo feature is available<b The undo feature allows the user to undo the removal of the container.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Add Component

BRIEF DESCRIPTION

The user opens the UI designer for the base container component. The UI designer allows the user to add components to the container.


FLOW OF EVENTS

Basic Flow of Events

B1. The user selects the component to add from the list of available components.
B2. The user places the component in the container.
a) The system adds the component to the container in the UI designer.
b) The system asks for any mandatory properties from the user (e.g. component name).
c) The system generates code for the component added.
d) The system updates the component’s properties list.
B3. The user can modify the component’s properties.

Alternative Flows

Alternative Flow 1: The UI container does not allow a UI component to be added
A1. If the UI container does not support the UI component type that the user is adding, the UI designer will show a visual indication that states the user has tried to add an invalid component. Optionally, there could be an informative message telling the user why the operation was denied/failed.
Alternative Flow 2: The user tries to place a component at an invalid position in the UI container
A2. If the user tries to place the new component at a position where it cannot be added, there will be a visual indication about invalid placement. Optionally, there could be an informative message telling the user why the operation was denied/failed.
Alternative Flow 3: The user gives an invalid mandatory property value
A3. If the user gives an invalid value for a mandatory property, e.g. name, the user is warned about the error and is asked to enter the property value again.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The UI container component has been created

The user must first create a container component, into which the user can add UI components.

Precondition 2: The UI designer is opened for container components

The UI designer is open for the UI container component. The component list is open.


POSTCONDITIONS

Postcondition 1: The UI component is added to the UI designer

The UI designer shows a new UI component and the component’s properties.

Postcondition 2: The code for the component has been created

The system has created the code file for the new component. Possible changes that the user has made to the properties are applied to the code.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Modify Component

BRIEF DESCRIPTION

The user can alter the properties of selected components in the UI designer. Properties change the outlook and behaviour of components. If components have similar properties, more than one component can be changed and common properties for them all can be changed.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to modify a UI component.
B2. The user selects the component he wants to modify.
B3. The user opens the property list for the component.
a) The system opens the list showing the properties and values that can be changed for that particular selected component.
B4. The user selects the property to alter.
a) The property editor opens, allowing user to alter the value of a property. Different properties can have custom property editors.
B5. The user alters the property value and accepts the change.
a) The system updates the code according to the changes performed.
b) The system updates the property value in the UI and updates the UI according to the changes performed.

Alternative flows

Alternative flow 1: In-place editing
A1. The user can activate in-place editing for certain properties (e.g. text) when a single component is selected. When in-place editing is activated, the editor for a property opens in the UI designer and the user can edit the property directly in the UI editor.
Alternative flow 2: The user edits the component by editing the code
A2. The user edits the code to change the component. The UI designer notices that the code has changed and updates the component’s outlook and the property list accordingly.
Alternative flow 3: Multi selection
A3. The user can select multiple UI components and modify their common properties. When multiple UI components are selected, only the properties that are common for those containers are selectable and editable. After editing the property, the new property value is updated for all of the selected UI components.
Alternative flow 4: The user gives an invalid new value for the property
A5. If the user gives an invalid new value for the property being altered, the system will warn the user about the invalid value and reverts the property back to its original value.
Alternative flow 5: Eclipse refactoring
A6. If the user performs Eclipse refactoring while the UI designer is open, the system will inform the user that refactoring has been performed and components in the designers have been updated accordingly.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The UI designer is running and has one or more components

Component properties can only be altered when the UI designer is running.


POSTCONDITIONS

Postcondition 1: The property of the selected component is changed

The Property value visible in the property list is updated for the selected components and the code is changed. If the property affects a component UI, then the component will be redrawn with new property values.

Undo is available

The undo feature will be available to undo the latest change.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Remove Component

BRIEF DESCRIPTION

The user removes a UI component from the container.


FLOW OF EVENTS

Basic Flow of Events

B1. The user selects the component he wants to remove. B2. The user removes the component. a) The system removes the component from the UI design. b) The system removes the component’s commands and references to other components. c) The system removes any associated code. The removed code contains the code for the component’s initialisation and the code for the component’s properties. Import statements are not removed. d) The UI designer views are redrawn to match the changes. This includes the actual UI designer area, property views, etc.

Alternative flows

Alternative flow 1: The user removes the component by editing the code
A1. The user edits the code to remove the component. The UI designer notices that code has been removed and updates the UI designer views accordingly.
Alternative flow 2: Multi selection
A2. The user can select multiple UI components and delete the selected components. After removing the selected components, the UI designer views are redrawn to match the changes. This includes the actual UI designer area, property views, etc.
Alternative flow 1: The code file cannot be deleted
A3. If the code file cannot be removed, the user will be informed of this and component deletion continues. This might happen, e.g. when some other program has locked the code file.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The UI designer is open for a container and the container has one or more components

The UI designer is opened for a container, showing the components of that container. The container must have at least one component that can be removed.


POSTCONDITIONS

Postcondition 1: The component is removed from the container and all associated code is removed

The component is no longer visible in the UI designer or in the container.

Postcondition 2: The undo feature is available

The undo feature is available to undo the deletion of the component.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Add Event

BRIEF DESCRIPTION

The user can add an event to a component in the UI designer.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to add an event to the component.
B2. The user selects the component to which he wants to add a new event.
B3. The user selects the event add –feature.
a) The system shows a list of events available for the selected component.
B4. The user selects the event he wants to add from the list of available events.
a) The system asks for the event listener implementation method from the user.
B5. The user selects the event listener implementation method.
a) The system asks for the mandatory properties for the new event from the user.
b) The system adds the code for the new event.
c) The system adds a new event into the list of events for the selected component.
d) The system adds the new event to other proper event lists in the UI designer.

Alternative flows

Alternative flow 1: The user adds a new event to the code
A1. If the user adds a new event to the code the system will notice that the code has been changed and re-parses the code for design. This effectively adds the new event to the UI design.
Alternative flow 2: The user gives an invalid mandatory property value
A2. If the user gives an invalid value for a mandatory property, e.g. name, the user is warned about the error and is asked to enter the property value again.
Alternative flow 3: The code file cannot be created
A3. The user is informed about the error and component addition is cancelled.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

The UI designer is open and has at least one component that allows events<b Events are associated with UI components, so events can only be added when the UI designer is open and has components that allow events.


POSTCONDITIONS

Postcondition 1: The code is created for the new event<b Code is generated and the file can be opened for editing.

Postcondition 2: The new event is available in component’s event list<b Selecting the component’s event list shows the newly added event included.

Postcondition 3: The event’s properties are modifiable<b The user can select the event and modify its properties.

Postcondition 4: The undo feature is available<b The undo feature allows the user to undo the addition of the event.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Remove Event

BRIEF DESCRIPTION

The user removes an event from the selected component.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to remove an event from the selected component.
B2. The user opens the event list for the selected component.
B3. The user selects the event to remove.
a) The system removes the event-related code. This contains the event’s code and all of the code that was added to the components to make them listen to the event.
b) The system removes the event from the UI designer.

Alternative flows

Alternative flow 1: The user removes the event from the code in the code editor
A1. If the user removes the event in the code editor, the system notices that the code has been changed and re-parses the code for design. This effectively removes the event from the UI designer.
Alternative flow 2: The code file cannot be opened
A2. If the system cannot open the code file for editing, the user will be warned about the error and the removal is cancelled.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

The UI designer is open and includes a component that has at least one event<b Events can only be removed from components in the UI designer.


POSTCONDITIONS

Postcondition 1 <b The event is removed from the UI designer’s design and the event’s code is removed

Postcondition 2: The undo feature is available<b The undo feature allows the user to undo the removal of the event.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Add Menu

BRIEF DESCRIPTION

This use-case describes how a menu is added to a UI container in the UI Designer. Typically in LCDUI applications the menu contains commands and in eSWT applications the menu contains menu items or commands


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to add a menu to the UI container in the UI designer.
B2. The user selects the menu component from the component list and adds it to the UI container.
a) The system adds the menu to the UI container and visualises it.
b) The system generates the required code for menu creation.
c) The system lists the menu component’s properties for the user.
B3. The user can modify the menu’s properties with editors.

Alternative Flows

Alternative flow 1: The user creates a sub-menu
A1. The user decides to add a submenu of an existing menu.
A2. The user selects the add menu feature.
A3. The user adds the menu to an existing menu in the UI container.
a) The system creates the code for the menu and sets it as a submenu of the existing menu.
b) The system adds the menu to the UI container as a submenu of the existing menu.
c) The system redraws the UI container.
d) The system lists the menu component’s properties for the user.
A4. The user can modify the menu’s properties with editors.
Alternative flow 2: The user creates a sub-menu with the properties editor
A5. The user decides to add a sub-menu to an existing menu.
A6. The user selects the add menu feature.
A7. The user places the menu in the UI container but not upon an existing menu.
a) The system adds the menu to the UI container and visualises it.
b) The system generates the required code for menu creation.
a) The system lists the menu component’s properties for the user.
A8. The user selects the parent menu from the menu component’s properties.
a) The system modifies the menu’s code so that it is set as a sub-menu of another menu.
b) The system adds the menu as a sub-menu of an existing menu.
c) The system redraws the UI container.
Alternative flow 3: Sub-menu creation is not allowed
A9. The user decides to add a submenu to an existing menu.
A10. The user selects the add menu feature and tries to place it upon an existing menu in the UI container.
a) The system shows a visual indication that the menu cannot be added as a sub-menu of the existing menu.
Alternative flow 4: The UI container does not allow a menu to be added
A11. If the UI container does not support the menu the user is adding, the UI designer will show a visual indication that states the user may not perform this task. Optionally, there could be an informative message telling the user why the operation was denied/failed.
Alternative flow 5: The user tries to place a menu at an invalid position in the UI container
A12. If the user tries to place a menu at a position where it cannot be added, there will be a visual indication about invalid placement. Optionally, there could be an informative message telling the user why the operation was denied/failed.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The UI designer is open and contains a UI container<b The UI designer must be open and include an active UI container.


POSTCONDITIONS

Postcondition 1: A menu component is added to the UI container<b A menu component is added to the UI container.

Postcondition 2: The code for the menu is created<b The code required for menu creation is created.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Modify Menu

BRIEF DESCRIPTION

This use-case describes how the menu can be modified using the UI designer.


FLOW OF EVENTS

Basic Flow of Events'

B1. The user decides to modify the menu.

B2. The user selects the menu to modify.

a) The system reveals the properties view for the selected menu.
b) The system activates the in-place editor.
B3. The user modifies the menu’s properties.
i) The user can add menu items.
ii) The user can remove menu items.
iii) The user can rename menu items.
iv) The user can change the order of menu items.
v) The user can change the menu to a sub-menu or remove it from being a sub-menu.
B4. The user saves his changes to the menu.
a) The system generates and modifies the code according the changes.
b) The system redraws the UI design.

Alternative flows

Alternative flow 1: The user modifies the menu using the in-place editor
A1. The user decides to modify the menu.
A2. The user selects the menu to modify.
a) The system reveals the properties view for the selected menu.
b) The system activates the in-place editor.
A3. The user modifies the menu using the in-place editor.
i) The user can add menu items.
ii) The user can remove menu items.
iii) The user can rename menu items.
A4. The user saves his changes to the menu.
a) The system generates and modifies the code according the changes.
b) The system redraws the UI design.
Alternative flow 2: The user modifies the menu from code
A5. The user modifies the menu directly in the code.
A6. The user compiles and saves the changes.
A7. The user opens the container class in the UI designer.
a) The system redraws the UI design.
Alternative flow 3: The user gives a wrong value for the menu properties
A8. The system will show an error message. After the user has accepted the message, the system restores the original value.
Alternative flow 4: The code file is locked by another editor and the code cannot be updated.
A9. The system shows an error message explaining why the modifications cannot be made. The changes made will not be saved until the file lock is removed and saving is tried again.
Exception 3: The user modifies the menu code so that it does not compile
A10. The user modifies the menu code so that it does not compile in the code editor.
A11. The user tries to open it in UI designer.
a) The system shows an error message explaining that the file cannot be opened in UI designer because it does not compile.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The user has created a menu to modify<b The user must have created a menu that can be modified

Precondition 2: The UI designer is open and the UI design with the menu is open and active To modify the menu the UI designer must be open. It must also contain the UI design with the menu to be modified.


POSTCONDITIONS

Postcondition 1: The menu is modified according to the user’s action and the generated/modified code compiles


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION


Comments:


Remove Menu

BRIEF DESCRIPTION

This use-case describes how a menu is removed from a UI container in the UI designer.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to remove a menu from the UI container.
B2. The user selects the menu to be removed.
B3. The user selects the remove menu feature.
a) The system removes the menu item’s code related to the menu.
b) The system removes the code generated for the menu.
c) The system removes the menu and its sub-items from the UI design.
d) The system redraws the UI design.

Alternative flows

Exception 1: The user has created code linked to a menu outside the generated code
A1. The system shows that the code cannot be compiled and the UI design is not displayed until the errors have been fixed.
Exception 2: The code cannot be removed because the file is open in another editor
A2. The system shows an error message explaining that the code cannot be removed. Removal is cancelled.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The UI Designer is open and the container class contains a menu


POSTCONDITIONS

Postcondition 1: The menu and its menu items are removed

The menu and its menu items are removed from the UI designer. Also, the generated code for these is removed. The undo feature is available.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Install Component

BRIEF DESCRIPTION

The user can install new custom components to the UI designer.


FLOW OF EVENTS

2.1 Basic Flow of Events

B1. The user decides to install a new custom component.
B2. The user copies the new custom component’s file(s) to Eclipse’s folders.
B3. The user starts Eclipse.
a) The system adds the component(s) to the UI component list. A new component category may also be added.

Alternative flows


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1:

The user has a component (Eclipse plug-in) he wants to install


POSTCONDITIONS

Postcondition 1:'

The new custom component is available in the system


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Uninstall Component

BRIEF DESCRIPTION

The user uninstalls a component from the system.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to uninstall the component.
B2. The user removes the component’s (Eclipse plug-in) library files from Eclipse’s folders.
B3. The user starts the system.
a) The system notices that the component has been uninstalled and removes the component from the component list.

Alternative flows

Alternative Flow 1: The user removes only some of the component’s files
A1. The user decides to remove the component.
A2. The user removes only some of the plug-in’s files.
A3. The user starts the system.
A4. The system acts as if the component had been completely removed.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The system is not running

Components can only be uninstalled when the system is not running as the system locks the components.

Precondition 2: The user knows the plug-in files he needs to remove


POSTCONDITIONS

Postcondition 1: The component is not available in system


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Install UI Style

BRIEF DESCRIPTION

The UI designer is based on different UI styles. A UI style defines the outfit and the positioning of the components on the screen. The user can install new compatible UI styles to the system.


BASIC FLOW OF EVENTS

B1. The user decides to install a new UI style.
B2. The user adds the plug-in containing the new UI style to the Eclipse’s plug-ins folder.
B3. The user starts the system.
a) The system notices that a new UI style has been added and makes it available anywhere UI style selection is visible.


ALTERNATIVE FLOWS

Exceptions

Exception 1: A UI style is not compatible
A1. If the new UI style plug-in is not compatible, the system ignores the new UI style and does not load it.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS


POSTCONDITIONS

Postcondition 1: The new UI style is available to be selected

After installing a new UI style it is available for selection.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Change UI Style

BRIEF DESCRIPTION

The application allows the user to switch between different screen engines and UI styles (Look and Feel) for them.


FLOW OF EVENTS

Basic Flow of Events

B1. The user opens the UI designer for the UI container class.
a) The system lists the available UI styles for the user to select.
B2. The user decides to switch the UI style which the UI designer currently uses.
B3. The user selects the UI style he wants to use.
a) The system redraws the UI for the selected UI style, move and zoom controls as needed, and visualises the new display area. Visualisation takes care of any possible overflow indications when all controls are not (fully) visible in the new UI style.
b) If there are several screen sizes possible for the UI style, the default screen size is selected.
B4. Additionally, the user can select the screen size for the UI style (when UI style offers more than one screen size).

Alternative Flows

Alternative Flow 1: The new UI style has different resources, e.g. fonts
A1. When switching the UI style, the new style doesn’t have some resources that the current style has.
a) The system uses default resources.
Alternative Flow 2: The new UI style does not have the screen size of the current style
A2. When switching the UI style, the new style does not have the screen size that the current style uses.
a) The default screen size for the new UI style is selected and the UI is repainted accordingly.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: More than one UI style has been installed

To switch a UI style, the user must have more than one UI style installed.

Precondition 2: The UI designer is running

Switching between UI styles is only possible when the UI designer is running.


POSTCONDITIONS

Postcondition 1: The UI has been updated for a new UI style

UI components are redrawn according to the new UI style and its screen size.

Postcondition 2: The screen sizes list is updated

A list of available screen sizes is updated to show the screen sizes of the selected UI style.


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:


Uninstall UI Style

BRIEF DESCRIPTION

The user can uninstall the UI style from the system.


FLOW OF EVENTS

Basic Flow of Events

B1. The user decides to uninstall the UI style.
B2. The user removes the UI style plug-in from the system’s folder.
B3. The user starts the system.

Alternative Flows

Alternative flow 1: The user removes only some of the plug-in files
A1. The user removes only some of the UI style plug-in files or folders.
A2. The user starts Eclipse.
A3. The system works as if UI style had been completely uninstalled.


SUBFLOWS


KEY SCENARIOS


PRECONDITIONS

Precondition 1: The user knows what files need to be removed form Eclipse’s folders to uninstall the UI style plug-in


POSTCONDITIONS

Postcondition 1: The UI style is removed from UI style selection

The removed UI style is no longer available in the UI style selection lists. In addition, UI style components are removed from the system (including files).


EXTENSION POINTS


SPECIAL REQUIREMENTS


ADDITIONAL INFORMATION



Comments:

Back to the top