Skip to content
  • Jehan's avatar
    Issue #8900 and #9923: reimplementing GimpUnit as a proper class. · d493f053
    Jehan authored
    This fixes all our GObject Introspection issues with GimpUnit which was
    both an enum and an int-derived type of user-defined units *completing*
    the enum values. GIR clearly didn't like this!
    
    Now GimpUnit is a proper class and units are unique objects, allowing to
    compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
    tells us if unit is the pixel unit or not), which makes it easy to use,
    just like with int, yet adding also methods, making for nicer
    introspected API.
    
    As an aside, this also fixes #10738, by having all the built-in units
    retrievable even if libgimpbase had not been properly initialized with
    gimp_base_init().
    I haven't checked in details how GIR works to introspect, but it looks
    like it loads the library to inspect and runs functions, hence
    triggering some CRITICALS because virtual methods (supposed to be
    initialized with gimp_base_init() run by libgimp) are not set. This new
    code won't trigger any critical because the vtable method are now not
    necessary, at least for all built-in units.
    
    Note that GimpUnit is still in libgimpbase. It could have been moved to
    libgimp in order to avoid any virtual method table (since we need to
    keep core and libgimp side's units in sync, PDB is required), but too
    many libgimpwidgets widgets were already using GimpUnit. And technically
    most of GimpUnit logic doesn't require PDB (only the creation/sync
    part). This is one of the reasons why user-created GimpUnit list is
    handled and stored differently from other types of objects.
    
    Globally this simplifies the code a lot too and we don't need separate
    implementations of various utils for core and libgimp, which means less
    prone to errors.
    d493f053
Loading