Hi,

On the last day of LGM, the mypaint, gimp, tupi and krita people got together, originally to take the first steps towards integrating the MyPaint brush engine in our applications. This quickly led to a discussion centered on how to share mypaint brushpacks between applications, which got generalized into a design session on a bruskpack file format we can share between apps like krita, gimp and mypaint.

Here's the proposal, now that I've got network again:

Use-cases:

* we want a file format that can pack brushes into a single, complete package that artists can share, install and use directly.

* users can decide whether to download an e.g. mypaint brushpack and install it for mypaint only, or in a shared location so other applications that can use that brush type can load it as well. Sharing is opt-in.

Installation locations:

Following the create spec:

/usr/share/create/brushpacks: global location for shared brushpacks. If a distro creates a repo package of a brush pack, it should be installed here.

/usr/share/apps/$APP/...: global location for application-specific brushpacks. Here the brushpacks bundled with an application are stored

$HOME/$APP_DATA_DIR/...: e.g. .kde/share/apps/krita/brushpacks: here the user installs brushpacks that she doesn't want to share with other applications

$HOME/.local/share/create/brushpacks: here the user can install brushpacks they want to share between application.

On windows, the windows equivalents are used, on OSX ditto.

Brushpack format:

* A zip file that is unzipped on installation.

* The zipfile contains one or more toplevel directories: every toplevel directory is a brushpack in its own right. The application should use the directory name as a tag or identifier for the brushpack in the gui.

* the toplevel contains a manifest.xml file that contains author, copyright and license information.

* Allowed licenses are - proprietary
- public domain
- CC-BY-*

Example:

Oils

2013-04-06T17:12:10
2013-02-03T22:01:18
where you would get a new version public domain


John Doe
http://johndoe.deviantart.com

* The brushpack directories can contain a tags.xml file that contains tags for the containing brushes, following the gimp tagging format.

* A brushpack directory contains all the necessary subfolders following the CREATE spec with the necessary resources to create the brushes. It is up to the application to decide whether to show brush-specific resource (patterns, gradients, brush tips) in the generic gui.

Example:

deevad.zip for Krita contains

/manifest.xml /deevad/
/deevad/tags.xml
/deevad/brushes/gimp (contains .gbr files) /deevad/patterns (contains patterns for textured brushes) /deevad/gradients/ (contains gradient color sourcess) /deevad/krita_paintoppresets (contains krita paintop presets)

For gimp, it would be more like:

/manifest.xml /deevad/
/deevad/tags.xml
/deevad/brushes/gimp (contains .gbr files) /deevad/gimp_gdyn
/deevad/gim_gtp

For mypaint
/manifest.xml
/deevad/
/deevad/tags.xml
/deevad/mypaint_myb

Note that we didn't decide on a namespace/naming convention for the kpp, gtp, myb etc directories. It might also be good to fix brushes/gimp to follow any new convention (since brushes/gimp can contain abr, gbr, vbr and gih files, at least).

Brushpacks should not be mixed: so no mypaint brushes and gimp brushes in one brushpack.

Mimetype and extension:

mimetype: application/x-create-brushpack+zip extension: .brushpack

Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

On Tue, 16 Apr 2013, Alexia Death wrote:

Hi,

Brushpacks should not be mixed: so no mypaint brushes and gimp brushes in one brushpack.

Why this restriction

To make life easier for users. We discussed this a lot, but creating a brush pack that contains, for instance, both Krita and MyPaint brushes wasn't seen as desirable.

and why different internal formats

I'm not getting this question -- the formats are there because that's how applications define their brushes. Mypaint's .myb format is different from Krita's .kpp and Gimp's .gdyn.

and why such a complicated create folder format?

Hm... What do you consider the complications? Basically, it's just the equivalent of the way the create spec stores patterns, brushes, gradients etc. in separate directories, extended to allow new brush types that are not in create, like kpp, myb etc.

It would
be very simple to have a pack& create forder structure that allows for both mixed packets and for each app only handle what it can/need...

