Hi, > 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). to get an idea of this concept, you could have a look at the text tool in an uptodate CVS checkout. I've today replaced the old-style ToolInfo memebers with a GimpText object. This is not exactly what we have in mind as the final situation but it already shows how tools will store their parameters as object properties and how the GUI is a view on these properties. The ToolInfo reset method is down to a one-liner and it would be trivial to implement saving and loading of tool parameters now. > 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. The new text tool will also need some of these so I'd welcome to see such a GimpDrawTool subclass soon. > 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. yes, we need to figure out and write down what absolutely needs to be done before 1.4. IMO this is merely getting the text and path tools to work. Salut, Sven
