insertcreativityhere / galp Goto Github PK

Right now only sessions support being exported in a binary format (as opposed to csv files and/or directories) via serialization.

In the future it may be worth adding support for experiments and trials to also be exportable in this fashion. Maybe with a custom scheme instead of serialization even.

Perhaps even DataBuffers should be allowed to be exported in this fashion? But maybe that's too crazy.

While loading save files, we always check that the version baked into the file matches the current version of the program, and if it doesn't we throw an exception.

It's somewhat of a moot point right now, since there's only 1 version of the encoding it could possibly be, but in the future, support should be added for loading older save files and automatically converting them into a new format.

Right now, all data is constrained to fitting into a hierarchy of:

• Session
  • Experiment
    • Trial
      While this is an ideal format for the way that the physics lab is run, this in general may be too restrictive for general use. To solve this problem, we should introduce a new data-object type of 'OneOff' which would function as a single fully-contained trial, and that would be place-able anywhere within the hierarchy.

Right now we only support sensor identification using raw voltage readings, but some sensors support identification and communication with the I2C Wire protocol.
It would be nice to add this one day, so the interface could identify all sensors, instead of only those that use the ID voltage line.

This logic should be added to the handleAnalogSensorIDReading function.

Right now when an interrupt from the ADC is missed, we report an error and ignore it. It might be nice to instead retry the last reading before taking another one.

In the navigation panels we check for whether popup-menus should be shown in both
mouseReleased and mousePressed. On some systems, this may result in the menu being displayed twice if the user presses and releases.

Currently we have no mechanism for calculating, or displaying the current progress while saving, exporting, loading, and importing data from files. Having such an indicator might be useful feedback to display to users when they're working with large files.

The default split bar is pretty ugly looking, we should instead change it so that instead of having the default split bar, users can use the actual "Data Explorer" label to adjust the split position.

The current rendering strategy for graphs is to clear the graph display, and redraw it from scratch everytime with calls to drawLine(...)

It might be worth looking into instead rendering everything onto a BufferedImage and 'scrolling' it instead, so that instead of redrawing the graph everytime from scratch, we'd only have to paint 1 extra line to the BufferedIMage, then perhaps 'scroll' it before displaying, which may be more performant.

We should add formatting into the display strings passed to these methods.

The list of supported sensor IDS in fast.h should be looked over again. There's likely sensors that shouldn't be included but are still in the list, and sensors that should of been included that aren't.