Hi, Robin Rowe wrote: > Just so everyone knows, the GIMP has a different management style > than CinePaint and doesn't identify its team -- except for Yosh, > the GIMP release manager. Sven is perceived as the project manager > of GIMP.
I would like to clarify this - the GIMP is now 8 years old, 8 or 9 years old, and the original authors are long gone. What has happened since then is something of a co-operative effort, whereby a group of the current developers just kind of decide stuff. This is haphasard at times, but it would be incorrect to say that we don't identify our team. But the team changes very regularly. That is not to say that certain characters who have been around for a while do not have more credence than others. It might be worthwhile to keep an up-to-date list of current developers, along with their domains of interest/responsibility, but the GIMP's authors are publicly acknowledged in the AUTHORS file. I'm not sure how Sven feels about the title "Program manager" - if it helps you to label him as such, then so be it. He is one of the main developers around at the moment, and works more or less full time on the GIMP, so he has more say in contentious issues than blow-ins like me, but everyone is heard (often leading to bikeshed arguments, but there we go), and decisions get made more or less by concensus (which is a partly a factor in certain things taking longer than they might). > You are right that our gbr brushes are different from GIMP's. Although I > appreciate you considering it, they can't be made fully compatible with GIMP > because of bit depth. The best you could do would be to crush down to 8-bit > when opening our 16-bit brushes. As a proposal for a modification which would bring back compatibility, we could expand the header by 4 bytes to include bit depth (8 or 16), which could then be factored into the load routines of both our apps (we would crush 16 bit nbrushes down to 8 bits, and you would expand 8 bit brushes to 16 bits). As a file format change, it would allow is backward compatibility, since the format changes nothing in the other header fields. > By the way, where would I find your docs for the GIMP gbr format? After reading this mail, I drew up a specification of the gbr format. It's fairly straightformward, and is obvious from the header files & source, but a text file documenting the format is no harm. I will put it in the devel-docs directory of the GIMP CVS, and attach it inline here (I believe that our list software, and probably yours, doesn't like attachments). Cheers, Dave. The GIMP Paintbrush File Format Version 2 (.gbr) ------------------------------------------------ HEADER ------ Bytes 0 - 3: header_size: Type: 32 bit unsigned int Value: size of brush header (28) + length of brush name Bytes 4 - 7: version Type: 32 bit unsigned int Value: The file format version. Currently Bytes 8 - 11: width Type: 32 bit unsigned int Value: Brush width Bytes 12 - 15: height Type: 32 bit unsigned int Value: Brush height Bytes 16 - 19: bytes Type: 32 bit unsigned int Value: Colour depth of brush. 1 = greyscale, 4 = RGBA Bytes 20 - 23: magic_number Type: 32 bit unsigned int Value: GIMP brush magic number. ('G' << 24) + ('I' << 16) + ('M' << 8) + 'P' Bytes 24 - 27: spacing Type: 32 bit unsigned int Value: Default spacing to be used for brush. Percentage of brush width. Bytes 28 - (header_size - 28): Type: char * Value: UTF-8 string - name of brush BODY ---- Size: width * height * bytes Type: uchar * Value: Pixel values (row-first) for brush -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer