* 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
> 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

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

Reply via email to