You could contact David Revoy and see if he could help you with the brushes. He's a digital painter and concept artist who also uses open source tools in his workflow. I see him contributing to many open source painting programs (e.g. Krita, MyPaint), especially with brushes and similar resources. For example here's a freely available brush set he made for GIMP painter:

http://www.davidrevoy.com/?article29/free-brush-kit-for-chaos-and-evolutions

He's also the author of Chaos&Evolutions DVD, a digital painting course using free/open source software. He should be a valuable addition if he agrees to help.

Regards,
Lamoot

On Tue, Jul 6, 2010 at 4:06 PM, Matjaz L. wrote:

You could contact David Revoy and see if he could help you with the brushes. He's a digital painter and concept artist who also uses open source tools in his workflow. I see him contributing to many open source painting programs (e.g. Krita, MyPaint), especially with brushes and similar resources. For example here's a freely available brush set he made for GIMP painter:

Hi Matjaz,

GIMP developer time is a scarce resource as it is. Martin went all the way to prepare terrain for this call for assets and post it here - -now is a good time for each subscriber to gimp-developer list to give a small contribution, if theres in o time or expertise to contribute with the development itself.
In this case, the help is as little as to forward the invitation above to artists you know. I am sure you could e-mail David Revoy yourself instead of asking Martin to do so.

Thank you for your colaboration!!

js ->

http://www.davidrevoy.com/?article29/free-brush-kit-for-chaos-and-evolutions

He's also the author of Chaos&Evolutions DVD, a digital painting course using free/open source software. He should be a valuable addition if he agrees to help.

Regards,
Lamoot

--
Matjaz L. (via www.gimpusers.com)

On 7/6/10, Martin Nordholts wrote:

Hi all,

If you would like better default resources in GIMP, now is a great opportunity to do something about it. We want GIMP 2.8 to ship with a good set of default resources, but we need help from our artist community with this.

This is perhaps quite offtopic, but if it was possible to save guides in GIMP templates, the existing collection of them could be improved as well.

Alexandre Prokoudine
http://libregraphicsworld.org

I don´t know if this helps, but there is already the GIMP GPS resources and I heard about GIMP painter, you could check with their authors to use what they have made, They would love having their work on GIMP.

Em Qua, 2010-07-07 às 06:58 +0400, Alexandre Prokoudine escreveu:

On 7/6/10, Martin Nordholts wrote:

Hi all,

If you would like better default resources in GIMP, now is a great opportunity to do something about it. We want GIMP 2.8 to ship with a good set of default resources, but we need help from our artist community with this.

This is perhaps quite offtopic, but if it was possible to save guides in GIMP templates, the existing collection of them could be improved as well.

Alexandre Prokoudine
http://libregraphicsworld.org

Von: Alexandre Prokoudine

This is perhaps quite offtopic, but if it was possible to save guides in GIMP templates, the existing collection of them could be improved as well.

https://bugzilla.gnome.org/show_bug.cgi?id=168541

HTH, Michael

I'll contact him directly then :)

Regards, Lamoot

Martin Nordholts gmail.com> writes:

Hi all,

If you would like better default resources in GIMP, now is a great opportunity to do something about it. We want GIMP 2.8 to ship with a good set of default resources, but we need help from our artist community with this. Right now, we would like to do the following:

* Add rake brushes * Add more bristle brushes
* Add more realistic patterns from commonly used artistic media * Add more complex vector based brushes because of their good scaling properties
* Add a selected subset of GIMP Paint Studio brushes and presets * Remove the outline squares
* Convert small bitmap brushes to larger variants * Either create better example brushes of GIMP's capabilities, or keep existing ones
* Make sure the new resources are properly tagged

I'm an artist and I'm willing to help. Who do I contact to organize this? I'll need some explanations on the technicalities (how to create vector brushes), what rake and bristle brushes are, and exactly what patterns are wanted. I can contribute my own patterns - I have a small library of patterns I find useful in my work, but i don't know if they have a general appeal.

hi all,

the reason I talked myself into the position of 'maintainer of default resources' (is that a title like 'floor manager' at mcdonalds?) at the LGM is that I voiced concern over how they can either enhance or sabotage the product vision:

to give a fictive, crass, but clear example: if somebody checks out GIMP because she is looking for a 'high-end photo manipulation application' and is confronted by 213 (well-drawn) clown face brushes, then we are in fact killing the GIMP project.

