On 23 May 2012 03:41, Nicholas Bishop <[email protected]> wrote: > Hi, > > I'm one of the maintainers of the sculpt/paint tools in Blender > (www.blender.org), and I'm looking into using the MyPaint brushlib. I > see that the library is transitioning from C++ to C, which is good for > us as Blender is mostly C.
Hi Nicholas, glad to hear you are interested! I'd love to see the MyPaint brush engine used in Blender. > I have a few questions on the future of the brushlib: > > * How soon are the various goals mentioned in its TODO file expected? If you look at the git log, you will see that I started the reworking around one week ago. I hope to complete the items on the TODO within the next two weeks. 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). > * 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). 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. * Easy generation of bindings for languages like Python, Vala, Javascript using gobject-introspection. Having g* types for the things that C89 cannot represent makes that just-works. We need to research how we can do that without using glib types. Any help in this area or the other items on the TODO would be most welcomed! -- Jon Nordby - www.jonnor.com _______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
