Nathan Carl Summers <[EMAIL PROTECTED]> writes:

> On 30 Jan 2003, Sven Neumann wrote:
> > Hi Nathan,
> >
> > when I updated my gimp tree this morning I was surprised to see this
> > commit:
> >
> > 2003-01-30  Nathan Summers  <[EMAIL PROTECTED]>
> >
> >         * app/tools/gimptoolgui.[ch]: GimpToolGui, a new class descended
> >         from GimpObject to be used to separate GUI from logic.  Heavily
> >         inspired by GimpDrawTool.  Not actually used by anything yet.
> >
> > Would you mind to explain what you have in mind here?
> Not at all.  I think I posted this before, but basically, I'd like to have
> a GimpToolGui class and a GimpToolLogic class, which both inherit from
> GimpObject.  The appropriate GimpToolInfo structure would then have to
> have the GType for both the gui and logic classes.  A GimpTool can then be
> created that contains a pointer to both a GimpToolGui and GimpToolLogic.

Hi Nathan,

I don't understand what you want to do here. A GimpTool already *is*
a GUI-only object. The separation of a GimpTool holding core and GUI
objects is exactly the madness we had in 1.2 and which was just painfully
removed to create a class hierarchy of tools.

Remember, in GIMP 1.2 we had for instance the selection_tools which
had to allocate a draw_core just to render to the canvas. To acheive
this, they somehow had to dispatch the events they got to the draw core
object, introducing additional (and error prone) indirection.

Now we have GimpDrawTool the selection tools can inherit from and
transparently get the correct drawing behviour.

I don't see how an aggregation of objects can be a more useful abstraction
than a derivation that simply has proven to work.

Again, GimpToolGui and GimpToolLogic is IMHO the wrong way, since
tools are GUI-only objects (at least they are in 1.3).

> > Looks a lot like the GimpDrawTool actually and I'd like to hear about
> > your plans for the tools since of course Mitch and me have a plan as
> > well. I must admit that we haven't told you about it neither but we are
> > actively working towards a massive tool redesign for quite some time
> > now.
> I would love to hear what you have in mind.

It's more a tool_options redesign. GimpToolOptions will be derived
from GimpContext and not have a GimpContext. So it will inherit
all (de)serialization stuff. All option values will be GObject
properties so the tool options GUI can be created from gimppropwidgets.c
(which will be extended to fit all tool option needs).

The draw tool also needs some overhaul, preferrably with an API
that deals with vectors and control points instead of drawing.
(the drawing API should probably stay there for special porpose
stuff that can hardly be abstracted away).

The best thing would IMHO be a GimpDrawTool subclass which abstracts
the draw stuff away (using GimpdrawTool's API). Tools are then
derived from the subclass and can decide whether to use the drawing
or the vectory/control point API. This would also give a smooth
transition path instead of breaking everything at once.

But then we would like to get GIMP 1.4 out this year, so a feature
freeze (at least for starting fundamental resedigns) should not
be too far away.

Gimp-developer mailing list

Reply via email to