Hi Roland

On 07/31/2010 02:32 PM, Roland Lutz wrote:

Hi,

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 #74554).

No significant progress have been made, as far as I know no one is working on making tools pluggable.

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.

Yes not having IWarp on-canvas really makes the whole thing feel rather crippled. Tor Lillqvist started porting the IWarp plug-in to a tool a while back but never got around to finish it. I'm sure he would appreciate someone finishing the work: https://bugzilla.gnome.org/show_bug.cgi?id=162014

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.

Doing previews on-canvas is indeed superior to our current dialogs that plug-ins uses, switching to GEGL will help us greatly with making things being previewed on the canvas.

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?

I think this is a tricky issue. In order for a tool to be easy to use, it needs to be very well integrated in the UI. It is hard to construct an API that is well designed and easy to maintain, but still allows tools to feel integrated. It would be very interesting to see an attempt at defining a useful API for pluggable tools.

Regards, Martin

On 7/31/10, Roland Lutz wrote:

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.

Roland,

There was an attempt to rewrite IWarp into a tool before, but this work wasn't finished. Check archives for February 2008.

These days new tools are better implemented on top of GEGL. One such tool is currently in works as an objective of a Google Summer of Code project:

http://git.gnome.org/browse/gimp/log/?h=soc-2010-cage

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.

This will change along with further integration with GEGL, AFAIK.

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?

"Because every feature needs its programmer" is the best I can come up with :)

Alexandre Prokoudine http://libregraphicsworld.org

Pluggable tools would be nice, but the tool system is already set up to make it
easy to add new ones. It's one of the easiest places in the gimp code for a new
developer to work, although it would be a lot easier if there were more developer
documentation. The problem with the iwarp tool wasn't in the framework, it was in
the execution. It turns out to be very difficult to generate in-image previews at full
scale fast enough to be responsive. There were also some difficulties, if I remember
correctly, in adapting the code to work when the image window shows a rescaled
version of only a portion of the layer. Doing the tool as a plug-in wouldn't help with
those problems at all.

-- Bill

I think an IWarp tool would require mechanisms in GIMP that don't exist yet as none of the current tools, even if superficially similar (like the smudge tool) requires them. Also, the exact way an IWarp tool should behave should be specified before one starts coding on it;) Yeah, getting input on how the corresponding functionality UI works in PS might be useful, or not. GIMP is not supposed to be a PS lookalike.

Should using an IWarp tool mean entering a separate "mode" where you then have to "apply and exit" it when done? That is somewhat ugly, isn't it? Or should an IWarp tool automatically do the final application of the displacement map that has been built up during subsequent IWarp "brush" strokes and whatnot when another tool is selected and used? Will that be unbearably slow? In a non-destructive GEGLified future, that probably doesn't matter much as the calculation of updated actual image pixels can be done in the background (as long as the preview is correct enough), or something.

I quote my comment in the bug mentioned, "The smudge tool is inherently quite different from what an IWarp tool would be. Each stroke of the smudge tool immediately affects the pixels the brush touches. There is no memory of previous strokes. In IWarp, on the other hand, what happens when you stroke is that the displacement map gets updated, and the effect on the *original* pixels from when the tool was started has to be recalculated. (At least, something like this is what I recall from when I was hacking on making IWarp a tool.)"

--tml

On Saturday, July 31, 2010 22:33:56 Tor Lillqvist wrote:

I think an IWarp tool would require mechanisms in GIMP that don't exist yet as none of the current tools, even if superficially similar (like the smudge tool) requires them.

Doing the iWarp tool in paint tool way was rejected because it destroys the image very fast. Krita has such implementation and I suggest you try it.

Should using an IWarp tool mean entering a separate "mode" where you then have to "apply and exit" it when done? That is somewhat ugly, isn't it?

This is the only way this tool can currently work without creating undue degradation of the image while working. Once gegl is fully integrateed however, It can be a sort of an effect layer/op in the graph.

[SNIP]

In IWarp, on the
other hand, what happens when you stroke is that the displacement map gets updated, and the effect on the *original* pixels from when the tool was started has to be recalculated. (At least, something like this is what I recall from when I was hacking on making IWarp a tool.)"

CAGE tool currently under development already creates a piece of such a tool, a displacement map renderer. In fact, in many ways, the cage tool and iWarp are alike. Once cage tool is done, spawning an iWarp tool form its code should be trivial. All you need is to replace the UI code to brush instead of polygon editor and create the displacement map. Render pipleine should already be in place.

-- Alexia