This is a continuation of a thread on this list: https://mail.gnome.org/archives/gimp-developer-list/2022-July/msg00016.html. 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 type. 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 defined. 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 GNOME? _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
