Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorder Preset IDs #3929

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

AlvaroTorcato
Copy link

This pull request addresses issue #3773 . It introduces the functionality for sorting presets, laying the groundwork for potential drag-and-drop capabilities in the frontend in the future. For example, if there are three presets with IDs 1 to 3, and we want the preset with ID 3 to become ID 1, the preset with ID 2 will then move to ID 3, and the preset with ID 1 will shift to ID 2.

@geeh-xx geeh-xx mentioned this pull request Apr 25, 2024
@AlvaroTorcato AlvaroTorcato changed the base branch from main to 0_15 April 25, 2024 21:01
@AlvaroTorcato AlvaroTorcato changed the base branch from 0_15 to main April 25, 2024 21:02
Copy link
Collaborator

@blazoncek blazoncek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution but I do have some reservations.

First off, this needs to be based on 0_15 branch, not main.
Next, I do not see any API (JSON or otherwise) accompanying this "groundowrk", I would require at least JSON API to be present.
The other thing is inefficiency of reading entire preset into temporary buffer (which is inadequate BTW). As the presets should not change during rearrangement there is no need to read them into memory instead only ID should be rewritten inside presets.json (if the ID will not fit then make a copy using existing behaviour).

// Function to find the preset ID by its name
int findPresetIdByName(const char* targetName) {
String currentName;
byte maxPresetId = 251;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maximum allowable preset ID is 250, not 251.


// Check if the IDs are the same or invalid
if (oldId == newId) {
//Serial.println(F("Old ID and New ID are the same. No changes required."));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would require using DEBUG_PRINT macros or remove these comments.


// Determine the highest ID to dictate array size
int highestId = max(oldId, newId);
StaticJsonDocument<4096> *tempPresets = new StaticJsonDocument<4096>[highestId + 2];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why StaticJsonDocument? For dynamic allocations you should use PSRAMDynamicJsonDocument.

The other thing is the limit to 4k. That's not enough. At minimum it should be the size of JSON_BUFFER_SIZE. Do not forget, you can store PixelMagic images inside preset.

String presetName;
if (!getPresetName(i, presetName)) {
//Serial.println("Error reading preset name for ID: " + String(i));
presetName="ERROR READING NAME";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not all presets have name. Some do not use name at all.

tempPresets[newId] = tempPresets[highestId+1];

// Save all modified presets back to the filesystem
for (int i = 1; i <= highestId; i++) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is very inefficient and prone to flash corruption we are fighting since 0.11.

@@ -81,7 +171,8 @@ static void doSaveState() {

bool getPresetName(byte index, String& name)
{
if (!requestJSONBufferLock(9)) return false;
//had to remove this so the rearange presets would work
//if (!requestJSONBufferLock(9)) return false;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a showstopper, unfortunately.
As ESP32 & S3 are dual core, concurrent use of JSON buffer needs to be prohibited. That's the purpose of requestJSONBufferLock(). If lock cannot be acquired you cannot be sure that pDoc points to a valid JSON buffer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants