Add classes in the API to improve documentation
The API is being changed to be more object oriented. For example, the GimpImage class was added to libgimp. (The class already exists in core, the class added to libgimp is a proxy to the core class, over the wire, more or less.)
There are several conceptual classes that have not yet been added to libgimp. For example, GimpContext class is not defined in libgimp. The symptom or smell is that the API reference document (devel-docs/Gimp-3.0) has very many "Functions" where the functions seem like they should be methods of a class in the "Class" section.
The enhancement is to define such classes in libgimp. The enhancement has these benefits, mainly to the documentation.
1. methods are grouped under a "Class" instead of appearing in the "Functions" section.
2. The class gives a place to document the concept
There are several cases for the classes:
1. Conceptual superclass, where there is no actual inheritance, but there could be.
For example, GimpParamSpec, GimpValue
2. Singleton class, where there are no actual instances in libgimp,
and the class is a proxy to core where there may or may not be an actual instance.
GimpContext
3. Class with only class methods (no instances or instance methods.) GimpMessage
There should be little impact on performance. It should just add a few types to the GType runtime. You can think of it as a trick or kludge on the documentation tools, using the GObject naming conventions.
The defined classes will be empty of data and methods. The defined classes can be generated by a tool in Python.
I have done some experiments and can submit an MR. Its not as rosy and simple as it sounds above. For example, GimpMessage doesn't work without changing the API a little, and GimpParamSpec may require changing to actual inheritance of a superclass.
Related is !740 (merged), to add GimpResource class to libgimp.