PF_ENUM, SF_ENUM, dynamically defined enums for plugins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


This is a continuation of a thread on this list:
The thread diverged to a discussion about future PF_OPTION implementation
in GIMP 3.

Here are my preliminary thoughts.

A PF_OPTION, in the old PyGimp, or a SF_OPTION, in ScriptFu,
is a declaration of a dynamic enum type.
The enum is created by the plugin.
Only the plugin knows the enum.
GIMP has no knowledge of the enum, until at runtime the plugin informs it.

Suppose that for PF_OPTION we can implement so that a GIMP plugin
dynamically defines an enum type
(in the GType system)
Then when registering an arg of the plugin declared using PF_OPTION,
the plugin uses a g_param_spec_enum, passing the GType of the dynamic enum
Then GIMP can use that g_param_spec to add a  property to the GimpProcedure
for the plugin,
and to create a GimpConfig for that property,
and show a dialog with a combo-box widget for the enum type.
All the latter stuff seems to work already.
That is, PF_ENUM and SF_ENUM seem to work,
for a plugin to declare an argument of a GEnum subtype that GIMP has
The problem is to implement the dynamic creation of an enum type.

GLib appears to be able to create enum types dynamically.
Its complicated and arcane, not something I understand.
So what I suggest may not be possible.

If you grep the GIMP repo, you find G_DEFINE_DYNAMIC_TYPE used in the
modules directory.
That is a GLib macro that seems pertinent, it seems to hide many of the
arcane details.
Anyway, there seems to be some history of dynamically defined types in GIMP.
The word "modules" is a GLib term for dynamically loaded code.

One problem is that GLib documentation often uses the word "static" for the
array of GEnumValues
that are in a GEnum type.
I don't think that  means the key value pairs in the enum must be defined
as static vars in some C code.
I think you can still have an interpreted plugin that allocates an array of
key value pairs and creates a dynamic GEnum type from it.

Another issue that concerns me is the "wire".
If a plugin creates a dynamic GEnum subtype,
does the type have to cross the wire, or only values of the GEnum?
I hope I am worrying too much.

As Ofnuts pointed out, PF_ENUM is heavily used.
It  deserves some attention.
In the thread reference above, Jehan has said he has an idea for
implementation and realizes it needs attention.
Here I am offering an alternative high-level view of what the technical
problem is.

If the technical problem is to create a dynamic GType,
then a pragmatic problem is that few developers deeply understand GType.
(Its a slog for me.)
Maybe Neils could look at it, or maybe we could get some mentorship from
gimp-developer-list mailing list
List address:    gimp-developer-list@xxxxxxxxx
List membership:
List archives:

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux