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 is inefficient. It complicates the tool handling code, causes a lot of unneccesary frees, mallocs and initialzations, and seems to me to be a lot like "Windows must restart for these changes to take effect." On the other hand, multiple instances of a tool should exist for diffent input devices so that they can be in different states. Proposed Solution: Tools should just deal with having thier state changed. We can introduce a function tool_manager_get_tool that takes a tool class and input device and returns the correct tool (creating it on the fly if needed). The toolbox would just call that function and set the current tool on that device to that. active_tool should just go away. (so should iterating over the list of registered tools, perhaps) 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. Proposed Solution: a generic object, ToolCache, from which the specific kind of cache would be derived. A virtual function, compute_cache, would compute the value to be cached. For efficiency reasons, the cache may either be generated on-the-fly when its values are requested, or whenever the target changes. However, if the cache is not accessed after a certain number of changes it automagically switches to on-the-fly mode to conserve CPU cycles. variables: dynamic_timeout (number of times the target can change until it switches to on-the-fly mode) dynamic_countdown (how many times remain) methods: tool_cache_get (gets the data that is cached, generating on-the-fly if neccessary) <the obligatory get and set methods> signals: target_changed (the object whose data is being cached has changed) cache_flushed (sent whenever the cache has been flushed and filled with new values) compute_cache (mandatory virtual function to set the new values in the cache) target_destroyed (The target may be destroyed, but I'm not quite dead y...<plunk>) Problem: The number of ToolCaches should be kept down to a reasonable level. Proposed Solution: have a maximum number a tool can have. Make it configurable, perhaps on a per-tool basis. Any suggestions? Comments? Violently ranting flames? Rockwalrus P. S. The new implementations of DrawCore (now called DrawingTool) and PaintCore (now called PaintingTool) will be commited as soon as I finish the game of freeciv I'm playing. Must...stop...playing...freeciv.....must...start...doing...something... productive....can't...stop...must...think...clearly...aw, one more turn won't hurt, right?
