Plugged-in tools

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

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.

Roland

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

On Sat, 31 Jul 2010, Tor Lillqvist wrote:
> 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?

That's how the Scissors tool works, so people are already used to it.
This way, a separate warp history could be maintained in the tool area
which could allow reverting arbitrary strokes. With GEGL, it might even
be possible to re-open and revise a warp layer at a later time.

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

This doesn't mean the warp 'strokes' shouldn't be understood as a single
warping operation. The (yet invisible) grid they affect defines the way
the drawable sould be transformed. This is not equivalent to composing
several transformations (think of the 'Remove' deform mode).

Roland