The email went off-list, so I am quoting it in full here. On 26 May 2012 01:31, Nicholas Bishop <nicholasbis...@gmail.com> wrote: >> The overall goal of this is to make it easy for projects to use the >> MyPaint brush engine without having to "fork" the code (copy into >> project and change). And that when using the brush engine, they can >> use exactly the same brushes as MyPaint. I don't want a situation >> where there is Blender MyPaint brushes, GIMP MyPaint brushes and >> MyPaint MyPaint brushes... >> >>> In particular, transitioning to the JSON file format and accompanying >>> load/save code? >> >> I am busy this weekend, so the target for that is middle to late next >> week. I think we need to do this in the brushlib to achieve the >> overall goal. I don't think relying on all consumer of the brushlib to >> correctly read/write settings files (including handling newer and >> older versions compared to) is a good idea. >> The things that are not necessary for compatibility can be handled on >> a higher level. >> >> I will however not implement JSON parsing from scratch, so this means >> a libjson dependency (or similar). > > That all sounds good to me. Libjson is probably fine to add as a > dependency for Blender. > >>> * Will brushlib keep its dependency on glib? The use of glib seems to >>> have spread a bit, it's not just using it for g_rand but also types >>> and macros. For Blender we probably don't want to depend on glib, but >>> for now it shouldn't be too hard to patch it locally to work around >>> that. If brushlib starts using glib more extensively that could be a >>> problem though. Is there any interest in using regular C types rather >>> than glib's (e.g. replacing gboolean with int), or wrapping the >>> glib-specific parts in '#ifdef WITH_GLIB' or equivalent? >> >> If you really don't accept glib as a dependency, we would have to >> solve that of course (and without you having to patch it). > > I can't state with absolute certainty that we wouldn't ever accept > glib as a dep, but it's unlikely if its only usage in Blender would be > for the brushlib. > >> These are my worries for removing the use of glib, and my motivation >> for continuing the use of it: >> >> * Unicode/UTF-8 string, file and path handling. Mainly relevant for >> the brush setting handling. This is yet to be written, so I don't know >> how difficult/tedious it will be without glib. > > Perhaps these could be just function pointers and the parent > application provides the implementation? Blender has its own internal > file and string code, and this could work well for replacing the > g_rand() stuff too. > > -Nicholas
The JSON load/save handling is now basically done (see separate mail thread). I decided to punt on the file handling issues. libmypaint will only do serialization/deserialization of JSON, read/write to files is left to the applications. So no problem doing that without glib. I also added the gobject introspection based bindings build. Getting rid of glib while still letting that work looks to be easy as well. We will have to copy the gboolean and guint16 typedefs to keep the interface C89 compatible and for the binding scanner to understand it, but that is no problem. The g_rand usage will be replaced with a suitable PRNG implementation. There looks to be several available under liberal licenses that can be dropped in. One from D.Knuth for instance. So when I have time next week, the library should be able to build without glib. If you have time to test if there are any other issues for you using it in Blender before then, that would be much appreciated. -- Jon Nordby - www.jonnor.com _______________________________________________ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
