gui

Author: Tom-Willemsen

.gitignore

@@ -2,3 +2,4 @@
 .venv/
 ibex_developers_manual.egg-info/
 build/
+_build/

doc/Gui.md

@@ -0,0 +1,44 @@
+# IBEX GUI (Eclipse)
+
+## Getting Started
+
+```{toctree}
+:glob:
+:titlesonly:
+
+client/Building-the-GUI
+client/GUI-Development-Workflow
+client/Maven-and-Tycho
+```
+
+## Coding
+
+```{toctree}
+:glob:
+:titlesonly:
+
+client/GUI-Coding-Conventions
+client/An-Introduction-to-Databinding
+client/Adding-a-Plugin-or-Feature-to-Maven-Build
+client/Connecting-a-View-to-a-PV
+client/Static-analysis
+client/Instrument-switching
+client/PV-Switching
+client/OPI-Creation
+client/Adding-a-Button-to-the-Perspective-Switcher
+```
+
+## Testing
+
+```{toctree}
+:glob:
+:titlesonly:
+
+client/An-Introduction-to-Unit-Testing
+client/Adding-Unit-Tests
+client/Using-Mockito-for-Testing-in-the-GUI
+client/System-Testing-with-Squish
+client/Test-naming
+```
+
+# Web Dashboard

doc/Processes.md

@@ -9,6 +9,7 @@ processes/Tickets-and-their-Workflow
 processes/Umbrella-Tickets
 processes/Dependency-Updates
 processes/External-Contributions
+processes/Component-and-Activity-Stewards
 ```
 
 # Meetings
@@ -25,6 +26,7 @@ processes/Sprint-Planning
 processes/Sprint-Review-and-Retro
 processes/Program-Increment-Planning
 processes/Technical-Debt-Stand-down
+processes/Code-Chats-and-Lightning-Talks
 ```
 
 ## External meetings

doc/uncategorised/GUI_development/Testing/Adding-Unit-Tests.md renamed to doc/client/Adding-Unit-Tests.md

@@ -1,4 +1,4 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Testing](GUI-Testing) > Adding tests
+# Adding tests
 
 For more detailed information see [an_introduction_to_unit_testing.rst](https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/An-Introduction-to-Unit-Testing).
 

doc/uncategorised/GUI_development/Coding/Adding-a-Button-to-the-Perspective-Switcher.md renamed to doc/client/Adding-a-Button-to-the-Perspective-Switcher.md

@@ -1,4 +1,5 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Coding](GUI-Coding) > Adding a perspective
+# Adding a perspective
+
 ![Perspective Switcher](GUI_development/images/adding_a_button_to_the_perspective_switcher/IBEX_complete_perspective_switcher_highlighted.png)
 
 

doc/uncategorised/GUI_development/Coding/Adding-a-Plugin-or-Feature-to-Maven-Build.md renamed to doc/client/Adding-a-Plugin-or-Feature-to-Maven-Build.md

@@ -1,8 +1,8 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Coding](GUI-Coding) > Adding a plugin or feature to Maven
+# Adding a plugin or feature to Maven
 
 The steps for adding a plug-in (one small part of IBEX, such as the blocks view) or feature (a larger collection of plug-ins, such as CSS) to the maven build are below:
 
-# Step by step:
+## Step by step:
 * Add the plug-in to `feature.base`:
     * Open `feature.xml` in `uk.ac.stfc.isis.ibex.feature.base`
     * Go to "Included Plug-ins" (or "Included Features") tab and click "Add..."

doc/uncategorised/GUI_development/Coding/An-Introduction-to-Databinding.md renamed to doc/client/An-Introduction-to-Databinding.md

@@ -1,4 +1,4 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Coding](GUI-Coding) > Data binding
+# Data binding
 
 Note: there are some helpful tips to common errors/mistakes [here](Databinding---common-mistakes).
 

doc/uncategorised/GUI_development/Testing/An-Introduction-to-Unit-Testing.md renamed to doc/client/An-Introduction-to-Unit-Testing.md

@@ -1,6 +1,4 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Testing](GUI-Testing) > An introduction to unit testing
-
-# Unit Testing
+# An introduction to unit testing
 
 To create unit tests for an Eclipse plug-in a Fragment Project is used. When creating a Fragment Project we assign the plug-in we wish to test as a Host Plug-in.
 Eclipse automatically gives the Fragment access to the classes in the original plug-in.
