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 709090 - Enumerations in plug-in calls not available from Python
Enumerations in plug-in calls not available from Python
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Gimp-Python
git master
Other All
: Low enhancement
: Future
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2013-09-30 12:59 UTC by yotam
Modified: 2018-05-24 13:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description yotam 2013-09-30 12:59:52 UTC
I tried to use two constant in my scripts and I got an error. The constants are 

SINUSOIDAL (supposed to be 2)
SMEAR (supposed to be 2)

python 2.8.4, ubuntu 13.04
Comment 1 Jehan 2013-09-30 13:30:47 UTC
Hi,

is it the SINUSOIDAL (2) from plug-in-bump-map and the SMEAR (0) from plug-in-ripple that you are talking about?
Comment 2 yotam 2013-09-30 13:53:40 UTC
Hi, 

sorry I wasn't clear before. 
the SINUSOIDAL (2) constant is from plug-in-bump-map and the SMEAR (2) constant is from plug-in-displace
Comment 3 Jehan 2013-09-30 14:10:41 UTC
Well it looks like it may be normal when they are data coming from plug-ins. When they are core pdb procedure, they have an associated type created. But it does not look like we would create a type and named constants for plug-in's parameters.

So you'd have to use the constant integer value in between parentheses, while the value names are only for reference of which is which.

I agree that's not the nicer consistency since you have to care if a procedure comes from a plug-in or not (but fortunately the procedure's name gives it away!).

I'll confirm this with other developers, but that looks like the answer to your problem.
Comment 4 yotam 2013-09-30 14:16:02 UTC
Just to be sure. 

In gimp functions, I should use the constant (e.g. TRUE, or WHITE_FILL). when I handle plug-ins (everything that start with "plug-in") I should use the value and not the constant?
Comment 5 Jehan 2013-10-01 12:21:45 UTC
Yotam,

Yes that's it. Actually you can still use TRUE because that's a boolean, or you could use any enum value from a core type, if a plugin were to use this core type. But when it is not a core type, just use the actual values. Checking the code again from your examples, that's indeed expected that these names are not usable from outside the plug-ins. They are only used as documentation to explain the value's meaning.

That could be better but it is likely not a priority to improve our plug-in system to be able to register types.

So I guess I will close as a NOTABUG. :-)
Comment 6 yotam 2013-10-01 13:13:25 UTC
I would place that under (very) low priority, but I can see your point. I would recommend upon putting something in the documentations about this though.
Comment 7 Jehan 2013-10-02 08:08:46 UTC
Well, ok. Reopening as a low priority enhancement.
Comment 8 Joao S. O. Bueno 2014-06-20 01:15:32 UTC
The idea for gimp 2.10 is that most plug-ins become GEGL operations - as such, the enums shouldbe available through introspection. Still, "classic" plug-ins should work it installed, and for these, the only easy easy way to make the enumerations in the documentation available for Python is to parse the pdb blurb itself - it would be a feasible hack, but since we are moving forward anyway, I don't think it will be done.
Comment 9 GNOME Infrastructure Team 2018-05-24 13:58:22 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/503.