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

[Michael Natterer <mitch gimp org>]

Peter,

somebody comes up with a huge improvement over the current
stuff in GIMP, and all you have to say is:

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

"...but one million users do not care."

"can I point out the vision of the GIMP team?"

I don't know who that "GIMP team" is, but my vision is that
we encourage new development like this, and not put an end
to it with mails such as yours.

Of course things have to be evaluated, implemented in GEGL,
designed and whatnot, but can we please not respond in
a "this sucks" tone? Thank you.


Sigtech: I *strongly* encourage you to please go on, and if
you could port it to goat-invasion that would be great, it's
not that different from master.

Regards, and let's discuss more reasonable approaches to
*collaborative* development in Vienna,

--mitch


On Mon, 2012-04-30 at 13:05 +0200, peter sikking wrote:
> 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
> 
> 
> 
> _______________________________________________
> gimp-developer-list mailing list
> gimp-developer-list gnome org
> http://mail.gnome.org/mailman/listinfo/gimp-developer-list