search

dlktdr / HeadTracker

This project is built to record the orientation a FPV headset to allow the camera on your RC to follow your head movements.
GNU General Public License v3.0
378 stars 90 forks source link

Data model of the GUI application #107

Open kobelev-tech opened 2 years ago

kobelev-tech commented 2 years ago

The GUI application is very similar to a classic editor of application specific data. Classic editor has memory buffer. User can load his data there, modify it using various controls and save the results of editing. This particular application has this structure: image

There are 2 possible approaches to make the design consistent:

a. Treat the connected board similar to a data file. In this case it is separate from the memory buffer. Application should allow same operations like it allows on the .ini file. Application should allow full editing of configuration without any board. b. Treat the contents of the board and the memory buffer as the same thing. I.e. the buffer should be not existing when the board is not connected.

Existing design is much closer to the second case, but it is not exactly there. Let me give an example why:

  1. Start the app without connecting anything
  2. Modify the limits, gain, channel. All these controls are enabled on the main screen.
  3. Save the settings. I am not getting any error. The file is created.

In this scenario I do not have any board at all, but still I can use this application as an editor.

To make the design consistent, it is necessary to:

  1. When the board is not connected, hide the Reset Center button, IMU Output - Local Board panel on the main screen. The graph at the bottom may be still displayed.
  2. Block loading and saving settings when the board is not connected. There is no buffer when there is no board.
  3. Do not allow to open Diagnostic Display and Channel Viewer when the board not connected and close these windows on disconnect.

Not sure, maybe if this is already so:

  1. Application cannot connect to an unprogrammed board.
  2. Programming puts the initial state of settings into the board. If this is so, then there will be no default settings on the picture above. Application will always start from something taken from the board.

It may look like that what I am writing is not important. Might be. My software background does not allow me not to write about this. Consistent design is consistent design. This is what the software is all about.

It does not look like this issue requires a lot of changes.

dlktdr commented 2 years ago

Agree, that it would be good to use this as an editor too.

The GUI was originally built to support more than one board, which switched the layout a bit on connect dependent what was detected. This would cause a issue, what GUI should come up when you start editing? Although I think I can remov this now. I don't have any intention to support the other firmware it could connect to anymore, it probably doesn't work great anyway, been a while since I tested it.

Set defaults is already in Master, currently wipes the flash on the board and reboots. Re-sync happens on connect to the board defaults.

If you see something you would like to change, by all means create a pull request too.