@@ -218,9 +216,9 @@ From the results it can be seen that 63.2% of the StringManipulator code is used
 The code that isn't used is highlighted in red - for this example we can see that we need to write a test that tests the reverseString method.
 
 
-# Eclipse is complaining
+## Troubleshooting
 
-## ClassNotFoundException
+### ClassNotFoundException
 
 Running the tests in Eclipse might crash with an error like:
 
@@ -244,14 +242,14 @@ This is a known bug and there is a workaround:
 * On the original dialog, click "Apply" and then "Run"
 * Hopefully, the tests will now work and you should be able to re-run them in the normal way
 
-## Eclipse is not picking up new tests
+### Eclipse is not picking up new tests
 
 If Eclipse is not picking up changes when you add tests you may need to change the default output folder for tests for Maven to pick it up.
 
 * Right-click on the tests plug-in, go to properties, Java build path
 * Change the output folder to target/test-classes (you may need to create this folder first by clicking browse, selecting target and adding the test-classes folder)
 * If this does not work try deleting the target/test-classes folder first, if it existed already, and do a clean rebuild of the workspace
 
-## IncompatibleClassChangeError
+### IncompatibleClassChangeError
 
 If the tests are failing because of an IncompatibleClassChangeError error then the solution is to delete the bin and target folders for both the main plug-in and the corresponding test plug-in

doc/uncategorised/GUI_development/Getting_started/Building-the-GUI.md renamed to doc/client/Building-the-GUI.md

@@ -1,4 +1,4 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Getting started](GUI-Getting-Started) > Building the GUI
+# Building the GUI
 
 Before building and running the GUI please make sure you have followed the steps from here: [First time installing and building (Windows)](First-time-installing-and-building-(Windows)). In particular make sure Git and genie_python are installed.
 

doc/uncategorised/GUI_development/Eclipse/Common-Eclipse-Issues.md renamed to doc/client/Common-Eclipse-Issues.md

@@ -1,4 +1,4 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Coding](GUI-Coding) > Connecting a view to a PV
+# Connecting a view to a PV
 
 See [An Introduction to Databinding](An-Introduction-to-Databinding) for a explanation of databinding.
 

doc/uncategorised/GUI_development/Eclipse/Common-Eclipse-Tasks.md renamed to doc/client/Common-Eclipse-Tasks.md

@@ -1,10 +1,10 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Coding](GUI-Coding) > Conventions
+# Conventions
 
 Contains the style and coding conventions for the IBEX GUI.
 
 **New conventions should not be added to this document without first being discussed at a 'Code Chat'.**
 
-# Style Conventions #
+## Style Conventions #
 
 Unless stated otherwise below we should follow the standard Java conventions for style where possible.
 