first of all, resources in GIMP are: - brushes
- patterns
- gradients
- palettes
- paint dynamics
- tool presets

so what are we looking for for each of these resources? well, apart from rule nr.1 formulated above (enhance the product vision? in; sabotage? out) I think it is either

1) the default resource is a 'must-have primitive' for the resource type.
simply cannot do without it. this is analogous to that a graphics program
'must have' a way to draw squares, rectangles, circles, ellipses, lines.

or

2) the default resource is general purpose, very versatile. example: a brush to paint grass is _not_. a brush that with some tweaking and combining can be used to paint grass, hair, fur, brushed metal and rain _is_.

or

3) the default resource showcases the depths and sophistication of the resource type. the stress here is on being educational and a starting point for users to make their own deep, sophisticated resources. I am not having high hopes for these defaults also to be 'must-have primitive' or 'general purpose, very versatile,' so there is not going to be a lot of them and they better be classy.

oh, and talking about classy, there is going to be a 'no cheese rule'. a Leopard pattern? no no no.

then here some notes for some of the resource types:

patterns a first look here tell me that application of the rules above will clear out (almost) the whole section. size matters here, large (thousands instead of 16–128 pix) patterns to avoid visible repetition.

the one thing I can think of we need pronto is one or more believable film grain patterns for photo manipulation.

gradients similar big cull coming

palettes the websafe/visibone stuff looks really deprecated in 2010. something like the Tango Icon Theme palette is an excellent example of a resource the fits with the product vision (GIMP is Free Software and a high-end application for producing icons).

paint dynamics paint dynamics are still fully in development, including the actual functionality. it is not useful at the moment to contribute paint dynamics presets.

one last thing: we have a green pepper problem. it fails several of criteria outlined above, but the GIMP team seems to be emotionally attached to it. similar to the GIMP name, we seem to wear it as a badge of honour. so I am 50/50 on in/out. this may prove to be the hardest decision of my career >^}

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

I have spent some time investigating this in order to ask intelligent questions but I give up, here goes.

I use Gimp for photography and as pre-press for presentations and web-sites. I am retired from a career of medical image processing, so I have a history and a library of C++ image manipulation routines.

I would like some new tools in Gimp and I've searched plug-ins and scripts. My first problem is that I am not comfortable that the tools I want don't exist rather than I just haven't found them yet.

What I'd like to do is:

* Rotate by an arbitrary angle. I've scanned an image but the page was not square in the scanner or camera. The best way to do this is to draw a line on the edge of the page and have a command that rotates it to horizontal or vertical. The algorithm is well defined and easy (except for indexed color images). * Draw arrows and shapes over an image (new vector layer). I found a shape drawing plugin that is fine except you fill in a form instead of draw the outline with a cursor, and it doesn't use the pen defined in the main window.

My questions:

* Do plug-ins like this already exist? * Would you write these as core, plug-ins, or scripts?

I did download and build 2.7.1 from sources and have a NetBeans project working for development, I've been using my compiled version. I'm exploring the sources and while I'm familiar with the algorithms for what I want to do, I have a long way to go figuring out where to hook in. I'd appreciate advice on documentation, and source modules to read.

Sorry for the newbie questions to the list.

Joe

On Mon, Jul 19, 2010 at 10:49 AM, peter sikking wrote:

hi all,

the reason I talked myself into the position of 'maintainer of default resources' (is that a title like 'floor manager' at mcdonalds?) at the LGM is that I voiced concern over how they can either enhance or sabotage the product vision:
(...)

one last thing: we have a green pepper problem. it fails several of criteria outlined above, but the GIMP team seems to be emotionally attached to it. similar to the GIMP name, we seem to wear it as a badge of honour. so I am 50/50 on in/out. this may prove to be the hardest decision of my career >^}

One thing that applies to to the pepper , but may ease the conflict of what should go in or not:
maybe the "default" resources could be tagged to "default" -- and instead of showing all items at program satrt=up, we could show just the "deffault" tagged items.

That way, the pepper, sun, wine brushes could go under a "bitmap" tag, but have no "default" tag attached. That would also make it easier to display just the wanted gradients - several of the gradients shipped with GIMP are used in tiny-fu scripts.

