On 2 June 2012 17:21, Martin Renold martin...@gmx.ch wrote:
hi Jon
Nice progress with brushlib!
No objection to convert MyPaint's .myb to json as planned.
Thanks!
I have pushed a branch json to the mainline repository now. This has
the code for supporting the new format in MyPaint, migrates the stock
brushes to this format and implements loading in libmypaint.
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.
I agree. I will make this change in above mentioned branch shortly.
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).
Yes, the current approach works OK I think. I don't really propose we
change that now. Though we should document it so that other
applications will work the same way.
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?
By reading/setting the attributes on the JSON strings passed to/from
the brush, or by using the mypaint_brush_{get,set}_base_value and
similar.
But if the brushlib does not use these, perhaps we should move them
out of the settings key and into the toplevel?
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.
This could be added to the vfuncs of MyPaintTiledSurface. So that
similar to get_tile/update_tile (which operates only on the layer)
there is a get_image_tile/update_image tile.
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.
You mean similar to the current custom brush setting? That one would
be able to add such settings at runtime?
That should not be a problem.
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.)
The current API is still there, and I don't plan to make any changes there.
Interactive applications will likely wrap the MyPaintBrush interface
in something that allows them to track changes in the different
settings. I don't see that as a big problem since the API is so small.
And I don't see a convenient way to implement such functionality in
libmypaint (at least not without using glib/gobject).
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.
I think we should continuing to store them, as I don't think it is
acceptable to change the brushes the user has already created by
changing the defaults in the library/application.
And being able to change the default in the lib/app can be handy.
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?
There is no generic JSON functionality exposed by the brushlib API. If
the application wishes to add additional attributes, that should be
done using whatever library the application prefers for manipulating
JSON documents.
The reponsibility of the brushlib is just to correctly
serialize/deserialize its own settings. And to not meddle with the
applications settings.
About saving unknown
