Remarks for the migration from ChartJS 2.9.4 to 4.4.4. TESTED ON SAFARI : with this new version, the application takes much less RAM, and does not crash at some point. The user can still experience some latencies, but it might be due to the presence of too many time axis labels + the fact that each graphs has its own (for the moment).

Here is a list of what has been done :

Upgraded the ChartJS zoom plugin library, and changed the corresponding options in the chart configuration. The previous version was not working with the version 4.4.4 of ChartJS
Installing the date library Luxon and its adpater for ChartJS. This is needed because since version 3.x, time axes need these libraries.
Renamed or moved all needed parameters in the ChartJS configuration.
Changed all xAxes and yAxes references to x and y.
Adapted afterBuildTicks callbacks with the new signature (only axis is given)
Changed all references to ticks.max|min : these two properties are one step higher, at the level of the axis, not the ticks
Change the implementation of the callback located in options.scales.x.ticks at chart creation in the Chart class, so it considers that the label is a timestamp. -> move code to afterBuildTicks Reference : https://www.chartjs.org/docs/latest/axes/labelling.html#creating-custom-tick-formats
improvment of labeling, using beforeFit instead of ticks.callback to modify labels
fixed flase cursor appearance when panning
Make the zoom type toggle work again.
Display only one time axis.

Here is a list of what needs to be done :

Make the zoom via touchpad less sensitive. The recent tests have shown that the zoom via gesture is very sensitive. Two things can be looked for : 1. see if there is the possibility to adapt the sensitivity of the zoom for the touchpad only or 2. update the library Hammer.js which is used by ChartJS to handle this type of gesture (even if the current version is 0.0.1 version later than the last one, this might be an explanation).

Summary

Documentation
Obsolete files
Procedures
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 !!!)

Clone this repository on the ~ folder on your machine
If not done yet, activate a Python environnment
Run the command cd seweb

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

Run the command cd ~/seweb
Depending on if you want to start the right part or no, go to the file ./client/jsFiles/SEAWebClientMain.js
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.
To start the server the history from InfluxDB (NICOS cache), run the command :
```
 `./secop-webserver port=<port> instrument=<instrument> hostport=<host:port>`
```
Dummy server (with dummy graphics):
```
 `./dummy-webserver port=<port> instrument=<instrument> hostport=<host:port>`
```
Where :
- <port> : the port of the machine to start the server with (for example : 8841)
- <host:port> : the address of the SECoP server - <instrument> : the name of the instrument (for example : lab4)

Stopping the application

If the server is started diretly in a Terminal: press ctrl-C

If the server is started in the background (with '&' appended to the command):

Run the command ps ax | grep webserver
In the output of the previous command, identifiy the PID corresponding to the server process
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

The application is experiencing some latencies after some time in live mode. This could be due to a memory leak from ChartJS. When the update of the graphs is triggered too frequently, with Safari, the RAM used by the application increases a lot. This has to be improved, maybe by updating the ChartJS library.
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.