linse/seweb
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updated README

Browse Source
This commit is contained in:
l_samenv
2024-09-10 10:33:08 +02:00
parent 08191991d0
commit 784d3f16fc
1 changed files with 104 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

109
README.md
View File

@ -2,7 +2,14 @@
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)
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
@ -12,10 +19,58 @@ This repository contains the code of the server for the control and graphical pa
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 !!!)
@ -24,19 +79,63 @@ This repository contains the code of the server for the control and graphical pa
2. If not done yet, activate a Python environnment
3. Run the command `cd seaweb`
### Configuring the application (!!! WIP !!!)
### Configuring the application
### Starting the application (!!! WIP !!!)
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
## 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
- The 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.
- 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.
### ... in the features
- 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.