Re: [Mypaint-discuss] Using brushlib in Blender
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
Re: [Mypaint-discuss] Using brushlib in Blender
hi Nicholas I think it would be desireable (and not hard) to get rid of the glib dependency. We can use C99 bool instead of gboolean (unless someone thinks it's too early to use a 1999 Standard already in the year 2012 ;-) The reason for using glib's random generator was because it can save its state. Is there a good replacement in the standard library? We probably could use random_r() or rand_r(). Are those portable enough? Regarding json brush settings, personally I would prefer not to parse this from C since the whole file and string handling (including unicode file names etc) is much easier from a high-level language like Python. Also, some of the stuff that we save into the .myb files (like restore_color and parent_brush_name) are actually handled on a higher level than brushlib. The disadvantage of that route is of course that brushlib is less self-contained. Regards Martin On Tue, May 22, 2012 at 09:41:10PM -0400, Nicholas Bishop 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. I have a few questions on the future of the brushlib: * How soon are the various goals mentioned in its TODO file expected? In particular, transitioning to the JSON file format and accompanying load/save code? * 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? I'd be happy to contribute patches to brushlib for TODO items and making integration with Blender easier; would be good to hear more on what existing plans are. Thanks, -Nicholas ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss -- Martin Renold ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Using brushlib in Blender
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. I have a few questions on the future of the brushlib: * How soon are the various goals mentioned in its TODO file expected? In particular, transitioning to the JSON file format and accompanying load/save code? * 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? I'd be happy to contribute patches to brushlib for TODO items and making integration with Blender easier; would be good to hear more on what existing plans are. Thanks, -Nicholas ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