(as for the pepper per se, my personal opinion: I have no problem at all with it going away. I have _one_ "real" use for it: it helps me to locate the pixel brush, since it is next to it in alphabetical order. The "pixel" brush should, IMHO, be tagged "pixel" by default, so it can be found with less keystrokes)

js ->

On 19 July 2010 17:36, Joseph Areeda wrote:

Rotate by an arbitrary angle.  I've scanned an image but the page was not square in the scanner or camera.  The best way to do this is to draw a line on the edge of the page and have a command that rotates it to horizontal or vertical.  The algorithm is well defined and easy (except for indexed color images).

This was brought up recently, in the following thread http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg20264.html See especially the last email.

Draw arrows and shapes over an image (new vector layer).  I found a shape drawing plugin that is fine except you fill in a form instead of draw the outline with a cursor, and it doesn't use the pen defined in the main window.

See the branch soc-2006-vector-layers in git: http://git.gnome.org/browse/gimp/refs/heads IIRC, this has been dropped from the 2.8 schedule due to resource constraints. Half the gimp
world would probably love the people who finally gets this merged and polished up.

Thanks for opening this discussion, Peter.

On Mon, Jul 19, 2010 at 9:49 AM, peter sikking wrote:

hi all,

the reason I talked myself into the position of 'maintainer of default resources' (is that a title like 'floor manager' at mcdonalds?) at the LGM is that I voiced concern over how they can either enhance or sabotage the product vision:

1) the default resource is a 'must-have primitive' for the resource type.
simply cannot do without it. this is analogous to that a graphics program
'must have' a way to draw squares, rectangles, circles, ellipses, lines.

It is ironic that you made this statement, as it is the most often repeated criticism I see made about GIMP (how difficult it is to draw shapes). And this (IMOO) should be a requirement under product vision 'GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements;"

or

3) the default resource showcases the depths and sophistication of the resource type. the stress here is on being educational and a starting point for users to make their own deep, sophisticated resources. I am not having high hopes for these defaults also to be 'must-have primitive' or 'general purpose, very versatile,' so there is not going to be a lot of them and they better be classy.

Keeping a good example of GIH brushes is a necessity here, as it is one of the big features that I keep hearing PS users complain about _not_ having. Keeping the cheese factor down might be the issue. Personally, I'm a big fan of the ivy brush for this.

I'd also suggest a bokeh brush might be appropriate here(?) and probably some grunge type brushes which are good for photo-manipulations.

What is the status of vector brushes for 2.8?

then here some notes for some of the resource types:

patterns a first look here tell me that application of the rules above will clear out (almost) the whole section. size matters here, large (thousands instead of 16–128 pix) patterns to avoid visible repetition.

Having a small section of halftone/dither patterns would possibly be of value here.

I also keep a small 50% grey pattern to quickly build dodge/burn overlay layers when photo retouching. It is faster than having to open up the colour dialog and specifying 50% grey.

the one thing I can think of we need pronto is one or more believable film grain patterns for photo manipulation.

With resource tagging now a reality, is there any value in maintaining the .pat file type for these, or should they all be .png files with appropriate tags?

gradients
similar big cull coming

Regarding the "icon and web creation" purpose I'd suggest a number of "web 2.0" type gradients, providing gradients the complement what get chosen as default palettes.

Please keep in metallic gradients.

Regarding photo manipulation, I'd suggest a few cyanotype/duotone/tritone gradients that can be used with the gradient map filter.

palettes
the websafe/visibone stuff looks really deprecated in 2010. something like the Tango Icon Theme palette is an excellent example of a resource the fits with the product vision (GIMP is Free Software and a high-end application for producing icons).

I realize there are restrictions on pantone colours.... but there any GPL compatible alternatives for spot colours?

-Rob A>

On 7/19/10, peter sikking wrote:

first of all, resources in GIMP are: - brushes
- patterns
- gradients
- palettes
- paint dynamics
- tool presets

- templates

Let me say that the toilet paper one has caused a lot of unhealthy agiotage over the years worldwide :)

Alexandre Prokoudine http://libregraphicsworld.org

