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 _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
