After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783742 - Unable to give a layer group as a parameter to a python script
Unable to give a layer group as a parameter to a python script
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Gimp-Python
2.8.22
Other Linux
: Normal normal
: 2.8
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2017-06-13 13:35 UTC by Ofnuts
Modified: 2018-05-24 17:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test script (1.50 KB, text/x-python)
2017-06-18 16:49 UTC, Ofnuts
Details
Test image (2.67 KB, application/octet-stream)
2017-06-18 16:50 UTC, Ofnuts
Details

Description Ofnuts 2017-06-13 13:35:07 UTC
Trying to pass a layer group as a PF_DRAWABLE argument (as the usual default active layer or as a supplementary argument) elicits:

    TypeError: can't pickle GroupLayer objects

I have encountered this problem in two different scripts that used to work (for instance;: http://registry.gimp.org/node/26996)

It seems this is a regression in 2.8.18 or 2.8.20.
Comment 1 Jehan 2017-06-16 12:14:24 UTC
If this is a recent regression, this should not be too hard to cherry-pick using the branch gimp-2-8 of the git repository. Would you be able to try?
Comment 2 Jehan 2017-06-16 13:02:45 UTC
By the way, I confirm the error is outputted with the linked script on master (not tested on 2.8).
Comment 3 Ofnuts 2017-06-18 12:18:48 UTC
I can fix the problem by just adding:

   copy_reg.pickle(gimp.GroupLayer, _drawable_id, gimp._id2drawable)

in gimpshelf.py. But... `git log` (GIMP_2_8_22 branch) shows that this file hasn't received updates since... 2009 (and no significant code updates since 2008). So I don't understand why this problem appears now. 

The bug doesn't occur with a script that takes only an image and a drawable, because gimpfu.py doesn't save parameters when there are only default parameters (image+drawable, here), ant this could explain while the problem has remained under the radar. Otherwise if there are non-default parameters all parameters are saved (including the default ones, and the logic for this escapes me).
Comment 4 Michael Schumacher 2017-06-18 12:27:08 UTC
Did you verify that it ever worked in 2.8 or with group layers at all - i.e. did you try it yourself whether this worked in e.g. 2.8.18 or older versions?

From what I can see in https://www.gimp-forum.net/Thread-Help-Plugin-killed-by-last-update you were relying on information provided by one user, who apparently didn't have the older version installed anymore to verify. 

"But I could have sworn..." and "Oh, I didn't recall I didn't use any layer groups yet..." are far more frequent that you might imagine.
Comment 5 Ofnuts 2017-06-18 14:04:38 UTC
Tried with 2.8.16 and bug still there. Going further back is slightly beyond by current recompile abilities (getting glib incompatibilities when rebuilding 2.8.14).

Note that the mentioned plugin was explicitly written to work with groups, so we can assume that it worked with at least one 2.8.x release. There is also this thread on GimpChat: http://gimpchat.com/viewtopic.php?f=9&t=4899 where users are discussing the groups-oriented scripts in 2012, and revived a couple of weeks ago by someone wondering why all the group-oriented scripts stopped working.
Comment 6 Ofnuts 2017-06-18 16:48:00 UTC
Beginning of an explanation. Rich unearthed a 2.8.4 and ran the attached script on the attached image. And on 2.8.4 the  script reports:

Image: <gimp.Image 'LayersAndGroups.xcf'>, layer "Group": <type 'gimp.Layer'>

While on later releases it says:

Image: <gimp.Image 'LayersAndGroups.xcf'>, layer "Group": <type 'gimp.GroupLayer'>

So the earlier version had no problem pickling the GroupLayer because for them it was a plain Layer. This was obviously changed later. Now, we have to understand how the interface sort of worked with Layers instead of GroupLayers before. And if we look at the script that made me report this problem (http://registry.gimp.org/files/group_offset.py.txt), it goes:


    def py_group_offset(img, tdraw, xoffset, yoffset, edge, half):

        # [code removed]
        
    ### get active layer             
        draw = img.active_layer

        if (type(draw) == gimp.GroupLayer):
                dogroup(draw)         
        else:
            debugMessage("This is not a layer group!")

        pdb.gimp_image_undo_group_end(img)

        # [code removed]

So, it is not using the layer passed as a parameter, but refers to "active.layer" instead. Between the parameter named "tdraw" and the "### get active layer" comment, it is very likely that the author found that the parameter was unusable and found a work around.
Comment 7 Ofnuts 2017-06-18 16:49:24 UTC
Created attachment 353994 [details]
Test script

Script showing the Python type of passed parameters
Comment 8 Ofnuts 2017-06-18 16:50:24 UTC
Created attachment 353996 [details]
Test image
Comment 9 Ofnuts 2017-06-18 17:19:01 UTC
git log /plug-ins/pygimp/pygimp-drawable.c

commit ae3d1f9c2fb3256498576b31593c454b04dbb0cf
Author: *************************
Date:   Tue Feb 10 11:55:30 2015 -0200

    Fix PF_LAYER always being passed as a Layer, even if object is a LayerGroup

So that would be a problem new in 2.8.16, given the release dates.
Comment 10 Michael Natterer 2017-06-19 07:42:26 UTC
Do these python wrapper objects not have an OO-like is-a relation to each
other? If they don't, things are seriously screwed.
Comment 11 Michael Schumacher 2017-06-19 08:21:37 UTC
http://gimpchat.com/viewtopic.php?f=9&t=4899&sid=263de349ec0b76f5aeb174dc6b123a90&start=10#p216702 hints at platform-specific behavior. And if this commit is the trigger, then it being broken since 2.8.16 (as mentioned there, at least for the test on the Ubuntu platform) would be expected.
Comment 12 Ofnuts 2017-06-19 09:35:56 UTC
@MichaelN: they do:

>>> inspect.getmro(gimp.GroupLayer)
(<type 'gimp.GroupLayer'>, <type 'gimp.Layer'>, <type 'gimp.Drawable'>, <type 'gimp.Item'>, <type 'object'>)

However, the code is doing rather specific pickling (IMHO this is a bit superfluous since we only save the Gimp ID...) and this one seems to be class-specific, which can be expected since a derived class could add new attributes.

@MichaelS: I can't get that person to confirm he is using the same version on both, and that he's not using a "fixed" version I published. I had a trustable person (Rich) try things on Windows and they fail the same way. In fact the "cant't pickle" error was initially reported by Windows users (for instance http://gimpchat.com/viewtopic.php?f=9&t=15663 and https://www.gimp-forum.net/Thread-Help-Plugin-killed-by-last-update) and reproduced on my Linux.
Comment 13 GNOME Infrastructure Team 2018-05-24 17:57:06 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1119.