Currently Active Image

[JBreckeen]

Hello all. 

So I have searched and found some info saying this may not be able to be done, but I would really like a way to infer the currently-viewed image in python-fu.

I need this since I have a plugin (think of it more as an extension in other software), that communicates with Gimp from outside.  Mostly is handles loading, saving, and exporting of image files to our pipeline.  Right now I just use:

        currentImage = gimp.image_list()[0]
        currentDrawable = pdb.gimp_image_get_active_layer(currentImage)

which works if there is either one image file open, or want to deal with the last opened.  But would really prefer to be able to have it work on whatever image is "active".  I have read there is nothing in the API that deals with the active, but are there any work-arounds?

Is there something that I am missing?

Thanks in advance,

J.

[Ofnuts]

Just made a tutorial for you: https://www.gimp-forum.net/Thread-Gettin...on-scripts

[JBreckeen]

(05-02-2024, 07:33 AM)Ofnuts Wrote: Just made a tutorial for you: https://www.gimp-forum.net/Thread-Gettin...on-scripts

Thank you so much for doing that.  I have seen the method, but yours is a better description of registration.

Unfortunately, my issue would be the need to get the "active" image after the plugin has been registered.  Since my plugin is really an integration between two DCC's, the plugin is registered at the beginning of a Gimp session and the "active" image can vary after the plugin has been registered, such as working on more than one image at a time.

An example functionality:  when a user has two open images, image_A and image_B, and wants to save a new version (version-up) of image_A to the pipeline (Prism), the user clicks the customs command in the menu.  This triggers Prism to create the necessarily directories and sidecar files, and then sends a command back to Gimp passing a new filepath.  Gimp then handles the image and creates a thumbnail.  It then saves the .xcf using the new filepath.  That all works well.

But the need is to "know" that image_A is "active".  If the arg[image] is passed when the plugin is registered, that image will always be the one referenced which is not desired.

Enviro Vars are out since Gimp has everything in separate environments - which is probably a good thing.  I thought about having the plugin save the image position from gimp.image_list() to a .json each time a command is triggered.  But that is a bit ugly, and still have the issue of passing which item in the list is the "active".

Hope that makes sense.  I don't mind sharing the code, but it will not really function without Prism installed as well.

J.

[Ofnuts]

The image argument is passed when the plugin is called from the UI, not when the plugin is registered. If you have 10 images open, the plugin can be applied to each image by activating a view on the image (image windows or tabs) and then calling the plugin from the menu or a shortcut. Likewise the plugin automatically sets the "drawable" argument to the current active drawable of the current image.

However, an external process cannot determine the current image, if this is your problem (and anyway it could have changed in between....). So you probably want to send the image ID to your external process with the rest of the data so that it can use it to retrieve the image for which it was called later.

[JBreckeen]

(05-03-2024, 09:32 PM)Ofnuts Wrote: The image argument is passed when the plugin is called from the UI, not when the plugin is registered. If you have 10 images open, the plugin can be applied to each image by activating a view on the image (image windows or tabs) and then calling the plugin from the menu or a shortcut. Likewise the plugin automatically sets the "drawable" argument to the current active drawable of the current image.

However, an external process cannot determine the current image, if this is your problem (and anyway it could have changed in between....). So you probably want to send the image ID to your external process with the rest of the data so that it can use it to retrieve the image for which it was called later.

Yes, that is the method that I have used.  But since the plugin is always active, I have to have the Menu plugin send the Gimp Image to the external script (Prism), and then have Prism send it back to the looping function plugin for processing in Gimp.  It is working, but would be much easier and cleaner if there was an API to get the current image.  

But this seems to be working without an error - which is nice.  And it is invisible to the user so that's all that matters.

Thanks for the help!

J.

[Ofnuts]

(05-05-2024, 01:45 PM)JBreckeen Wrote: Yes, that is the method that I have used.  But since the plugin is always active, I have to have the Menu plugin send the Gimp Image to the external script (Prism), and then have Prism send it back to the looping function plugin for processing in Gimp.  It is working, but would be much easier and cleaner if there was an API to get the current image.  

That would be very dangerous... You start the processing on some image, and while your process runs, the active image changes for any reason, so when the result comes back it would be applied to the new active image and not the image it was intended for. Your current scheme is more robust...

[JBreckeen]

(05-05-2024, 01:56 PM)Ofnuts Wrote:

(05-05-2024, 01:45 PM)JBreckeen Wrote: Yes, that is the method that I have used.  But since the plugin is always active, I have to have the Menu plugin send the Gimp Image to the external script (Prism), and then have Prism send it back to the looping function plugin for processing in Gimp.  It is working, but would be much easier and cleaner if there was an API to get the current image.  

That would be very dangerous...  You start the processing on some image, and while your process runs, the active image changes for any reason, so when the result comes back it would be applied to the new active image and not the image it was intended for.  Your current scheme is more robust...

True, but I think it would be more of a gimp.image_get_current() that would be a reference to that image object, just as the PF_IMAGE does - just like any other object instance.  It is actually safer than determining the image by indirect methods such as image_list().

But don't want to complain too much, as I am just happy Gimp has such an extensive API, though quirky.