On Wed, Mar 12, 2008 at 9:21 AM, Alexia Death <[EMAIL PROTECTED]> wrote: > On Tuesday 11 March 2008 21:46:41 Joern P. Meier wrote: > > I have been looking at the GIMP code recently to look for > > possibilities of implementing some features that could make GIMP more > > useful for artists that create paintings from scratch (which includes me > > ;)). > Yay! Another art buff interested in brushes. > > > > A more powerful and flexible brush engine would be near the top of > > the list. > So true. > > > > This would likely also cover the SVG brushes (very appealing idea) and > > adjustable input curves proposals. > And dynamics,,, That's important too IMHO. Ability to bind any brush property > to one or more motion dynamics, primary or derived (speed, tilt,pressure, > angular speed, etc...) .
Angular speed? Do you mean 'turning speed', otherwise known as torque? > > > > Maybe someone with more insight into the code could give an outline of > > how it currently works? > > I am willing to invest some time studying the > > code myself, but unfortunately it is very scarcely documented and so I > > am not sure how the various components interact. > Gimp is large code wise. I opted for trying to understand the bits I'm > working > on and not the whole thing at once ;) > > I have been hacking in the event side of things since early this year and I'm > slowly starting to get a clue how things relate to each other. Perhaps best > for you to learn is to trace events stating from display shell callbacks to > the drawing code in various tools to get the overview you need? > > As I understand it now paint core handles most of painting related stuff, > different brush types are dervates of GimpBrush that overload the functions > in witch thy differ. Making a new brush type should not be that difficult, > but integrating it to UI... That part is a mystery to me. The UI is a mystery because no one has worked it out yet. The current design, with two places to control brush behaviour (brushes dialog, and brush editor) is clearly unsatisfactory. The design seen in mypaint is capable, and it uses up far too much space. Personally, I envision a GUI like [target selector] list | this of | source's sources | parameters [add] [remove] (keeping in mind that it would be very helpful for the dialog to be small enough to be a dockable. for example, the first item in Brian's first mockup would show like this [Opacity] Pressure % | CURVE | HERE The second would show up like [Size] Pressure -+ | CURVE | HERE  and the last would show up like [Angle] Direction =| CURVE | HERE  Doubleclicking on an item in the list of sources ought to allow it to be changed to another kind (different source, or different kind of modification). There should be a quick way to set a single constant value for the curve. shift+click? There should also be a quick way to enable or disable a particular adjustment Such a dockable should include targets such as size opacity hardness color from FG/BG (need way to specify opacity for color mix) color from gradient (see above) dissolve (yes, this sets a percentage of the pixels to transparent, just like dissolve does. I used this once in Pixia and found it a very useful fundamental adjustment) jitter (replacing the jitter options from paint tool options) rate/exposure (note: ignored for tools that have neither) airbrush pressure (note: airbrush normally inverts the size adjustment. how to account for this?) torque (as suggested by you, Alexia. Well, torque is the technically correct term, however none of the candidates, including 'torque', are very meaningful to a casual inspection.. the final name might be something different again.) and sources such as time (need some way to set length) -- this would allow you to do 'fade' in a more flexible way. speed tilt (note: this is a hardware-provided value, from eg. Wacom Intuos tablets) angle pressure This still leaves the matter of VBR editing and later, SVG brush editing. I think we could put them in an expander underneath the main part, in recognition of the fact that they are going to be accessed less often. We also need to ensure that only the things that really are specific to individual brush types go there. eg aspect ratio, rotation, hardness are things that make sense in context of any brush, not only VBRs or SVG. Oh yes, the UI separation of brush types.. IIRC it's more or less a hack (VBRs are the only editable type, and editing a brush brings up a VBR editor) When I get my system fully working again, I plan to prototype various UI possibilities in this area using PyGTK, and post the source+screenshots. A UI spec would be helpful, and probably not very possible until there is some UI to try. > > Also it would be nice to know if there are already more concrete plans > > for this (GEGL stuff?), or even if someone is already working on it. > Somebody is working on some gegl stuff but its not really usable yet as far > as > painting goes. Yes. At this point, it would be possible to implement eg. brush rotation using GEGL ops. That would be getting ahead of ourselves, I just want to point out that it is currently possible to do -- and would even be relatively simple. _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer