On Wed, Mar 12, 2008 at 9:21 AM, Alexia Death <alexiadeath@xxxxxxxxx> 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 [1]
and the last would show up like
[Angle]
Direction =| CURVE
| HERE [1]
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@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
