I am using Gimp AppImage 2.10.8 ‘with plug-ins’ under Ubuntu 18.04 LTS. I am attempting to script a custom filter (GMIC.nb_Composants), hoping to manipulate the output layers later in GIMP.
The following .py is never recognized by my installation. Attempts to locate the py script in my menu system fails.
You can take the habit to try to run your script at least once in a command prompt. If there are any big syntax problems they will show up there (indentation problems, unbalanced quotes/parentheses, encoding, etc…). No point trying to run in Gimp until you get:
Traceback (most recent call last):
File "badGMIC.py", line 6, in <module>
from gimpfu import *
ImportError: No module named gimpfu
You can’t get any further in a command prompt since gimpfu is defined only when you run under Gimp, but when you get this the worst syntax problems have been fixed.
Since you are under Linux, start Gimp from a terminal, if there are “finer” syntax errors or runtime problems when the script is run for registration you will see them there.
I followed your instructions as per location of my GMICComp.py. Unfortunately, the script does not show up in my menus. The script works fine in the GIMP.Python console.
I agree to investigate messages while Gimp AppImage is loading. My only way, at this moment, to launch Gimp Appimage is by double clicking its file (GIMP_AppImage-release-2.10.8-withplugins-x86_64.AppImage). I have no idea how to launch ‘verbose style’ the AppImage. I am familiar with the FlatPak.Gimp version and can launch it ‘verbose style’. But unfortunately , FlatPak.Gimp does not include GMIC.
I have managed to launch GIMP.AppImage from the terminal with:
$ gimp --verbose
GIMP.AppImage is now verbose! So usefull!
Now with my ill GMICComp.py, the terminal answers with :
Querying plug-in: ‘/media/nicolas/860Turnbull/Nicolas/maison/Images/Outils/MAP/GMICComp.py’
Traceback (most recent call last):
File “/media/nicolas/860Turnbull/Nicolas/maison/Images/Outils/MAP/GMICComp.py”, line 16, in
register(
NameError: name ‘register’ is not defined
With this information, I can locate my (typing error) at line 16. How can ‘register’ be not defined when my successful .py scripts carry the same instruction?
Carefully check you registration parameters. You are specifying the menu twice, if you use the menu= named parm, the other should just be the final menu label. A sample registration looks like this:
from gimpfu import *
def executedFunction(image,drawable):
pdb.gimp_message("Hello, Gimpers!")
# Registration
register(
"plugin-identifier-must-be-unique",
"Plug-in summary for procedure browser and mouse-over in menus",
'''
Full Plug-in description
This is the real plugin description that shows up in the procedure browser.
It can contain complementary information to the auto-generated argument descriptions.
''',
"Author's Name",
"Copyright owner's name",
"Copyright date",
"String for menu label",
"*", # Supported image types
[ # Description of input arguments
(PF_IMAGE, "image", "Label/description in auto-generated dialog and procedure browser", None),
(PF_DRAWABLE, "drawable", "Label/description in auto-generated dialog and procedure browser", None),
],
[], # Descripton of return values
executedFunction,
menu="<Image>/Menubar Entry/Submenu/"
)
main()
Also did you fix the python-fu_GMICComp problem, including where it appears in the register() call?
If you use import gimpfu, only gimpfu is added to the global name space, and things in gimpfu have to be accessed via gimpfu: gimpfu.gimp, gimpfu.pdb, etc…
If you use from gimpfu import * all symbols in gimpfu are added to the global name space and can be accessed directly: gimp, pdb.
It is usually recommended to use the import package form because it avoids possible name clashes when you import many packages. When the package has a long name you can use an alias: import longpackagename as lpn and then use the alias: lpn.someFunction().
The from form is also considered OK if you import a few selected symbols: from package import someFunction.
The blunt form from package import * is usually advised against, but for gimpfu this is of little consequence since most labels are “defined constants”, and prefixing every usage with gimpfu wouldn’t be very readable.