Re: [Gimp-developer] [Demo] Porting MyPaint brush engines to the GIMP.

[peter sikking <peter mmiworks net>]

sigetch wrote:

> MyPaint brush engine has three four advantages:
> 
> 2. It has 9 inputs, 42 setting parameters, and 30 internal states to
> determine the timing, position, size, color, and blend mode.

nice for you, but for users I would swear that this should show up
on the disadvantages list.

> 3. All parameters are defined as brush parameters, while in gimp,
> those parameters are not managed in one object,  brush dynamics and
> tool options manages some of those parameters.

true, presets management in painting is a mess right now.

> 4. Its implementation is very simple and well designed. This is the
> most important things for developers!

...but one million users do not care.

> And It has some disadvantages:
> 
> 3. It lacks paint mode at all. (But who uses the painting mode of the
> paint brush?)


can I point out the vision of the GIMP team?

<http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision>

within GIMP painting is _part of_ image manipulation, that's why
it is so general purpose and must have the modes. painting is
never an objective in itself in GIMP. here GIMP is 100% different
from krita, or mypaint.

of course when you want to make your painting engine an extension
to GIMP, and distribute it separately, you can do whatever want.
it is a free/libre world.

if you are aiming to get your engine _inside_ GIMP and have it
in its standard distribution, then your technology (which seems
to be your focus) must be adopted to the GIMP vision (see above),
be adopted to the new technical architecture of GIMP (see GEGL)
and fit the interaction architecture of GIMP (no giant panel with
42 big sliders; adapt to the tool options, integrate (how?) with
the paint tools, etc).

this can all be done, but takes strategic thinking and then
a lot of design work (technical and interaction) before
development makes sense.

so you have to ask yourself which route you want to take,

    --ps

        founder + principal interaction architect
            man + machine interface works

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