I hope you don't deem it inappropriate for a non-developer to input his opinion on a developing issue but I'd like to add that people who are really concerned about what GIMP can not do are certainly not concerned about the set of brushes, patter etc pp. shipped with GIMP. If there is something to work on in, especially the brushes section then it is improving the brush engine to give greater GENERIC flexibility - take a commecrical brush engine as an example - I only know the PS one and I think that's what's needed. Predefined pattern and brushes are useless from a certain extend on. They just bloat the list with things you will never use. As an artist (which I am hardly) I will surely refrain from using an oversized set of patterns and brushes. A decent amount of generic patters and brushes (bitmap) are very good - common things, mostly grain patterns - no one uses apparently repetetive patterns and diffuse irregular brushes which cannot be generated. But then on the brush
size, we need far more control over generic brushes. Again, look at PS.

On 07/19/2010 07:27 PM, Alexandre Prokoudine wrote:

On 7/19/10, peter sikking wrote:

first of all, resources in GIMP are: - brushes
- patterns
- gradients
- palettes
- paint dynamics
- tool presets

- templates

Let me say that the toilet paper one has caused a lot of unhealthy agiotage over the years worldwide :)

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Jul 19, 2010 at 10:52 PM, Cedric Sodhi wrote:

size, we need far more control over generic brushes. Again, look at PS.

Want to buy me a PS license and a Windows license? You still haven't taken a look at the current development status, have you?

On 7/19/10, Cedric Sodhi wrote:

If there is something to
work on in, especially the brushes section then it is improving the brush engine to give greater GENERIC flexibility

The brush engine is already actively being worked on. You probably missed all v2.6-v2.7 reviews. Go read them, or, better, try 2.7.1.

- take a commecrical brush engine as an example - I only know the PS one and I think that's what's needed.

Let's get it straight: are we talking about brush engine before or after CS5?

The Photoshop's brush engine *before* CS5 is not much different from the current GIMP's engine. There are not so many missing things in GIMP right now (like dual brush). I know that for sure, because I reverse-engineered brush dynamics in ABR.

The Photoshop's brush engine *after* CS5 -- now, that's a whole different thing, because Adobe is now trying to bite a piece of the pie that used to belong to Corel, SAI et al. The GIMP team seems to have agreed that Krita and MyPaint are doing a damn great job there already, so they [GIMP team] aren't going to do natural brushes or media simulation

Alexandre Prokoudine http://libregraphicsworld.org

I don't know PS after CS3, I heard it had horrible performance, by the way :) After all, I did not try to imply that the brush engine is being neglected and I needed to tell you to work on it, of course not. Just statet what I think is necessary, if that's already being approached, simply take it as an confirmation for your efforts.

On 07/19/2010 10:46 PM, Alexandre Prokoudine wrote:

On 7/19/10, Cedric Sodhi wrote:

If there is something to
work on in, especially the brushes section then it is improving the brush engine to give greater GENERIC flexibility

The brush engine is already actively being worked on. You probably missed all v2.6-v2.7 reviews. Go read them, or, better, try 2.7.1.

- take a commecrical brush engine as an example - I only know the PS one and I think that's what's needed.

Let's get it straight: are we talking about brush engine before or after CS5?

The Photoshop's brush engine *before* CS5 is not much different from the current GIMP's engine. There are not so many missing things in GIMP right now (like dual brush). I know that for sure, because I reverse-engineered brush dynamics in ABR.

The Photoshop's brush engine *after* CS5 -- now, that's a whole different thing, because Adobe is now trying to bite a piece of the pie that used to belong to Corel, SAI et al. The GIMP team seems to have agreed that Krita and MyPaint are doing a damn great job there already, so they [GIMP team] aren't going to do natural brushes or media simulation

Alexandre Prokoudine http://libregraphicsworld.org

Joseph Areeda wrote:

* Rotate by an arbitrary angle. I've scanned an image but the page was not square in the scanner or camera.

GIMP has a built-in tool that lets you rotate an image by an arbitrary angle. There is also a Script-Fu plug-in that you can use to straighten an image and crop the result. You can find it at http://registry.gimp.org/node/18821

I haven't tried the plug-in so I don't know how well it works, or even *if* it works in a current version of GIMP.

On 7/24/10, Kevin Cozens wrote:

Joseph Areeda wrote:

* Rotate by an arbitrary angle. I've scanned an image but the page was not square in the scanner or camera.

GIMP has a built-in tool that lets you rotate an image by an arbitrary angle. There is also a Script-Fu plug-in that you can use to straighten an image and crop the result. You can find it at http://registry.gimp.org/node/18821

There is also deskew plug-in that was once proposed to be included to GIMP's bundle.

