Hi, 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 abandoned: > > 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 more features. > > 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. Comments? Salut, Sven
