Import and Export patterns

[MidnightJava]

Added a button to export the current pattern on each matrix to a json file, and a button to import such a json file and apply it to either matrix.

[MidnightJava]

Tested import and export round trip. Also tested that malformed json does not cause an error on import. Tested a file with > 39 values, < 39 values, and values > 255. Attempt to import an invalid json file will make no change to the matrix, and an error will be logged on the console.

[MidnightJava]

Added a Persistence checkbox. When this is checked, the display will never sleep, as the app will send the wake command in the background periodically before the sleep timer fires.

[timoteuszelle]

Hi everyone,

Mark and I are working together on a LED matrix monitoring project that uses the Framework LED Matrix module as a status/indicator display. This PR (#11) is a great fit for the hardware side of that workflow, since it defines a clear import/export format for patterns that can be sent directly to the device.

To support the software side of the project (icon libraries, monitoring indicators, etc.), I’ve opened a follow-up PR #12:
#12

PR #12 is based on the current head of this PR and keeps all of the behavior here exactly as-is (39-byte hardware pattern format, UI, persist, wake loop). On top of that, it adds a separate “Export for Software” JSON export:

• Binary or grayscale (0–255) values
• Fixed column-major 9×34 layout that matches the LED matrix orientation and the icon format we use in the monitoring project

In practice, the workflow we’re aiming for is:

1. Use this tool to design patterns/icons on the matrix.
2. Use the existing import/export from Import and Export patterns #11 for hardware tests.
3. Use the new JSON export from Feature/software icon export on pr11 #12 to feed those same icons into the monitoring software.

If you prefer to keep things focused on the hardware workflow, you can merge #11 on its own. If you’d like the software-oriented export alongside it, you can merge #12 instead as a superset of this work. I’m happy to adjust naming or wording in #12 based on your feedback.

Thanks again for putting together the original import/export implementation—it's been very straightforward to build on.

[JohnAZoidberg]

Closing in favor of #12