Hello Lionel,

On Fri, Nov 21, 2008 at 3:04 AM, Lionel Tarazón wrote:

Hi everyone,

I am currently developing a Gimp plug-in with a GTK+ user interface. My plug-in is unstable if the user modifies the image or calls other plug-ins while it is running.

What version of GIMP are you using? This situation has been improved in 2.6, though there is still plenty of scope for further improvement.

Is there a way of "blocking" user interaction over the gimp window which called the plug-in?

No (and we probably would never implement it; it is pretty rude behaviour.)

In the future, a locking facility to simply prevent the user from modifying an image while a plugin is running on it (or only when the plugin is actually reading/writing from/to the image) could be desirable. It remains to be seen how useful this would be in light of GEGL integration (in future, most plugins should become little more than GEGL ops.)

David

IMHO the way GIMP works is fine, and interaction should never be blocked. We don't want a program that is unusable while an effect is being applied.
A better solution (and I think that the porting to GEGL is aiming in this direction, among other things) would be to put the filter and the transformations in a sort of queue, so the interaction is never blocked and the processes are stacked so you can continue working while a filter is applied.
Of course, in some point it will be necessary to implement a "smart" queue that blocks some processes that can be incompatible between them, but I think that simply blocking interaction while a plugin is working would be a step backwards.

There's something I saw in Avid Liquid that is extremely interesting. The program shows a quick preview of the effects using the GPU while you edit, and it renders the filter in the background. Of course I won't compare a video editor with a program like GIMP, but I find that method very interesting.
Using low resolution proxies of the filters would give an instant feedback of the filters while the real transformation is applied in the background, queued.
That would be in my oppinion a smart way to avoid blocking interaction without limiting the possibilities of the program.

Hi Lionel,

On Fri, Nov 21, 2008 at 8:15 PM, Lionel Tarazón wrote:

Hi David

I am currently developing a Gimp plug-in with a GTK+ user interface. My plug-in is unstable if the user modifies the image or calls other plug-ins while it is running.

What version of GIMP are you using? This situation has been improved in 2.6, though there is still plenty of scope for further improvement.

Actually 2.4, in which ways has it improved in 2.6?

The NEWS file says:
* allow plug-ins to work in parallel on different layers of the same image

David

2008/11/20 Guillermo Espertino :

A better solution (and I think that the porting to GEGL is aiming in this direction, among other things) would be to put the filter and the transformations in a sort of queue, so the interaction is never blocked and the processes are stacked so you can continue working while a filter is applied.

GEGL is (as I understand it) actually a bit fancier than this.

It's a demand-driven system, so filters are never really rendered at all. Instead, it just generates the pixels necessary to update the display. From the users point of view, all filters apply instantly, though more expensive filters will repaint the screen more slowly.

John