# SEAWeb

The WEB GUI client of SEA.

This repository contains the code of the server for the control and graphical parts, plus the client code (HTML, CSS, JS).

**Summary**

- [Documentation](#documentation)
- [Obsolete files](#obsolete-files)
- [Procedures](#procedures)
- [Possible improvements to bring](#possible-improvements-to-bring)

## Documentation

```
./doc/
    blocks.tsv              <-- (DE) Indicates the position of the different blocks depending on the screen size
    client.md               <-- (ENG) Developper documentation about the client part
    message_chain.txt       <-- (ENG) Gives the message chain (API calls) for builiding the different blocks
    protocol.txt            <-- (ENG) Gives a summary of the different server response payloads
    Screen Shot sea.png     <-- A picture of the SEA GUI (for reference)
    server.md               <-- (ENG) Developper documentation about the server part
    variables_config.md     <-- (ENG) User/programmer documentation about configuring parameters for the graphical part
```

## Obsolete files

Here is a list of files that might be obsolete because the recent developments did not concern these files or they are just too old.

```
./client/
    cssFiles/
        SEAWebClientStart.css       <-- Used with SEAWebClientStart.html
    externalFiles/
        alertify.min.css            <-- Not referenced anywhere
        alertify.min.js             <-- Same
        Chart.bundle.min.2.7.2.js   <-- Same (old version of chartJS)
        Chart.bundle.min.2.8.4.js   <-- Same (old version of chartJS)
        Chart.bundle.min.patched.js <-- Same (old version of chartJS)
        chartjs-zoom new.js         <-- Same
        chartjs-zoom ticks.js       <-- Same
        chartjs-zoom-orig.js        <-- Same
        d3.min.js                   <-- Old library that was once used for the graphs
        mjs_plot_0_3_n.js           <-- Used in plotex.html
        oldswiper.min.css           <-- Not referenced anywhere (CSS for old version of Swiper)
        oldswiper.min.js            <-- Same (old version of Swiper)
        swiper.css                  <-- Same (CSS for old version of Swiper)
        swiper.js                   <-- Same (old version of Swiper)
        swiper.min.css              <-- Same (CSS for old version of Swiper)
        swiper.min.js               <-- Same (old version of Swiper)       
        swiper.min.js.map           <-- Same (map for old version of Swiper)
    jsFiles/
        SEAWebClientStart.js        <-- Used with SEAWebClientStart.html
    res/
        go_to_now.png               <-- Unused
        menu_white.png              <-- Same
        x_zoom_white.png            <-- Same
        y_zoom_white.png            <-- Same
    console.html                    <-- Used in main.html
    group.html                      <-- Same
    main.html                       <-- Served when the route /main is reached. Allow to test the queries independtly from user interactions. The new parameters for the different queries have not been added
    plotex.html                     <-- A test for graphics with the library mjs_plot
    SEAWebClientStart.html          <-- An attempt for making the instrument selection page, similar to SEA (marked as OBSOLETE)
    select.html                     <-- A test for an HTML table allowing instrument selection, similar to SEA
    touchtest.html                  <-- A test for the different JS events (especially touch* and click)
./doc/
    graphics_todo.txt               <-- Contains some old tasks to do for the graphics
    url for graphics.txt            <-- The urls given in this file (especially host:port) are not updated
instruments.json                    <-- Contains the list of arguments to use if the command used to start the server does not include them. See section "... in the code" for further information
seagraph.py                         <-- Its content is used if the server is run with the history from SEA, but some routes have changed or have been added that were not reflected in this file
```

## Procedures

### Installation (!!! WIP !!!)

1. Clone this repository on the `~` folder on your machine
2. If not done yet, activate a Python environnment
3. Run the command `cd seaweb`

### Configuring the application

All this can be done in the `config` folder :

```
./config/
    generic.ini             <-- Holds the configuration to apply for all instruments (applied first). For now (September 2024), this is only used for the charts
    influx.ini              <-- Holds the configuration of the InfluxDB instance that runs on this machine (pc16932)
    <instrument>.ini        <-- Holds the configuration to apply for this instrument (applied last). For now (September 2024), this is only used for the charts
```

For the `generic.ini` and `<instrument>.ini` files, go to `./doc/variables_config.md` for further information.

### Starting the application

1. Run the command `cd ~/seaweb`

2. Depending on if you want to start the right part or no, go to the file `./client/jsFiles/SEAWebClientMain.js`

3. Edit the line 79 : `(.treat("hideRightPart", "hr", to_bool, <value>))` by replacing `<value>` with `false` to have the right part, or `true` to hide it.

4. 
    To start the server without the right part and the history from InfluxDB (NICOS cache), run the command :

        `python ./seaweb.py type=influx port=<port> instrument=<instrument>`

    With the right part :

        `python ./seaweb.py type=influxsea port=<port> sea=<sea_address> instrument=<instrument>`

    Where :   
        - `<port>` : the port of the machine to start the server with (for example : 8841)    
        - `<sea_address>` : the address of the SEA server (host:port) in order to have a running right part (for example : samenv:8664)   
        - `<instrument>` : the name of the instrument (for example : lab4)   

### Stopping the application

1. Run the command `ps ax | grep seaweb`
2. In the output of the previous command, identifiy the PID corresponding to the server process
3. Run the command `kill <previously_identified_PID>`

## Possible improvements to bring...

### ... in the code

- When the livemode is activated on the server, the data of all available variables is sent, even if some of them are not displayed on the client
- Some components made on the client use class instead of ids to identify the elements that are in their own context. To have a more lightweight code, and prevent side effects, it would be a good way to see if HTML shadow root could be used to isolate elements.
- The file `./instruments.json` should be moved in the `config` folder to have consistency in the file tree. It could also be removed, as there are now coniguration files, one generic and one instrument specific that could include these information. The arguments that should be given when the server is started are the port and the instrument name. This is already the case when the server is started without the right part, as the `sea` parameter is not needed.
- Some commented code and prints/console.log are still present, that does not make code reading easy. They should be removed.

### ... in the features

- For the moment, with a server started with `influxsea` or `influx` type, the device name is updated as described in the section "About instrument and device name" in the `client.md` file. The problem is that it is not possible to identify a portion of a device (for example the stick) which is no longer there (there is no way yet to have a `expired=False` tag on these measurements). This has to be discussed to know how to manage this problem.
- For the curves settings :
    - The table could display all the curves which are available, including those hidden by some configuration file on the server, meaning that we display all the curves with the parameters "value" and "target", even if hidden, plus the manually added parameters (like raw, for example) from the server or the user.
    - The bin item would then be a checkbox, and its column would have the signification "default". All curves which are retrieved from the server would have this checkbox checked, as it is the default content, and any newly user added curves should have it unchecked. When one of the value is changed, the checkbox would then be unchecked. Turning on the checkbox would have two effects : if the line comes from the server, its options are reset to those found on the server. If the line comes from some user configuration, turning on the checkbox would then set the category to "-".
    - When the curves settings are closed via the cross or via the "Apply" button, all the lines which are not checked as default would be saved to the web storage. This implies that the key (which is, by September 2024, a number) would be `<variable>.<param>`.
    - The "Add line" button could be variable related (so we could have one per variable), and would mean "add a parameter". The newly added line should have a dummy value for the parameter, which would mean that the parameter is still not yet chosen (we cannot say empty line because empty line means "value"), and the category would have the value "*". 
    - For choosing the color, the user should have the possibility to use a color picker to choose an arbitrary color, without loosing the possibility to choose one of the predefined color
    - Finally, for maitenance, an idea could be to have the possibility for an informed user to send its configuration to directly overwrite the `<instrument>.ini` file.
- For the export :
    - The binning option should be checked since the user changes the input.