* Michael Natterer <[EMAIL PROTECTED]> [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
> 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
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.
.~. 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
Gimp-developer mailing list