Nathan Carl Summers <rock@xxxxxxxx> 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 <rock@xxxxxxxx> > > > > * 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. ciao, --mitch
