Version 7.0.0: Enhanced File Structure for Easier Use + New Example Page

[hm21]

Hi guys,

I’m excited to announce the upcoming release of version 7.0.0. While this update doesn’t introduce new features, it does include significant breaking changes due to a restructuring of the configuration files. I understand that breaking changes can be inconvenient; however, these updates are essential to improve clarity and ease of use, particularly for new users configuring the editor.

I currently spend between 2 and 4 hours every week answering the same questions because the previous file structure was not intuitive for users. I would much rather invest that time to fix issues and improving the editor. My hope is that this update will reduce the time spent on repetitive question answers and allowing me to focus on more impactful work.

The previous structure evolved over time, but as the package grew, it became increasingly complex—especially for standalone editor use. Many users have expressed confusion about locating and modifying specific settings such as icons, styles, or widgets. Below is an example of the previous structure:

{
    "#editorName":{
        /// editor configs
    },
    "imageEditorTheme":{
        "#editorName":{
            /// design
        }
    },
    "icons":{
        "#editorName":{
            /// icons
        }
    },
    "customWidgets":{
        "#editorName":{
            /// widgets
        }
    }
}

As the structure grew over time to support new features, it became harder to manage, especially for standalone use. Many users in the discussion tab also found it confusing to locate specific configurations.

Key Changes in Version 7.0.0

To simplify that problem, I’ve made two major changes to the configuration structure:

1. Renaming Theme Files to Style Files

In earlier versions, theme was used to define the editor’s design, a term that fit when we used fixed themes to mimic designs like WhatsApp. However, with the introduction of custom widgets, the term style will fit better. This change also aligns with Flutter’s convention of using style for widget design customization.

2. Consolidating Configuration into a Single File

All configurations for an editor are now grouped within the editor’s main configuration file, except for the i18n file. This change makes it easier to locate and manage settings. The new structure looks like this:

{
    "#editorName":{
        "icons",
        "style",
        "widgets",
        /// other configs
    },
}

Another small change I made is within the theme/style configurations. I renamed appBarForegroundColor to appBarColor and appBarBackgroundColor to appBarBackground. While Flutter uses the terms “foreground” and “background” for the appBar, it also uses simpler terms like “color” and “background” for other widgets. Additionally, web developers are generally more familiar with using color for text and background for background colors, making this adjustment more intuitive.

If any of you have difficulty with these changes or have suggestions for further improvements, please feel free to reach out to me. I’m always open to feedback and happy to help!

What come next

Before adding new features, I plan to make two important changes to the existing editor.

1. Improved State History

Currently, the editor's state history is functional but not well-optimized. The original implementation was designed for a previous project from myself where users needed to switch between templates. In that setup, the “state history” stored the full state information to enable switching, which later evolved into a quick state history solution. However, this approach stores far more data than necessary.

For example, an efficient state history system should store only the changes made, using an array of changes and an integer to track the current position for undo/redo functionality, like this:

[
  {"layer": TextLayer(...)},
  {"layer": EmojiLayer(...)},
  {"blur": 0.5)},
]

This method is efficient and minimizes the stored data.

However, because the editor was originally built with “templates” in mind, it currently stores the full data at each step, like this:

[
  {"layer": [TextLayer(...)]},
  {"layer": [TextLayer(...), EmojiLayer(...)]},
  {
     "layer": [TextLayer(...), EmojiLayer(...)],
    "blur": 0.5),
   },
]

This approach unnecessarily duplicates data by storing the entire state at every step, leading to inefficiency.
Currently, only the tune_editor supports the first, more efficient solution. All other editors still rely on the second, less efficient approach. My goal is to implement the optimized state history system across all editors to improve performance and reduce data usage.

At the moment, I believe these changes will not introduce any breaking changes. Additionally, the import-export functionality should remain backward compatible, as the exported history includes a version number to ensure compatibility with older versions. The export/import history will also be enhanced with new features, and the exported files will be significantly smaller after this update. If you’re curious about these changes, feel free to check out this PR from @saif-ellafi, which introduces some smart improvements that we plan to implement.

2. WebAssembly (Wasm) Support

The second major improvement will be adding support for WebAssembly (Wasm). If you’re unfamiliar with Wasm, you can learn more about it here.

When Flutter first announced Wasm, I explored converting the editor to Wasm. However, at that time, setting up web workers for multithreading—a crucial feature for the editor—was not straightforward. As a result, I decided to hold off on implementation.

With the release of Flutter 3.27.0, Wasm is now fully supported, and it’s possible to set up web workers. This capability makes it feasible to integrate Wasm support into the editor, which is an exciting step forward.

Final Thoughts

The editor has made significant progress, and you now have an idea of the next big planned releases. Don’t worry, though—I’ll continue to fix issues between major updates.

For smaller issues (those that take less than an hour to fix), I typically fix them within a week. Larger issues that require several hours of work will be handled step by step, as my free time allows. Since this is an open-source project, I hope you understand that some fixes may be delayed.

To help prioritize specific features or urgent bug fixes, I’ve created a GitHub Sponsors page. If you require a feature or need a faster resolution for an issue, you can sponsor me there, and I’ll make it a priority. Of course, even if you don’t sponsor me, I’ll continue to work on fixes—just at a slower, step-by-step pace.

Thank you for your understanding and support!

A big thank you to all the contributors who have helped improve the editor over time. Your efforts and support are greatly appreciated!

Made with contrib.rocks.

[saif-ellafi]

Sounds wonderful, thank you! Can't wait to test it and apply its changes (with particular care to backwards compatibility ;) )
Thank you for the amazing work and wonderful library!