something along the lines of: /manifest.xml
/coolpack-cutes/tags.xml
/coolpack-cutes/shared/* - resources in common formats - svg, png, gif, whatever, as long as the format isnt app specific, pehaps subfoolders by resource intended use...

I'm not really seeing right away the improvement that adding a "shared" directory level gives above having the common resources in their already defined create directory names.

/coolpack-cutes/mypaint/* -stuff in mypaint format, acceptable to mypaint and dictated by mypaint /coolpack-cutes/gimp/* - stuff in gimp format, following gimp resource structure, subfolders for brushes, dynamics, etc
/coolpack-cutes/krita/*- stuff in krita format that only krita can understand

and same structure in create/ resource folder.

So, if  gimp starts supporting mypaint, all it needs to do, is dig into shared mypaint resources in create. Same goes for krita and for say mypaint getting a brush engine that lets it read gimp resources...

If I get you correctly, you'd prefer to copy a gradient or pattern that is used by a brush into the create-defined location for gradients or patterns? We decided against that because those gradients or patterns (or even the brush tips themselves) are only packaged because they belong to a particular brush and shouldn't be automatically made available as a shared gradient or pattern.

Boudewijn

On Tuesday 16 April 2013 Apr 15:51:17 Elliott Sales de Andrade wrote:

Following the create spec:

I guess this spec is new, since I don't see it on freedesktop's wiki.

Well, no, it's so old that it disappeared -- it was on the old create wiki which got deleted some time ago. People are working to put it up again.

/usr/share/create/brushpacks: global location for shared brushpacks. If a distro creates a repo package of a brush pack, it should be installed here.

/usr/share/apps/$APP/...: global location for application-specific brushpacks. Here the brushpacks bundled with an application are stored

My /usr/share directory is already subdivided by application-specific directories. Why do we need the extra 'apps' directory?

Sorry, this bit was unclear -- basically a brainfart, a combination of what was in my head for krita (/usr/share/kde4/apps/krita) and what's actually present. It's a bit messy, like everything, but what's meant here is, the place where resources packages with an application are usually installed, system-wise.

$HOME/$APP_DATA_DIR/...: e.g. .kde/share/apps/krita/brushpacks: here the user installs brushpacks that she doesn't want to share with other applications

Hopefully this .kde bit is just an old KDE thing, because it'd be nice if it followed XDG and was $HOME/.local/share/$APP.

That'll happen when KDE Frameworks 5 gets released and Krita gets ported to it. Or not -- I don't actually know :-) It's just where krita looks for stuff right now. Again, an example of an impementation detail.

* the toplevel contains a manifest.xml file that contains author, copyright and license information.

Shouldn't this be part of the brushpack? It seems like the directory is "the thing", and the zip file is just a convenient transport. * Say you install a bunch of zip files by extracting them to one of the directories above. Now the manifest.xml is just for the last zip file and you lost all the rest.

That's a good point. Mitch proposed that a brushpack always unpacks into one directory, with subdirectories -- maybe we should make that mandatory.

* Say you decide to move a brushpack from local to global. What do you do with manifest.xml? Do you even remember it exists? * Say someone makes a "super mega brushpack collection" containing several brushpacks from different authors (which may or may not be OK, but it depends on the license). I'd lean towards the brushpack authors being the ones who require credit and not the collection author (though the collection author might warrant some credit for finding all the brushpacks).

* Allowed licenses are
- proprietary
- public domain
- CC-BY-*

Isn't "public domain" kind of spotty in some regions? I thought that's why CC-0 was created. IANAL though; things may have changed.

Yeah. it is... We had the same discussion at LGM, but we put in public domain because it seems to have a real meaning at least in some places, and in others, like Germany, it gets interpreted according to intention.

In the end, we took http://wiki.mypaint.info/Licensing_policy#Brush_packs as our example.

Brushpacks should not be mixed: so no mypaint brushes and gimp brushes in one brushpack.

Depending on how many you download or create, this may or may not be annoying. I don't really know the differences, so maybe an artist wouldn't bother to create brushpacks for all three, but then again, maybe someone would, and it would be simpler to distribute them all in one file. Your first use case was a "single, complete package", after all.

Well, the idea is, we share the same format and structure so code needs to be written only once, but a pack is specific for a particular format. We didn't think it likely that people would create a pack with two krita brushes, two mypaint brushes and then some gimp dynamics settings, nor that an artist would go and create a set of brushes with the same effects replicated for different apps.

Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl