06-02-2025, 08:02 PM
(06-02-2025, 11:59 AM)martymichal Wrote: @Ofnuts, what would be your ideal form of the single source of documentation? An online source at e.g., https://api.gimp.org/ (hypothetical) or an in-process resource similar to the existing browsers? Regarding code completion and type checking, would this be similar to what e.g., the Godot engine provides? It allows using external editors that can connect to a language server that runs in-process. I actually already made a ticket about this particular at https://gitlab.gnome.org/GNOME/gimp/-/issues/14124.
@vitforlinux, samples or examples of use in different languages is definitely something that would be great to have! The situation with enums in GEGL is "fun". Looking for 'enum' in the GEGL issue tracker yields several issues related to introspection of enums.
Preferably something that doesn't require to fire up Gimp just to read the documentation. The built-in doc used to be useful to generate calls, but it currently create things like this:
Code:
➤> procedure = Gimp.get_pdb().lookup_procedure('gimp-drawable-edit-gradient-fill'); config = procedure.create_config(); config.set_property('drawable', drawable); config.set_property('gradient-type', gradient_type); config.set_property('offset', offset); config.set_property('supersample', supersample); config.set_property('supersample-max-depth', supersample_max_depth); config.set_property('supersample-threshold', supersample_threshold); config.set_property('dither', dither); config.set_property('x1', x1); config.set_property('y1', y1); config.set_property('x2', x2); config.set_property('y2', y2); result = procedure.run(config); success = result.index(0)
which is quite an eyeful even for simple calls, so people actually use the direct API for most calls (Gimp.Drawable.edit_gradient_fill()) and the PDB calls are used through a wrapper. So the build-in code generator has lost all its interest. I would even say that in its current form the built-in doc is a misfeature because I have seen code written using it by people not aware of the direct API.
My usual editor (kate) can use a LSP, but a true Python wrapper with good type hinting around the GI stubs would be good too, and more usable in regular Python IDEs (PyCharm and such). In fact with a good wrapper a decent existing Pythonv3 LSP would do the job.