there has been a discussion, in 2002-2004, to allow plugged-in tools.

On 2002-02-22, Sven Neumann wrote:
> not discussed, but already implemented ;-) The CVS version has
> preliminary support for pluggable tools that can be either loaded as
> a plug-in (separate process) or as a module. I haven't looked at
> the implementation details yet.

What has become of this?  Many of the existing plug-ins would profit of 
such an infrastructure, as well as new plug-ins become possible (see bug 

There has been repeatedly brought up the request for in-window 
applicability of the IWarp distort.  Using IWarp in the preview pane is a 
nuisance and much inferior to, for example, the Photoshop Liquify tool. 
In fact, this has been the reason for me to consider hacking the GIMP in 
the first place.

Then there is the issue of dialog preview visibility.  Core dialogs like 
Levels and Curves are able to show preview directly in the image window, 
as opposed to plug-in dialogs which are restricted to small preview 
widgets.  Again, this is much inferior to the real-image preview and has 
got me frustrated more than once.

I know there have been a number of philosophical remarks in the past 
against pluggable tools.  However, to a user ignorant to the constraining 
GIMP design mechanisms, these restrictions and their consequences to the 
UI appear arbitrary.  Why stick with these at the cost of a bad UI?

If it turns out unfeasible to expose the tool API, the IWarp filter could 
be merged into the GIMP core so it can used as a tool.  However, this 
would not address the problem of bad preview in plugged-in filters, so 
maybe there is a better solution.


Gimp-developer mailing list

Reply via email to