Hi all, as has been discussed on and off a bit, it would be nice to move to JSON for storing the MyPaint brushes. This should make easier for alternative brush engine implementations (like the Javascript + HTML5 one) to reuse the brushes.
In addition I propose to move load/save into libmypaint (currently called "brushlib"). This is so that anyone using libmypaint are guaranteed to be able to correctly load and save MyPaint brushes correctly. == Data format == The data format is based on JSON, as defined in RFC4627 (http://tools.ietf.org/html/rfc4627). Files saved to disk shall have the extension ".myb", like before. The file contents shall be stored UTF-8 encoded. See the attached example for exact format (pretty printed). An open question is whether to change the individual setting format to be a dict with "base_value" and "inputs" instead of the current list. That would be a bit more explicit/readable? == Extensibility == New top-level key, value pairs may be added by applications. Application specific attributes must have the prefix "x_$appname_". Standardized attributes, as defined by libmypaint/MyPaint must not use an "x_" prefix. The currently standardized attributes are "version", "comment", "settings" and "parent_brush_name". An open question is whether "parent_brush_name" is considered MyPaint specific? Metadata that may be interesting to add in the future includes: - Brush preview/icon (as base64 encoded PNG for instance) - Name/email of creator - Description - Creation and modification date == Compatibility == - Brushes with old format will work in MyPaint, and be automatically migrated (backwards compatible) - Older MyPaint versions will not be able to open this new format (not forward compatible) - libmypaint will only be able to open this new format, not older. == libmypaint API == The proposed API for libmypaint is: void mypaint_brush_from_string(const char *); const char * mypaint_brush_to_string(); A roundtrip between these is guaranteed to preserve any non-recognized top-level attributes (application defined). This allows applications making use of libmypaint that wish to add or modify the additional metadata to do this by interpreting the JSON string before passing it on. Storing the brushes to disk is the responsibility of the application using libmypaint. == Implementation plan == 1. Add code to migrate to new format to MyPaint. 2. Migrate all the brushes shipped with MyPaint to new format. 3. Add code to libmypaint to load/save the setting brushes in new format 4. Document the format, as part of libmypaint 5. Use the libmypaint load/save code in MyPaint Any comments welcomed! Unless there are major objections I hope to complete this the next week or so.
slow_ink.myb
Description: Binary data
_______________________________________________ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
