Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Are these really python3 Gimp plug-ins?
#1
On this page from the Gimp dev site  I found a group of Gimp plug-ins made for python3. I thought I would try them in my Gimp snap pack which in theory can use both python 2 and 3.

They don't give any error messages yet the same set of old python2 versions don't work with errors. I can't tell if these python3 plug-ins are working or not. Any ideas?
Reply
#2
Gimp 3 (2.99 for the time being) uses Pythonv3. Gimp 2.x uses Python v2.

The scripts you find in Gimp source code are included in your installed Gimp if the developers think they work well enough.  

The source of Gimp 2.x Python scripts is here. The source code repository has "branches", i.e. separate variants of the code where some (many in the case of the 2.x branches) of the files are different(*). The default branch is called master (though on some overly politically correct system (GitHub) this has been renamed main. You switch to a branch in the repository using the branch selector. 

   

A (hopefully coherent) state of the code is called a "commit" which happens when a developer decides so. The commit is identified by a "hash" (which is a string of 40 hexadecimal digits, usually shortened to the first 8), so a branch is a sequence of commits. Specific commits can be given a "tag", so for instance you can retrieve the code used in the published 2.10.34 version by using the GIMP_2_10_36 tag which has been set on commit 1651e6e7 (which is itself a shortening of the true hash 1651e6e767965cf055e05d13e075095d226f1c66).

TL;DR: If you aren't a developer, looking at the source code serves little purpose, if it works, it has been published, and if it isn't published, it is probably buggy.

(*) branches have two uses:
  • Somewhat permanent branches to maintain different versions of the code: Gimp 2.x versus Gimp 3 for instance
  • Temporary branches where developers can work without impacting others. When they do so they can periodically "rebase" their code by importing changes made to the branch they forked off, and when they are done "merge" their branch back to the code they forked off. Until the merge, "what happens in the branch stays in the branch"
Reply
#3
Thanks very much ofnuts you solved my problem Smile  I found the right files here. Ubuntu, who make the Gimp snap are at v2.10.34 while Gimp, who make the flatpack are at v2.10.36.
It has been good understanding what's happening in Gimp and Ubuntu. The snap file loads faster but a few seconds is not important. Gimp have retained python2 which is what the users want. I will upload my snap with python2 on Github because that's where I have an account.

I discovered this command to make all the python files in a directory tree executable.

Code:
find . -name "*.py" -exec chmod +x {} \;                             (changes all py files)
find . -name "*.pyc" -exec chmod -x {} \;
find . -name "*.pyo" -exec chmod -x {} \;

It also changes the support files so I have to change them back Smile

Reply
#4
(11-20-2023, 10:45 PM)Tas_mania Wrote: Thanks very much ofnuts you solved my problem Smile  I found the right files here. Ubuntu, who make the Gimp snap are at v2.10.34 while Gimp, who make the flatpack are at v2.10.36.
It has been good understanding what's happening in Gimp and Ubuntu. The snap file loads faster but a few seconds is not important. Gimp have retained python2 which is what the users want. I will upload my snap with python2 on Github because that's where I have an account.

I discovered this command to make all the python files in a directory tree executable.

Code:
find . -name "*.py" -exec chmod +x {} \;                             (changes all py files)
find . -name "*.pyc" -exec chmod -x {} \;
find . -name "*.pyo" -exec chmod -x {} \;

It also changes the support files so I have to change them back Smile

Normally you don't need to make .pyo and .pyc files executable. They are pre-compiled version of like-named .py modules loaded by "main" .py files so aren't invoked as commands by the OS. One coukd even say that you probably don't need to make all .py executables either.

This said you shell code can be improved:

Call chmod once for with the found files (instead of once per file):
Code:
find . -name "*.py" -exec chmod +x {} +   # "+" instead of ";"

Use the bash globstar option:
Code:
shopt -s globstar # likely already set as default in your bash profile
chmod +x **/*.py  # With globstar "**/" matches all directories at all levels under parent
Reply
#5
Thanks ofnuts for improving that shell code :Smile
I pasted-in python2 without over-writing any files in the original snap pack. I wanted to have a 'drop-in' python2 to automate it.

Link to the python2 ubuntu snap.

Any testers are welcome. Snap is already in later Ubuntus but it needs to be installed 'dangerously' Smile
'sudo snap install --dangerous ./gimp_2.10.34_python2_amd64.snap'

It becomes the system Gimp in Ubuntu and can be uninstalled with
'sudo snap remove gimp'

   


Plug-ins and scripts go here in a snap pack:
users home/snap/gimp/x1/.config/GIMP/2.10/
Reply


Forum Jump: