Nathan, you didn't answer to our mails but I'd like to continue this
discussion until a decision has been made. I don't like the idea of
having unused code in CVS, so we should get to a point about
gimptoolgui.[ch]. I'll try to pick up the decision where it was left
> > 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).
this basically has happened in the meantime and works quite nicely.
There is less code (due to reduced code duplication) that provides
> > 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.
this is still desirable and should probably be done at least to some
extent. I'll see if I can get something started when I add box
handling to the text tool. I can imagine that at least the crop tool
could use the same code for interactive rectangle handling. We might
even consider to use it for the selection tools as well in order to
finally get interactively resizeable selections.
However this new code I'm proposing here should IMO not live in a
separate object but should be implemented as a GimpDrawTool subclass
as Mitch suggested.
Gimp-developer mailing list