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 GI/glib though. >> PREFIX/share/mypaint/brushlib/__init__.py >> PREFIX/share/mypaint/brushlib/brushsettings.json >> PREFIX/share/mypaint/brushlib/brushsettings.py > > JSON definitions of the brush settings; a runtime requirement for > using libmypaint, and a Python interface to it. Both could be used by > apps other than MyPaint. I intend to package these and the .mo files > below as libmypaint[-brushlib], describing it as an > architecture-specific requirement for programs statically linked with > libmypaint. Hope that's right. One does not need these to use libmypaint, the C interface provides information about brush settings (based on data generated from the .json file at build time). See mypaint-brush-settings.h (and -gen.h for the enums). In MyPaint we use brushsettings.py mostly because it gives a more convenient interface for use in Python. And we currently don't have access to the whole libmypaint API on Python level. Its shielded behind the C++ wrappers in lib/ The .json file is the canonical data source for brush settings though, so I think that should be available. Post MyPaint 1.1 we should it to PREFIX/share/libmypaint/ though. brushsettings.py I don't really want to promote as public interface. >> PREFIX/share/mypaint/brushlib/generate.py > > This file appears to be here in error, and I'll probably be removing > it from the packages. It's used at compile time for constructing the > -gen.h files, and that's it. If I understand recent changes in master > correctly, it's being replaced by a scons Command. Yes, no need to install this file. The scons change only affects how the file is executed during build, so it will continue to exists and we should exclude it from install. >> PREFIX/share/locale/fr/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/id/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/ru/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/pt_BR/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/nn_NO/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/ro/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/en_CA/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/pl/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/it/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/cs/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/ja/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/zh_TW/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/zh_CN/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/sl/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/ko/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/uk/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/de/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/hu/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/sv/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/nb/LC_MESSAGES/libmypaint.mo >> PREFIX/share/locale/es/LC_MESSAGES/libmypaint.mo > > As described above: runtime requirements, packaged with the JSON > stuff. GNU message catalogs appear to be endian-specific, so > libmypaint[-brushlib] will be marked as architecture-specific for this > reason and in expectation of a .so version, and whatever gir magic is > needed. Sounds fair, though I don't know about the endianess issue. Debian people will probably. I believe Debian policy requires .gir files to be packaged separately. >> PREFIX/lib/pkgconfig/libmypaint.pc >> PREFIX/lib/libmypaint.a > > Compile-time requirement for programs statically linked with > libmypaint[-brushlib], part of the -dev package. ACK -- Jon Nordby - www.jonnor.com _______________________________________________ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
