hi Jon
Nice progress with brushlib!
No objection to convert MyPaint's .myb to json as planned.
About dict vs list: IMO if we have a high-level structure like json, only a
dict makes sense. The index is only required internally, for fast C array
access.
About base64-encoded PNGs: I think the current two-files approach works very
well: power-users immediately know how to edit the preview in an external
application, the textual .myb files are easy to handle. Brushes are never
shared individually anyway, but only as a whole collection (ZIP).
Collected notes about extensible settings:
There are some settings ('restore_color' and 'lock_alpha') that are not
handled by brushlib at all. How will the application access them?
The experimental blend_modes4-style brush modes also requires a brush
setting with higher-level application support: it needs the ability to fetch
the composited image, not just the current layer. This is something that
most applications probably don't want to implement. Usage of blender will
probably require additional blender-specific settings, too. (#mypaint Jun
22 21:52:52 <LetterRip> so we would need to have additional fields that
mypaint and other brushlib users wouldn't recognize).
So in the long-term, I think what would be required is the ability to add
opaque brush settings at run-time. Those could depend on all the inputs.
Brushlib would calculate the mapping and just pass the resulting value(s) on
to the dabbing code.
As you know, MyPaint keeps an observable brush settings object around, which
acts as a "master", and the brushlib brush acts as a "slave" storage of the
currently active brush settings. With the proposed change, either MyPaint
will have to fetch the loaded brush settings back from brushlib, or it will
have to parse the json itself and use the current API to update the slave.
(The current API or something very similar is still required to exist
anyway, since you hardly want to generate and parse a whole json for every
motion event, when a slider or curve point is dragged with live preview.)
I would also suggest that we stop saving settings that are at their default.
I have introduced the code to save everything at some point because I wanted
to change the default of one setting and was annoyed that it changed all the
old brushes - but I think it was a bad idea and really just clutters the
.myb files and makes them harder to edit/grep by hand.
About saving: I think applications that allow to save .myb files will have a
similar observer model like MyPaint. I'm still not a big fan of parsing
brushsettings in C (but I have no strong objection, neither), so I wonder if
it really makes brushlib users happy to use the brushlib API when dealing
with json files. Could you store a json list via the brushlib API, for
example?
About saving unknown attributes: not a good idea IMO. New brushes are
usually created by modifying an existing brush and then saving it under a
new name, which I assume would copy all unknown attributes. So if you have
an application that doesn't know the "License" attribute your new brush has
the same "License" as the old brush, even if you completely changed all
settings. Same problem with metadata like "modification date" or
"application name" or even "parent brush name". IMO better only save
attributes when you know what they mean, and drop unknown attributes when
loading. (Unless they are somehow marked or known as "safe to roundtrip".)
"Standardized attributes" is maybe a bit a big word for a library that is
called "libmypaint" ;-)
--
Martin Renold
_______________________________________________
Mypaint-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/mypaint-discuss
