Hm, seems I've sent that mail to the old address before ... --------------------------- Hi all, Nathan C Summers <rockwlrs@xxxxxxxxxx> writes: > On 21 Feb 2001, Sven Neumann wrote: > > Nathan C Summers <rockwlrs@xxxxxxxxxx> writes: > > > > > Problem: Many tools instruct the core to destroy themselves on certain > > > kinds of state changes, such as a change of image or display. While some > > > tools are quite good at handling these changes, others are quite unstable > > > psychologically and commit hara-kari for the smallest reasons. > > > > This problem should go away as soon as all tools are proper objects > > with init and finalize functions, destroy signals etc. > > That lessens but does not solve the problem that the code is more > complicated because of the destruction of tools due to state changes. I'm quite a bit biassed about wether we should destroy tools after use or not, but IMHO a tool should simply be able to handle both. Of course it has to handle it's destruction :) and being able to change displays will enable features we may not think of currently. Also, there would be no need to decide now if we want to destroy the tools or not. > > IMO the GimpToolInfo object Mitch just introduced to resurrect the tool > > system is the right way to go. GimpToolInfo objects stay around so Gimp > > knows what tools are available, can display icons, etc., the real GimpTool > > only exists when needed. > > I really like what Mitch has done with the tool code. He read my mind > when it came to renaming the gimp_tool_emit_* functions to more standard > names. The GimpToolInfo objects are elegant. > > Mitch: if you haven't yet written the code to get rid of the items marked > as needing to go away in the GimpTool class structure, let me know so > that I can write it and you can spend your time on less trivial code. Yeah, I went through the code when I re-integrated the tool stuff with the context and could not resist to apply some coding style paranoia. Most of the fields are already removed, I suggest to leave the remaining two (pdb string and cursors) there until there are some more tools back. The pdb_string could become a virtual function which returns the string, I'll care about making something real out of the cursor code when there are some more tools. > I also wonder what happened to standard_control_func. I know it was > misnamed, but it contained code that all of the current tools use and was > fit for inheritance. In general, it should be ran before the tool's > specialized control code. The function is now in the context manager because it's a wrapper around the active tool's "control" method. > > > Problem: Some tools, such as iscissors, keep around a lot of cached data > > > generated from the image they are attached to. Changing the image they > > > are working on clears this cache. This can be slow when working on > > > multiple images or layers. <discussion snipped> Hm, I'd rather vote for making the tool system stable again with all tools in their proper places in the tool hierarchy before we start adding fancy stuff like caches. And BTW, GLib already provides a cache mechanism which produces the requested data on the fly. > It is. I just think of the Gimp part as a namespace. Besides, after > typing GimpPaintingTool way too many times (yes, I found the macro command > in my editor...) I'm kind of sick of typing that big, long name. ;) > > (btw, why the "ing" ??). > > Because I figured that people would confuse GimpPaintTool with the > paintbrush. Please make it GimpPaintTool, you just talked about long names above :) > > If I remember correctly, the > > DrawCore is that ugly thing we use to draw on the display, so it should > > probably totally go away and be implemented on top of the yet to be written > > GimpDisplay. > > There isn't much code to it. But it will have to stay until GimpDisplay > gets written, as you can't meaningfully write code for an API that doesn't > exist. ;) Yeah, i guess we should put that to a separate tool so we can easily change it once there is a real GimpDisplay. > OK, here is the class hierarchy (some tools have been left out for > brevity) > > GtkObject > | > GimpObject > | > GimpTool > | \ > | GimpTextTool > | \ > | GimpDynamicTextTool? > | > GimpDrawingTool > | | \ > | | GimpColorPicker > | | > | GimpPaintingTool > | \ > | GimpPaintbrush > | > GimpTransformingTool > | | > GimpRotate GimpPerspective Well, I guess we should rather save some "ing" and add "Tool" all over the place to get a consistent namespace: GtkObject | GimpObject | GimpTool | \ | GimpTextTool | \ | GimpDynamicTextTool? | GimpDrawTool | | \ | | GimpColorPickerTool | | | GimpPaintTool | \ | GimpPaintbrushTool | GimpTransformTool | | GimpRotateTool GimpPerspectiveTool Also, the policy is to name files exactly as the objects they contain, e.g. gimptool.[ch], gimpcolorpickertool.[ch]. This may look a bit overly picky but a consistent file namespace is important in such a large codebase. > I'd like all the tools that don't take a specific point as input to be > turned into something else. My definition of a tool is something that you > click on the image with. They should also use the image view directly (as > should plugins). > > For example, by color select would count as a tool, but > contrast/brightness wouldn't. Of course the brightness/contrast stuff should be a tool, derived from GimpColorMapTool, how else do you want to get the display events there? > It will take some effort to do, of course, but it's worth it in simplicity > and user understanding. (Why do some things that work like filters not > respond to repeat last filter?, etc.) The "repeat last filter" stuff is just a bad hack due to the fact that not all gimp operations go through the PDB and can thus be repeated. While browsing through the code with this fact in mind i noticed that it cannot be _that_ hard to achieve this goal: once all main objects we can perform operations on (image, drawable, ...) are proper objects and live in their subdirs, we can redirect most commands.c callbacks and most stuff tools do to e.g. app/drawable/gimpdrawable-commands.[ch] where the respective PDB functions will be called. Looks like a bit of work, but if we want to hack GIMP 1.4's interface in a way that we can use it for 2.0, the way to go is to separate it cleanly from the core. ciao, --Mitch
