Block user interaction while a plug-in is running?

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.

Is there a way of "blocking" user interaction over the gimp window which
called the plug-in?
This way a user will be forced to close my plug-in before continuing working
with the image (the desired situation).

I've been looking in The Gimp API but haven't found a solution. I also know
this could be done easily using GTK+ functions if Gimp's windows and plug-in
windows existed in the same process, but as you know this is no the case :(

Thanks in advance
------------------------------------------
Lionel Tarazón Alcocer
PRHLT - Pattern Recognition and Human Language Technology Group
ITI - Instituto Tecnológico de Informática
UPV - Universidad Politécnica de Valencia
Valencia, Spain

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.

Is there a way of "blocking" user interaction over the gimp window which
called the plug-in?
This way a user will be forced to close my plug-in before continuing working
with the image (the desired situation).

I've been looking in The Gimp API but haven't found a solution. I also know
this could be done easily using GTK+ functions if Gimp's windows and plug-in
windows existed in the same process, but as you know this is no the case :(

Thanks for all
------------------------------
Lionel Tarazón Alcocer
PRHLT - Pattern Recognition and Human Language Technology Group
ITI - Instituto Tecnológico de Informática
UPV - Universidad Politécnica de Valencia
Valencia, Spain

Hello Lionel,

On Fri, Nov 21, 2008 at 3:04 AM, Lionel Tarazón <lionel@iti.upv.es> 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 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?

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

This would be great!

Thanks again.
------------------------------
Lionel Tarazón Alcocer
PRHLT - Pattern Recognition and Human Language Technology Group
ITI - Instituto Tecnológico de Informática
UPV - Universidad Politécnica de Valencia
Valencia, Spain

Hi Lionel,

On Fri, Nov 21, 2008 at 8:15 PM, Lionel Tarazón <lionel@iti.upv.es> 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 <gespertino@gmail.com>:
> 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