@@ -163,7 +163,7 @@ class Point {
 }
 ```    
 
-# Coding Conventions #
+## Coding Conventions ##
 
 A mix of IBEX specific and general Java coding conventions.
 

doc/uncategorised/GUI_development/Coding/Connecting-a-View-to-a-PV.md renamed to doc/client/Connecting-a-View-to-a-PV.md

@@ -1,4 +1,4 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Getting started](GUI-Getting-Started) > Development workflow
+# Development workflow
 
 ## Quick overview of workflow
 

doc/uncategorised/GUI_development/Eclipse/Creating-the-IBEX-Developer-Version-of-Eclipse.md renamed to doc/client/Creating-the-IBEX-Developer-Version-of-Eclipse.md

@@ -1,4 +1,4 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Coding](GUI-Coding) > [Instrument switching](Instrument-switching)
+# Instrument switching
 
 Instrument switching in the GUI uses an extension point. This means that the switch can take place in a central place but then each plugin which is interested can sign up to the switching event. This keeps a separation between the plugins and the instrument switching module; i.e. a plugin can be removed without changing the instrument switching code.
 

doc/uncategorised/GUI_development/Designing-for-Colour-Blindness.md renamed to doc/client/Designing-for-Colour-Blindness.md

@@ -1,4 +1,4 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Getting started](GUI-Getting-Started) > Maven and Tycho
+# Maven and Tycho
 
 The IBEX GUI is built using Tycho which is an extension of Maven designed for building Eclipse RCP products.
 

doc/uncategorised/GUI_development/Eclipse/Eclipse-RCP.md renamed to doc/client/Eclipse-RCP.md

@@ -1,6 +1,5 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Coding](GUI-Coding) > OPI creation
+# OPI creation
 
-# Introduction
 OPIs live in `ibex_gui\base\uk.ac.stfc.isis.ibex.opis\resources`
 
  - Start CS-Studio to create/edit an OPI (see `EPICS\CSS\master\start_css.bat`)
@@ -71,7 +70,7 @@ In case an OPI's PV_root is defined in its parent, you need to go where to the p
 | ---- | ------- |
 | PV_ROOT | Root for all PVs within an OPI |
 
-# Completing the OPI
+## Completing the OPI
 
 Add the IOC name with appropriate information, including macros to the xml file
 
@@ -91,12 +90,12 @@ Please follow [these guidelines](Synoptic-Icons) when specifying and creating ne
 
 The final step should be to send the OPI to the instrument scientists. If they don't approve it that is fine but it is good to get their response.
 
-# Testing
+## Testing
 
 To start and interact with a testing IOC see [Running (and testing) IOC](Running-IOCs)
 The easiest way to test this is to run IBEX-gui through the eclipse editor. Create a device screen and use this to test. The device screen can be refreshed (right click -> refresh) to display the latest changes made in CSS editor.
 
-# Debugging: No scrollbars
+## Debugging: No scrollbars
 
 Check if you have stray widgets. An example of a stray widget might have:
 
@@ -109,15 +108,15 @@ If you have a stray widget, it may prevent scrollbars from appearing on your OPI
 - XML sorter
 - Diff tool e.g. notepad++, winmerge
 
-# Writing to char waveform PVs and displaying char waveforms as strings
+## Writing to char waveform PVs and displaying char waveforms as strings
 
 CSS text input fields can write to char waveform PVs but needs to be set up in a special way. If you don't do this, the `NORD` field of the waveform will not be set correctly on write and the PV value will only be written successfully if NORD already has a large enough value.
 - Postfix the PV name with ` {"longString":true}` (note the space before the JSON). The final value in "PV Name" should look similar to the following: `$(PV_ROOT):ARBITRARY:SP {"longString":true}`
 - Ensure "Format Type" is "String"
 
 Note: If waveform PV is being attached to a multi-line text box then user will have to `ctrl-enter` to save their changes. 
 
-# Data browser Graph Creation
+## Data browser Graph Creation
 
 To make a databrowser graph on an OPI:
 
@@ -130,15 +129,15 @@ To make a databrowser graph on an OPI:
 1. Add a `Data Browser` monitor to your opi
 1. In properties in file set the file you have created
 
-# Activate tab
+## Activate tab
 
 If it's required to activate a tab from a synoptic via a macro: (See SKF G5 Chopper OPI as an example.)
 
 1. Put macro in local PV
 1. Create script that reads value
 1. Set active tab on tab container using `setActiveTabIndex`
 
-# Create a Local Enum
+## Create a Local Enum
 
 AS OF 05/02/2020 DOES NOT WORK.
 
@@ -154,15 +153,15 @@ Or set the items from a script:
     combo.setItems( [ "Ene", "Mene", "Muh" ] )
 ```
 
-# Enable and disable controls
+## Enable and disable controls
 
 If the enablement state of a widget (i.e. `enabled` property) is controlled as part of OPI logic, it can be made more obvious by also controlling its `transparent` property.
 
 See `\base\uk.ac.stfc.isis.ibex.opis\resources\mercuryiTC\enablement_of_controls.py` for examples of setting properties based on the value of a PV.
 
 Initial investigations centred on alternating the background colour of the control between e.g. `ISIS_Textbox_Readonly_Background` and `ISIS_Textbox_Background`.  However, although the logic and syntax were sound, the OPI didn't faithfully reproduce the requested colours.
 
-# Using OPI rules and external scripts
+## Using OPI rules and external scripts
 
 When implementing display logic for OPIs (such as toggling an objects visibility based on a PV value) our standards are: 
 1. Rules take preference over scripts for trivial logic

