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 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".)
The point about preserving unknown attributes is just for libmypaint
when using the JSON persistence functionality (from_string/to_string).
The important thing is to not enforce policy. When an application
using libmypaint does a "add as new brush" or "save as new" action it
may be reasonable to strip all unknown attributes (as you mention).
The application is free to do that.
--
Jon Nordby - www.jonnor.com
_______________________________________________
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
