* Michael Natterer <mitch@xxxxxxxx> [020423 13:08]: > Hi Rock, > > While I have no doubt that it's implementable in a nice and working > way, I think it is the wrong way to go. Tools are an internal > implementation detail that is closely related to ugly things like > GdkEvents and fast response to user input. > > We should not add further tools, but drastically reduce their number > by separating their ui from the core. Then we make the factored out > core code (their actual functionality) accessible via both the PDB and > a module API. This is close to be finished for the paint tools. In the > end, there will be *one* paint tool with a variety of paint_core > implementations, each of them optionally featuring it's own tool > options. > The same holds true for the ImageMap tools, they will probably all > collapse into one single tool which simply uses the image_map modules > which are compiled in or loaded. If a general plug-in api for in-image preview should be implemented, I guess most ImageMap tools should be changed into standard distributed plug-ins. (since curves, levels, color-balance etc. could be considered core functionality) A standardised way to do in image previews would be what those tools need to become plug-ins instead. Since they probably should be distributed together with the gimp anyways,.. nothing would stop them from sharing some common code amongst themselves. My color-correction plug-in ( http://hal9001.2y.net/yuvadj/ which is now much more stable and usable since I announced it,. is from an users standpoint probably not be different in the way it works from levels/curves etc. -pippin -- .~. The mind is its own place,and in http://hnb.sf.net/ /v\ itself can make a Heaven of Hell http://hal9001.2y.net/ /(_)\ a Hell of Heaven. - John Milton ^ ^