doc/uncategorised/GUI_development/Eclipse/Eclipse-logging.md renamed to doc/client/Eclipse-logging.md

@@ -1,4 +1,4 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Coding](GUI-Coding) > PV switching
+# PV switching
 
 If you are only interested in how to create PVs in IBEX with proper switching behaviour go to "Using the PV Switching".
 

doc/uncategorised/GUI_development/Eclipse/Eclipse-preferences.md renamed to doc/client/Eclipse-preferences.md

@@ -1,10 +1,10 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Coding](GUI-Coding) > Static analysis
+# Static analysis
 
 We are currently making use of 3 static analysis tools to help ensure the quality of our code: [PMD](https://pmd.github.io/), [FindBugs](http://findbugs.sourceforge.net/), and [CheckStyle](https://checkstyle.sourceforge.io/). These particular tools are mostly intended for use with Java programs and as such our main use for them is the Eclipse GUI project, though they are also used on some Java code in the main EPICS project (specifically the IOC log server).
 
 All of these tools have maven plugins which allow the analyses to be run as part of the maven build process, with the results being output to an XML file. Additionally, they all have Jenkins plugins which can consume the XML results files, producing reports and graphs within Jenkins and allowing you to track code quality trends over time. The Jenkins reports list all the specific violations which can be categorised in a number of ways and are listed with file name and line number as well as a detailed description of the problem.
 
-# Checkstyle
+## Checkstyle
 
 Checkstyle is designed to enforce a set of highly configurable coding standards. It supports a very large number of rules including ones relating to naming conventions, annotations, javadoc comments, poor coding practices, etc. That rules that Checkstyle will check for violations of may be configured in an XML file. 
 
@@ -76,17 +76,17 @@ Or for multiple warnings:
         return hours * seconds_per_hour;
     }
 ```
-# PMD
+## PMD
 
 PMD focuses on potential coding problems such as unused or suboptimal code, code size and complexity, and good coding practices. Some typical rules include "Empty If Statement", "Broken Null Check", "Avoid Deeply Nested If Statements", "Switch Statements Should Have Defaults", etc. PMD will produce far fewer warnings/errors than checkstyle, however they are typically far more important, indicating technical problems with the code rather than merely stylistic ones, and should therefore be fixed whenever possible/sensible.
 
-# FindBugs
+## FindBugs
 
 FindBugs detects similar types of problems as PMD, though it can detect many additional serious problems such as potential null pointer exceptions, infinite loops, and unintentional access of the internal state of an object (to name a few). Unlike PMD, which checks through the source code, FindBugs actually checks through the applications bytecode for potential issues. FindBugs tends to find a smaller number of more important issues.
 
 For both PMD and FindBugs, there are certain rules which, while generally sensible, may not apply to the project at hand. For example, on the Eclipse GUI project, FindBugs throws up a lot of problems involving writing to a static member from an instance method, however the Activator class in most Eclipse plugins make use of this construct.
 
-# Maven
+## Maven
 
 The tools may be run as part of a maven build by including them as plugins in the project's pom.xml. In the case of the Eclipse GUI, each plugin is included in the 'tycho.parent' pom.xml file, and is therefore used in every other project (Eclipse plugin) during the build.
 

doc/uncategorised/GUI_development/GUI-CSS.md renamed to doc/client/GUI-CSS.md

@@ -1,10 +1,10 @@
-> [Wiki](Home) > [The GUI](The-GUI) > [Testing](GUI-Testing) > [System testing with Squish](System-Testing-with-Squish)
+# Squish
 
-# Squish Licensing Information & Contact Details
+## Squish Licensing Information & Contact Details
 
 we have one floating tester subscription and one floating execution subscription licence. The execution subscription is used by a build server to run tests, the tester subscription is used by us to develop tests. We can have at most one developer writing tests at a time, but we can all install the software on our machines. I don't yet know how the license system works e.g. if one developer forgets to close squish on their system, does it block everybody until they do? Or is there some timeout? We will have to experiment. See `license server` below for more details. 
 
-# Set Up for local server
+## Set Up for local server
 
 1. Install SQUISH/JAVA WINDOWS from `<isis experiment controls share>\squish`
 1. Read and accept the terms and conditions if still correct
@@ -39,11 +39,11 @@ You may also need to install `psutil` and `mysql-connector-python==8.0.11` throu
 
 Once you have set up Squish via the steps above, you should be able to run a test suite to confirm everything is working. Note that you need the IBEX server running in the background, but not the client (which will be started by Squish when you run a test).
 
-# RDP to Server
+## RDP to Server
 
 It is possible to remote desktop to the squish server but when you disconnect you must use the "Disconnect from RDP" shortcut on the desktop. To do this you must be an Admin on the desktop.
 
-# Setup For Build Server
+## Setup For Build Server
 
 1. Install all the things needed for an instrument (Git, MySql, Java)
 1. Install Jenkins build system but run it from a command line.
@@ -60,7 +60,7 @@ It is possible to remote desktop to the squish server but when you disconnect yo
 1. Then disconnect the session using the shortcut on the desktop
 1. Leave the machine with an attached screen. I think this is needed to set the resolution when leaving remote desktop.
 
-# Creating a new Test Suite
+## Creating a new Test Suite
 
 1. Click File -> New test Suite ...
 1. New Test Suite:
@@ -72,11 +72,11 @@ It is possible to remote desktop to the squish server but when you disconnect yo
 1. Edit the test suite settings (select test suite in test suites tab. Then click on icon with blue spanner)
     1. Edit Object Map to be `..\objects.map`. You may not be able to do this from the Squish client depending on your version, in which case you can directly edit `suite.conf` in `/<System tests folder>/suite_<something>_tests/` (it should say `OBJECTMAP=..\objects.map`)
 
-# System Testing The IBEX Script Generator with Squish BDD Tools
+## System Testing The IBEX Script Generator with Squish BDD Tools
 
 The way we use Squish for testing the script generator is a bit different to the way we test the IBEX client. The method for testing is documented on the [System Testing The IBEX Script Generator with Squish BDD Tools](System-Testing-The-IBEX-Script-Generator-with-Squish-BDD-Tools) page. Some of the hints and tips from this page still apply e.g. using utilities such as `set_text_field`.
 
-# Creating a new Test
+## Creating a new Test
 
 A test contains one test case.
 
@@ -102,7 +102,7 @@ A test contains one test case.
         <rest of test>
     ```
 