http://registry.gimp.org/node/2958

Alexandre Prokoudine http://libregraphicsworld.org

I want to thank everyone who responded.

The AutoRotate script does what I want, pretty much.

I am studying Scheme, which looks adequate to handle my desire for drawing shapes to call out parts of screen captures.

Afterwards, I plan to start trying to comprehend the GIMP project, which seems necessary for drawing arrows.

I'm finding the documentation difficult. I don't mean that I don't understand the vast amount of work put into it nor the completeness of what's there.

I think my problem is more a matter of a beginner being overwhelmed by the size and the number of choices.

What I've found very helpful in other projects of this type is a community wiki, where a beginner like me can submit a "here's how I took my first step" tutorial. The problem is the first steps are incomprehensible until you take them, then they become trivial. People who know the project can't really think up the questions, although they are the ones with the answers. (Rereading that, I hope it makes sense to someone besides me).

Just for the record, I've been using GIMP almost exclusively these days and hopefully will be contributing to the project soon.

Joe

I have a few function on my must have list. I've been able to find some scripts that are close.

It's been over 20 years since I did any LISP programming so Scheme is not to bad, but still a chore.

My biggest issue is debugging. My searching has turned up this quote (http://adrian.gimp.org/batch/batch-7.html):

"Debugging Script-Fu scripts is only slightly less painful than stabbing yourself in the eye with a dull spoon.

There is no debugger for Script-Fu, and it tends to generate either no errors or pretty much useless errors."

That sums up my experience so far, but I'm looking for a more optimistic approach.

If anyone has any suggestions, I'd appreciate it.

---------- As a more long term fantasy, has there been any discussion of an RPC portal to the Procedure Database.

This would allow add-ons to be written in any language with a relatively small investment in each. The big plus for the developers of add-on would be the ability to use existing IDEs with a DEBUGGER.

This is a project I could sink my teeth into.

Joe

I just use (gimp-message) a lot, with my error console turned on.

Here are pointers that work well with script-fu (up to a point): http://www.cs.indiana.edu/chezscheme/debug/

Too bad script-fu doesn't support tracing.

-Rob A>

On Tue, Jul 27, 2010 at 3:09 PM, Joseph Areeda wrote:

I have a few function on my must have list. I've been able to find some scripts that are close.

It's been over 20 years since I did any LISP programming so Scheme is not to bad, but still a chore.

My biggest issue is debugging. My searching has turned up this quote (http://adrian.gimp.org/batch/batch-7.html):

"Debugging Script-Fu scripts is only slightly less painful than stabbing yourself in the eye with a dull spoon.

There is no debugger for Script-Fu, and it tends to generate either no errors or pretty much useless errors."

That sums up my experience so far, but I'm looking for a more optimistic approach.

If anyone has any suggestions, I'd appreciate it.

---------- As a more long term fantasy, has there been any discussion of an RPC portal to the Procedure Database.

This would allow add-ons to be written in any language with a relatively small investment in each. The big plus for the developers of add-on would be the ability to use existing IDEs with a DEBUGGER.

This is a project I could sink my teeth into.

Joe

Hello,

"Debugging Script-Fu scripts is only slightly less painful than stabbing yourself in the eye with a dull spoon.

indeed debugging gimp scripts is a pain and I encountered it several times. There are several ways to make it easier to follow the execution (defining some functions which will print all the arguments passed to other functions) but I'm unaware of any interactive debugging utility.

As a more long term fantasy, has there been any discussion of an RPC portal to the Procedure Database.

This would allow add-ons to be written in any language with a relatively small investment in each. The big plus for the developers of add-on would be the ability to use existing IDEs with a DEBUGGER.

As far as I know, there are some plans to introduce javascript as the new scripting language for GIMP. It was suggested for this year's summmer of code, but eventually other projects were taken.

If the suggestion to move to javascript is likely to happen anywhere in the near future, I'm not sure if it's worth it to try write a scheme debugger. Also, a note from the manual of tinyscheme (the scheme implementation GIMP currently uses):

Decent debugging facilities are missing. Only tracing is supported natively.

So basically, I don't see any trivial way to implement debugging into GIMP's scheme withou a serious re-write of GIMP's scheme. I have only two solutions which are a quick and ugly but they'll work:

1. On my first programming course in the university we learned scheme, and we wrote a scheme interpeter in scheme for learning purposes. I think I can hack it and add debugging features to it as I still remember it's code - then in order to debug a script, you would simply pass the script as a to a function called "mc-eval". I'll need to ask permission from my professor to distribute the code, but I'm pretty sure he'll agree.

2. We can connect an external scheme implementation which supports debugging (I have one which I wrote in java, and there are probably more better existing ones) and allow it to run the script itself. When it doesn't find a function, then it will invoke the aproppriate procedure from GIMP using a call to the PDB (since if a script uses a function which is not defined in it, it's probably a gimp procedure)

So, I see no way of implementing a scheme debugger in GIMP nativly, but there are two tools which we can connect externally to provide debugging options.
Back to javascript - I think that a debugger should be included on the project's todo.

These are my thoughts - tell me if any of them seem interesting enough to try.

~LightningIsMyName

Decent debugging facilities are missing. Only tracing is supported natively.

Anyone know how? Even that would be handy.

-Rob A>

Quoting Rob Antonishen :

Decent debugging facilities are missing. Only tracing is supported natively.

Anyone know how? Even that would be handy.

Call the 'tracing' function with an argument of "1" to enable tracing ("0" to turn it off). The output from the trace doesn't appear until the script finishes (not sure if this is always true) and it is extremely detailed (even the convenience functions such as 'cadr' are traced into as '(car (cdr x))'). Nonetheless, one can generally figure out what the problem is from examining the tail end of the trace log.

My recollection is that 'tracing' had some problems early on in the GIMP 2.4 cycle but, thanks to the efforts of the GIMP developers, it now seems to be working fine.

Using the example from the ChezScheme guide:

(define buggy-remove (lambda (x ls)
(if (null? x)
'()
(if (equal? (car ls) x)
(buggy-remove x (cdr ls)) (cons (car ls) (buggy-remove x (cdr ls)))))))

(tracing 1) (buggy-remove 'a '(a b a c a))
...
... Lots of output!
...
Eval: (if (equal? (car ls) x) (buggy-remove x (cdr ls)) (cons (car ls) (buggy-remove x (cdr ls))))
Eval: (equal? (car ls) x)
Eval: equal?
Eval: (car ls)
Eval: car
Eval: ls
Apply to: (())
Eval: (# "car: argument 1 must be: pair") Eval: #
Eval: "car: argument 1 must be: pair" Apply to: ("car: argument 1 must be: pair") Eval: (if (more-handlers?) (apply (pop-handler)) (apply error x)) Eval: (more-handlers?)
Eval: more-handlers?
Apply to: ()
Eval: (pair? *handlers*)
Eval: pair?
Eval: *handlers*
Apply to: (())
Eval: (apply error x)
Eval: apply
Eval: error
Eval: x
Apply to: (# ("car: argument 1 must be: pair")) Apply to: ("car: argument 1 must be: pair")Error: car: argument 1 must be: pair

Hello,

I contacted David Revoy and got a reply. He explained he doesn't feel GIMP 2.7 is stable enough for regular production work, which would allow him to develop a good default brush set through actual work. He also said his current brush set made for Chaos&Evolutions DVD probably won't fit directly in GIMP 2.8 due to all the advancements made to the brush engine between 2.6 and 2.8. It's a sort of a chicken&egg who-came-first problem. Stable GIMP -> develop stable brush set -> release stable GIMP.

However, he did make a proposal how he imagines a default robust brush set (and by the look of it, it appears very similar to the one made for Chaos&Evolutions). Here's his proposal:

http://www.pasteall.org/pic/show.php?id=4866

In addition, I'm giving you a link to his portfolio so you can see what kind of artistic background he's coming from and evaluate how his use-case vs. proposed brush set vs. GIMP product vision relate to one another.

http://www.davidrevoy.com/

Regards, Lamoot

On Sunday, August 01, 2010 11:45:19 Matjaz L. wrote:

I contacted David Revoy and got a reply. He explained he doesn't feel GIMP 2.7 is stable enough for regular production work, which would allow him to develop a good default brush set through actual work.

...snip....

It's a sort of a chicken&egg who-came-first problem. Stable GIMP -> develop stable brush set -> release stable GIMP.

I agree with him. Exact dynamics/brush set development is best left after we have the first RC out of the door. But baseline setting can start now. Adding basic simple things that are likely to be keepers and removing stuff we arent going to keep for sure.

--Alexia