Python Fu Image Creation - Slight Issues - Printable Version +- Gimp-Forum.net (https://www.gimp-forum.net) +-- Forum: GIMP (https://www.gimp-forum.net/Forum-GIMP) +--- Forum: Extending the GIMP (https://www.gimp-forum.net/Forum-Extending-the-GIMP) +---- Forum: Scripting questions (https://www.gimp-forum.net/Forum-Scripting-questions) +---- Thread: Python Fu Image Creation - Slight Issues (/Thread-Python-Fu-Image-Creation-Slight-Issues) Pages:
1
2
|
Python Fu Image Creation - Slight Issues - BaconWizard17 - 12-31-2022 Hi all, I decided to finally start learning Python-Fu (I'm already familiar with Python), and I've been getting a feel for it by converting some of my older Script-Fu scripts to Python-Fu. It's going well so far, and I've been able to convert a few. Currently, I'm working on one of my scripts to create a preview image template. Formerly, I had a series of scripts that I could use to create different sized previews. I've streamlined it to one single new Python-Fu script with two sliders that allow me to customize how big I want the preview image canvas. The sliders determine the number of rows and columns, and then the image and guides are generated from that. The script works well, but there are two issues:
Code: #!/usr/bin/env python And here's one of the Script-Fu scripts for comparison: Code: ; 2x2 grid skin preview for XML2/MUA1 skins Any input is appreciated! RE: Python Fu Image Creation - Slight Issues - Ofnuts - 12-31-2022
PS: Using LAYER_MODE_NORMAL is much better than 28. RE: Python Fu Image Creation - Slight Issues - BaconWizard17 - 12-31-2022 If I remove the image and layer inputs from the function, I get the following error when running the script: Quote:TypeError: multiSkinPreviewAny() takes I think I read somewhere that python scripts automatically assigns an image and layer variable or something along those lines. I don't need the image and layer as inputs to the function because I'm creating a new image, but I can't get it to work without those there. What's the best way to fix that? As for LAYER_MODE_NORMAL vs 28, is that not the same thing? I checked and it does the same with either, but I'm curious why one would be preferred over the other. Are the text equivalents always better for these types of variables? Edit: I just realized that my old script didn't fill the image with white. It left the image transparent. I changed the layer type from RGB to RGBA. RE: Python Fu Image Creation - Slight Issues - programmer_ceds - 12-31-2022 (12-31-2022, 04:21 PM)BaconWizard17 Wrote: As for LAYER_MODE_NORMAL vs 28, is that not the same thing? I checked and it does the same with either, but I'm curious why one would be preferred over the other. Are the text equivalents always better for these types of variables? At the moment the constant declaration LAYER_MODE_NORMAL is set to 28 but if that ever changed (perhaps another mode was inserted into the list before this one) you could spend a long time looking for the problem. Using LAYER_MODE_NORMAL all you have to worry about is the name changing (as it did recently from NORMAL_LAYER_MODE if I remember correctly) and that would be easy to sort. Apart from that, reading LAYER_MODE_NORMAL conveys information - 28 doesn't tell you anything just by looking at it. RE: Python Fu Image Creation - Slight Issues - BaconWizard17 - 12-31-2022 (12-31-2022, 04:42 PM)programmer_ceds Wrote:(12-31-2022, 04:21 PM)BaconWizard17 Wrote: As for LAYER_MODE_NORMAL vs 28, is that not the same thing? I checked and it does the same with either, but I'm curious why one would be preferred over the other. Are the text equivalents always better for these types of variables? That makes sense. Thank you! I'll keep that in mind going forward RE: Python Fu Image Creation - Slight Issues - Ofnuts - 12-31-2022 (12-31-2022, 04:21 PM)BaconWizard17 Wrote: If I remove the image and layer inputs from the function, I get the following error when running the script: Did you restart Gimp so that it re-scans the plugins. What is the definition like in the pluginrc file? AFAIK, if the first arguments in the registration are an image and optionally a layer(*) (in that order) when when the plugin is called, the code that auto-generates the plugin considers that these are implicitly the current image and layer, and doesn't generate widgets to select them in the dialog. In some conditions, you can see them in the dialog (from memory when re-executing the scripts, perhaps if the original layer has disappeared). RE: Python Fu Image Creation - Slight Issues - BaconWizard17 - 01-23-2023 Sorry for the delayed response. Hectic start to the year. Quote:Did you restart Gimp so that it re-scans the plugins. What is the definition like in the pluginrc file? Yep, I always restart Gimp when making changes to the plugins. Here's the definition in pluginrc: Code: (plug-in-def "${gimp_dir}\\plug-ins\\MarvelMods-Common-MultiSkinPreviewAny.py" 1672505354 This looks the same regardless of whether I have the image and layer variables or not for my function. I'm going to include some screenshots of what I'm seeing. This is how the dialog looks when I run the script with no image open. The dialog is the same regardless of whether or not I have the image and layer variables in my function: This is the same dialog box if I already have an image open. Again, it doesn't change if the layer and image variables are there: If the layer and image variables are not part of my function (so def multiSkinPreviewAny (columns, rows):), I get this error: Quote:AFAIK, if the first arguments in the registration are an image and optionally a layer(*) (in that order) when when the plugin is called The issue is that I don't think I have these in my registration. I think they're being included automatically. This is the register function again: Code: register( Is there something wrong with that? I just want to set this up without the image or layer variables so that others can use this script and similar ones without any confusion. RE: Python Fu Image Creation - Slight Issues - Ofnuts - 01-23-2023 Looks like you are using the deprecated registration form, where the 7th argument is a full path for the menu, so you get an old behavior. In the current registration form, the 7th argument is only the menu label, and the location is passed in a named menu= argument. With this newer form, Gimp will not add parameters and will always call the plugin with the parameters declared in the registration. The only implicit behavior is that if the first parameters can be inferred from the way the plugin is called (typically, active image, layer, path...) they won't be part of the auto-generated dialog. So, trying with this code (that uses the current registration form): Code: #!/usr/bin/env python The plugin itself is written in way that makes it accept any number of parameters (this is for debug purposes only, not a good idea for a real plugin). The only purpose of the plugin code is to display the parameters received. It is registered as four different Gimp plugins, each with a different registration:
Called without any image opened in Gimp:
RE: Python Fu Image Creation - Slight Issues - BaconWizard17 - 01-23-2023 This worked perfectly, thank you! I appreciate the help. Just out of curiosity, is this documented anywhere? I haven't been able to find much about python fu on the official Gimp site. And a question that I thought of while testing (hopefully my last one for a while): Is it possible to change the title of this window when input is being collected? Currently it just displays the name from the registration, so I wasn't sure if that could be changed. RE: Python Fu Image Creation - Slight Issues - Ofnuts - 01-24-2023 Gimp python doc is here: https://www.gimp.org/docs/python/ For the title bar content, not as far as I know, but I never tried to find out. |