-# Writing tests
+## Writing tests
 
 Hints, tips and gotchas for writing tests:
 
@@ -117,7 +117,7 @@ Hints, tips and gotchas for writing tests:
     1. Save it and check it works by clicking highlight object; button should flash red.
 * Often `test.compare` and `test.verify` in Squish provides logs that aren't very useful, please do add a `test.log` line to describe the error.
 
-# Other 
+## Other 
 
 ### Change Java that squish is using
 
@@ -166,13 +166,13 @@ Frequency | Test | Error
 2         | tst_can_add_edit_and_delete_block_to_current_config | `RuntimeError: Property read failed: exception: java.lang.reflect.InvocationTargetException () org.eclipse.swt.SWTException: Widget is disposed`  `Called from: C:\Jenkins\workspace\System_Tests_Squish\suite_configuration_tests\tst_can_add_edit_and_delete_block_to_current_config\test.py: 74`
 1         | tst_user_names_can_be_set | `LookupError: Object ':Experiment Details_Text' not found. Could not match properties:    isvisible for object name: ':Experiment Details_Text' Called from: C:\Jenkins\workspace\System_Tests_Squish\suite_experiment_details_tests\tst_user_names_can_be_set\test.py: 19 C:\Jenkins\workspace\System_Tests_Squish\global_scripts\experiment_details.py: 19`
 
-# License server
+## License server
 
 This was setup as per https://doc.qt.io/squish/setting-up-the-squish-floating-license-server.html on `control-svcs.isis.cclrc.ac.uk` in the directory `/usr/local/squish-licenceserver` the service is automatically started at boot time vis systemd, the file `squish-licenseserver.service` has the service details and is symbolically linked from the systemd `/etc/systemd/system` area. The log file is `/var/log/squish-licenseserver.log` and the service is running on the default port of 49345
 
 To restart the licence server process use `sudo systemctl restart squish-licenseserver.service` on the licence server machine
 
-# Troubleshooting
+## Troubleshooting
 
 ### Squish fails to run tests with an error in the C runtime library