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?
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
