Re: [Mypaint-discuss] Anatomy of brushlib/libmypaint for 1.1.0 (for the Debian packages)
On 6 January 2013 04:20, Andrew Chadwick a.t.chadw...@gmail.com wrote: I am considering splitting libmypaint out of the Debian packages I'm working on so that authors of other apps can depend on it more conveniently, and so that other packages can depend on just the lib (possibly only at compile time). Can I confirm a few details? Before we go into the details, lets get a few things clear on the higher level. Warning: long braindump. My intent with libmypaint is that it shall be very easy to: 1) Add support for MyPaint brushes in an existing application. A user that wishes to use the same brushes as he does in MyPaint should be able to do this in all other libre graphics software that offers painting. Krita, GIMP, Blender have all expressed interest. 2) Create new applications with excellent painting tools for purposes and visions different from that of MyPaint. Examples include applications for animation, storyboarding, etc. or applications targeting other device form factors like tablets, smartphones. I envision two primary configurations of libmypaint to address this. 'minimal', mainly targeting usecase 1). Static C library whos only dependency is json-c for loading/saving of brushes and libintl/gettext for translated brush settings. Applications can integrate the library by providing a way to store/retrieve tiles by implementing a MyPaintTiledSurface subclass, or may do the rendering themselves by implementing a MyPaintSurface subclass. A reference surface implementation backed by a fixed size linear buffer is provided as an example. 'full', mainly targeting usecase 2). Provide everything that 'minimal' does. Also provide a reference, production quality, surface backend based on GEGL. Uses GObject Introspection to access from any language supported by GI (Python, Vala, Javascript, ++). Can for instance be used together with gegl-gtk or gegl-qt libraries to enable basic painting applications in less than 200 lines of code. Status as of MyPaint 1.1 * All of the functionality described above is present. * 'minimal' is built by default. To build 'full' use scons enable_gegl=true enable_introspection=true * Both configurations are build by Jenkins. * There will be bugs. Particularly the functionality that is not used by MyPaint is not well tested. * No ABI/API promise. As others attempt to use the library, it may be that we need to adapt the interfaces. * How brushes can be shared between different applications has not been thought out. * Documentation is basically non-existent. For these reason I'd say that libmypaint is currently 'unstable'. I hope that by MyPaint 1.2 these things will be ironed out, but this will require other applications to pick up the library and give feedback. I would like people to do this by just bundle libmypaint with their application, as this makes it easy to use another version that the one released with MyPaint 1.1. But as the GNU/Linux world typically does not do/like bundling, I guess we need to accommodate use through distributions as well. So thanks for bringing that up, and now what you actually asked for. * Can I assume that the version number is the same as that of MyPaint? Yes, as long as they are released together. * Can I also assume that libmypaint is always built correctly as part of a normal MyPaint build (looks like I can)? Yes. MyPaint relies on it and shall use it in much the same way as any other consumer of it would. * Is it the authors' intent that only a static library, libmypaint.a, is available for 1.1.0? I am assuming this is the case. Yes. If you want something else, bundle. * Should the package name be libmypaint, or libmypaint-brushlib? I prefer the 'libmypaint' name. Debian policy will probably also have an opinion about this. * I am assuming that brushlib will be moving to a dynamic library soon in order to support GI-style introspection. Yes, I hope that the build provided by MyPaint will be the 'full' configuration for 1.2 as we move to use GEGL and PyGI/GTK+3. Other than the brushes (which I intend to package separately because the mypaint app uses them too), the following files are installed by a brushlib_only=yes build. That's a good starting point for thinking about this division. I intend to package the files as follows: PREFIX/include/libmypaint/mypaint-tiled-surface.h PREFIX/include/libmypaint/mypaint-brush.h PREFIX/include/libmypaint/mypaint-glib-compat.h PREFIX/include/libmypaint/mypaint-surface.h PREFIX/include/libmypaint/mypaint-config.h PREFIX/include/libmypaint/glib/mypaint-brush.h PREFIX/include/libmypaint/mypaint-brush-settings-gen.h PREFIX/include/libmypaint/mypaint-brush-settings.h PREFIX/include/libmypaint/mypaint-fixed-tiled-surface.h Headers for the static libmypaint.a, and only that, I assume. I'll bundle the entirety of PREFIX/include/libmypaint/** as part of a libmypaint[-brushlib]-dev package. ACK. The header in glib/ subdir should maybe not be installed when not building with
Re: [Mypaint-discuss] Subpixel painting attempt and brush stroke undo
I have rebased and pushed the first two of your commits into master. Let's build on that. Not sure if I'm happy yet with the last commit (the boolean). Are you working on a different approach? Also, strings are not frozen any more, it would be nice to have some explanation in the brushsetting tooltips (brushsettings.json) about what's actually having what effect now. On Sun, Dec 16, 2012 at 07:26:49PM +, kam1k...@gmail.com wrote: We can surely make snapping a slider which will basically lerp between snapped and non-snapped, but we still need something that will enable/disable the new aa algorithm, otherwise pixel-sharp dabs won't be possible, and the current workaround (aa=0 is no-aa, aa=0.001 is normal aa with little feather) is asking to confuse users IMO. On 16/12/12 16:23 Martin Renold wrote: On Sun, Dec 16, 2012 at 02:38:09PM +, Micael wrote: Maybe we should create a new slider for enabling/disabling the AA+snapping (0.5 is disabled, =0.5 is enabled) for now while we don't have the ability to create checkboxes? I don't see the lack of checkboxes as a limitation, it's more an encouragement to create smooth brushsettings that can be mapped to any input without creating glitches. Actually it's not so hard to think of something between fully snapping to integer pixels and not snapping at all. If this seems all too complicated, at the very least we can make in-between values stand for the per-dab probability to snap. -- Martin Renold -- Martin Renold ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Subpixel painting attempt and brush stroke undo
Thank you. I'm not very happy with the boolean commit either, specially since it doesn't solve the problem without introducing other problems. I think I have an idea on how to make it work with a single float value - brush-configurable - that will enable linear interpolation between no-aa and aa-approximation, and I will try to make it work ASAP, as well as adding an appropriate description to the new setting. Regardless of this change I purpose renaming the current antialiasing field to feather though; I believe that's much more appropriate and artists are already familiar with that term and what it does. On Sun, Jan 6, 2013 at 5:11 PM, Martin Renold martin...@gmx.ch wrote: I have rebased and pushed the first two of your commits into master. Let's build on that. Not sure if I'm happy yet with the last commit (the boolean). Are you working on a different approach? Also, strings are not frozen any more, it would be nice to have some explanation in the brushsetting tooltips (brushsettings.json) about what's actually having what effect now. On Sun, Dec 16, 2012 at 07:26:49PM +, kam1k...@gmail.com wrote: We can surely make snapping a slider which will basically lerp between snapped and non-snapped, but we still need something that will enable/disable the new aa algorithm, otherwise pixel-sharp dabs won't be possible, and the current workaround (aa=0 is no-aa, aa=0.001 is normal aa with little feather) is asking to confuse users IMO. On 16/12/12 16:23 Martin Renold wrote: On Sun, Dec 16, 2012 at 02:38:09PM +, Micael wrote: Maybe we should create a new slider for enabling/disabling the AA+snapping (0.5 is disabled, =0.5 is enabled) for now while we don't have the ability to create checkboxes? I don't see the lack of checkboxes as a limitation, it's more an encouragement to create smooth brushsettings that can be mapped to any input without creating glitches. Actually it's not so hard to think of something between fully snapping to integer pixels and not snapping at all. If this seems all too complicated, at the very least we can make in-between values stand for the per-dab probability to snap. -- Martin Renold -- Martin Renold -- Micael Dias ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Subpixel painting attempt and brush stroke undo
Ok, I've implemented snap-to-pixel as a brush setting. It is now possible to get 1 pixel wide brushes, so the pixel brush works fine now. https://gitorious.org/~mdias/mypaint/mdiass-mypaint Single dabs' shapes are also quiet predictable when full snapping is on, instead of slightly randomized, which may be useful in some special situation. The code actually snaps 2 slightly different things; the actual dab's position, and the dab's radius. I'm currently using only one setting for both, as I'm not sure if there could be a need to snap the brush's center and the radius separately. It's a pretty simple thing to add, I just don't want to carelessly add new settings... On Mon, Jan 7, 2013 at 1:29 AM, Micael kam1k...@gmail.com wrote: Thank you. I'm not very happy with the boolean commit either, specially since it doesn't solve the problem without introducing other problems. I think I have an idea on how to make it work with a single float value - brush-configurable - that will enable linear interpolation between no-aa and aa-approximation, and I will try to make it work ASAP, as well as adding an appropriate description to the new setting. Regardless of this change I purpose renaming the current antialiasing field to feather though; I believe that's much more appropriate and artists are already familiar with that term and what it does. On Sun, Jan 6, 2013 at 5:11 PM, Martin Renold martin...@gmx.ch wrote: I have rebased and pushed the first two of your commits into master. Let's build on that. Not sure if I'm happy yet with the last commit (the boolean). Are you working on a different approach? Also, strings are not frozen any more, it would be nice to have some explanation in the brushsetting tooltips (brushsettings.json) about what's actually having what effect now. On Sun, Dec 16, 2012 at 07:26:49PM +, kam1k...@gmail.com wrote: We can surely make snapping a slider which will basically lerp between snapped and non-snapped, but we still need something that will enable/disable the new aa algorithm, otherwise pixel-sharp dabs won't be possible, and the current workaround (aa=0 is no-aa, aa=0.001 is normal aa with little feather) is asking to confuse users IMO. On 16/12/12 16:23 Martin Renold wrote: On Sun, Dec 16, 2012 at 02:38:09PM +, Micael wrote: Maybe we should create a new slider for enabling/disabling the AA+snapping (0.5 is disabled, =0.5 is enabled) for now while we don't have the ability to create checkboxes? I don't see the lack of checkboxes as a limitation, it's more an encouragement to create smooth brushsettings that can be mapped to any input without creating glitches. Actually it's not so hard to think of something between fully snapping to integer pixels and not snapping at all. If this seems all too complicated, at the very least we can make in-between values stand for the per-dab probability to snap. -- Martin Renold -- Martin Renold -- Micael Dias -- Micael Dias ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
