1. 21 Jul, 2018 1 commit
    • Michael Natterer's avatar
      Initial space invasion commit in GIMP · e09e563a
      Michael Natterer authored
      All babl formats now have a space equivalent to a color profile,
      determining the format's primaries and TRCs. This commit makes GIMP
      aware of this.
      - enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA
        as deprecated aliases, add PERCEPTUAL values so we now have LINEAR,
        NON_LINEAR and PERCPTUAL for each encoding, matching the babl
        encoding variants RGB, R'G'B' and R~G~B~.
      - gimp_color_transform_can_gegl_copy() now returns TRUE if both
        profiles can return a babl space, increasing the amount of fast babl
        color conversions significantly.
      - TODO: no solution yet for getting libgimp drawable proxy buffers in
        the right format with space.
      - follow the GimpPrecision change.
      - TODO: everything else unchanged and partly broken or sub-optimal,
        like setting a new image's color profile too late.
      - add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as
        replacement for all "linear" booleans.
      - change gimp-babl functions to take babl spaces and GimpTRCType
        parameters and support all sorts of new perceptual ~ formats.
      - a lot of places changed in the early days of goat invasion didn't
        take advantage of gimp-babl utility functions and constructed
        formats manually. They all needed revisiting and many now use much
        simpler code calling gimp-babl API.
      - change gimp_babl_format_get_color_profile() to really extract a
        newly allocated color profile from the format, and add
        gimp_babl_get_builtin_color_profile() which does the same as
        gimp_babl_format_get_color_profile() did before. Visited all callers
        to decide whether they are looking for the format's actual profile,
        or for one of the builtin profiles, simplifying code that only needs
        builtin profiles.
      - drawables have a new get_space_api(), get_linear() is now get_trc().
      - images now have a "layer space" and an API to get it,
        gimp_image_get_layer_format() returns formats in that space.
      - an image's layer space is created from the image's color profile,
        change gimpimage-color-profile to deal with that correctly
      - change many babl_format() calls to babl_format_with_space() and take
        the space from passed formats or drawables
      - add function gimp_layer_fix_format_space() which replaces the
        layer's buffer with one that has the image's layer format, but
        doesn't change pixel values
      - use gimp_layer_fix_format_space() to make sure layers loaded from
        XCF and created by plug-ins have the right space when added to the
        image, because it's impossible to always assign the right space upon
        layer creation
      - "assign color profile" and "discard color profile" now require use
        of gimp_layer_fix_format_space() too because the profile is now
        embedded in all formats via the space.  Add
        gimp_image_assign_color_profile() which does all that and call it
        instead of a simple gimp_image_set_color_profile(), also from the
        PDB set-color-profile functions, which are essentially "assign" and
        "discard" calls.
      - generally, make sure a new image's color profile is set before
        adding layers to it, gimp_image_set_color_profile() is more than
        before considered know-what-you-are-doing API.
      - take special precaution in all places that call
        gimp_drawable_convert_type(), we now must pass a new_profile from
        all callers that convert layers within the same image (such as
        image_convert_type, image_convert_precision), because the layer's
        new space can't be determined from the image's layer format during
        the call.
      - change all "linear" properties to "trc", in all config objects like
        for levels and curves, in the histogram, in the widgets. This results
        in some GUI that now has three choices instead of two.
        TODO: we might want to reduce that back to two later.
      - keep "linear" boolean properties around as compat if needed for file
        pasring, but always convert the parsed parsed boolean to
      - TODO: the image's "enable color management" switch is currently
        broken, will fix that in another commit.
  2. 19 Jul, 2018 2 commits
  3. 18 Jul, 2018 3 commits
  4. 17 Jul, 2018 6 commits
    • Jehan's avatar
      app: set overrided system extensions as unsensitive. · acdf169d
      Jehan authored
      When a user extension with same id as a system extension is installed,
      set the system extension unsensitive in the GUI (as well as extensions
      with missing requirements, though it is not implemented yet).
      The reason why I broke this change in 2 commits (with the previous
      commit) is because it will allow to easily cherry-pick the core code
      commits whereas the GTK+ code will have to be reimplemented for
      gimp-2-10 since this widget uses GTK+3 API.
    • Jehan's avatar
      app: functions to manage running extensions. · 4d745743
      Jehan authored
      Add gimp_extension_manager_can_run() and rename function:
      A system extension cannot be run if it has been overrided by a
      user-installed extension of same ID. Moreover extensions can have GIMP
      version requirements as well as have dependency on other extensions
      (though these are not implemented yet).
    • Jehan's avatar
      app: serialize and deserialize extensionrc from GimpExtensionManager. · 02aec4c3
      Jehan authored
      We only save the active state of extensions so that we can reload all
      extensions same as they were at previous exit. All other data are saved
      as per-extension metadata and should not be saved in the rc file.
      If an extension is not listed in extensionrc, we run it by default if
      this is a system extension (so that new core extensions by the GIMP team
      are run when installed after an updated), but not when they are
      user-installed extensions.
    • Ell's avatar
      app: fix dynamics editor "fade" curve color · b2a9bb46
      Ell authored
      In the dynamics editor, use the neutral curve color, which depends
      on the current theme, for the "fade" curve, instead of hard-coding
      it to dark gray, which is hardly visible with dark themes.
    • Ell's avatar
      app: indentation fix in gimppluginmanager-restore.c · bfc26817
      Ell authored
    • Ell's avatar
      app, pdb: add gimp-register-file-handler-priority procedure · b4ac9568
      Ell authored
      Add a gimp-register-file-handler-priority procedure, which can be
      used to set the priority of a file-handler procedure.  When more
      than one file-handler procedure matches a file, the procedure with
      the lowest priority is used; if more than one procedure has the
      lowest priority, it is unspecified which one of them is used.  The
      default priority of file-handler procedures is 0.
      Add the necessary plumbing (plus some fixes) to the plug-in manager
      to handle file-handler priorities.  In particular, use two
      different lists for each type of file-handler procedures: one meant
      for searching, and is sorted according to priority, and one meant
      for display, and is sorted alphabetically.
  5. 16 Jul, 2018 5 commits
    • Michael Natterer's avatar
      app: opaque in gimp_layer_new() is 1.0 not 255 · ac5f44eb
      Michael Natterer authored
      The value is later CLAMP()ed correctly, but fix the call in xcf-load.c
    • Ell's avatar
      app: update GimpToolCompass when display is scaled/rotated · a810c6b6
      Ell authored
      In GimpToolCompass (and, as a consequence, in the measure tool),
      update the measured angle when the shell is scaled, rotated, or
      flipped, so that we always satisfy the compass's constrains, and
      render correctly.
    • Ell's avatar
      app: in GimpToolCompass, add visual distinction between angle lines · 0f03f9e9
      Ell authored
      When using a GimpToolCompass in 3-point mode, add a small gap after
      the angle arc to the line corresponding to the "second" non-origin
      point, so that it's visually distinguishable from the line
      corresponding to the "first" point.  This has significance for the
      measure tool, since it determines the direction of the rotation
      when straightening the image (the first point is rotated toward the
      second point.)
    • Ell's avatar
    • Ell's avatar
      Issue #1850 - Undoing the "straighten" operation in the Measure tool ... · 2e08c916
      Ell authored
      ... does not restore the measure points
      Halt the measure tool after straightening, thus removing the
      expectation that undoing the operation should restore the original
      Halting the tool, rather than making undo work "as expected",
      sidesteps several issues:
        - Implementing undo correctly is tricky, since image-undo and
          tool-undo are handled separately.
        - In fact, the measure tool doesn't provide tool-undo, so that
          image edits can be undone while the tool is active without
          affecting the tool, and it's not clear that we want to change
          this behavior.  However, this makes undoing a straighten
          operation a special case, and it's not entirely clear what the
          behavior should be when undoing other kinds of transformations,
          or when the measure points had changed since the straighten
        - Perhaps most importantly, measure tool points are restricted to
          the pixel grid, which means that when measuring an angle
          against an orientation that's not fully horizontal or vertical
          in image space (either using a 3-point angle, or when the
          canvas is rotated), the resulting transformed point after
          straightening doesn't generally land on the pixel grid, causing
          it to be rounded, which can result in a non-zero angle after
          the rotation.  This is especially ugly, since clicking
          "straighten" again at this point would cause another non-
          trivial rotation.
  6. 15 Jul, 2018 16 commits
    • Ell's avatar
      app: bind "orientation" measure-tool option to compass · 7a91aabf
      Ell authored
      Bind the "orientation" property of the measure-tool options to the
      tool's compass widget's "orientation" property, instead of manually
      synchronizing their values.
    • Michael Natterer's avatar
      Issue #1805 - Sample Points keep resetting themselves to "Pixel" · 47a008be
      Michael Natterer authored
      Rename XCF property PROP_SAMPLE_POINT to PROP_OLD_SAMPLE_POINT and add
      The new property saves the sample point's pick mode plus some padding
      for whatever else we might want to add. Always save the old property
      too so nothing changes for older GIMP versions, and avoid loading the
      old property if the new one was loaded before.
    • Ell's avatar
      Issue #1851 - Measure tool straighten rotation is always to the horizontal. · cb3b7a1b
      Ell authored
      Add an "orientation" option to the measure tool, corresponding to
      the "orientation" property of GimpToolCompass (i.e., it controls
      the orientation against which the angle is measured, when not in 3-
      point mode.)  The orientation is "auto" by default, so that the
      angle is always <= 45 deg.  Note that the "orientation" option
      affects the tool's "straighten" function, so that the layer is
      rotated toward the current orientation.
      Use the "pixel-angle" and "unit-angle" properies of
      GimpToolCompass to read the measured angle, instead of duplicating
      the angle-measurement logic, in particular, so that we benefit from
      the improvements/fixes of the previous commit.
    • Ell's avatar
      app: add "orientation" property to GimpToolCompass + improvements · d2f33cf1
      Ell authored
      Add an "orientation" property to GimpToolCompass, which can be one
      of "auto", "horizontal", or "vertical", and which controls the
      orientation of the line against which the angle is measured, when
      not in 3-point mode (previously, the line would always be
      horizontal.)  When "orientation" is "auto", the orientation is
      automatically set to either horizontal or vertical, such that the
      measured angle is <= 45 deg.
      Keep the line horizontal, or vertical, in display-space, rather
      than in image-space, so that the compass works correctly even when
      the canvas is rotated and/or flipped.
      Fix the compass's behavior when the image's horizontal and vertical
      resolutions are different, both with and without dot-for-dot.
      Add "pixel-angle" and "unit-angle" read-only properties, which
      return the measured angle either with or without taking the image's
      resolution into account, respectively.  These properties will be
      used by the measure tool in the next commit, instead of having it
      implement its own angle calculation.
    • Ell's avatar
      app: fix line-angle constraint when xres != yres · 4fefab17
      Ell authored
      Fix gimp_constrain_line() and friends to properly constrain line
      angles when the image's horizontal and vertical resolutions are
      different, and dot-for-dot is disabled.
    • Michael Natterer's avatar
      Issue #1805 - Sample Points keep resetting themselves to "Pixel" · a0129504
      Michael Natterer authored
      Remember the sample point's GimpColorPickMode in the sample point
      itself, so it is remembered across switching between images.
      Not persistent in the XCF yet tho...
    • Michael Natterer's avatar
    • Michael Natterer's avatar
      app: sort core-enums.h alphabetically · a7a277ef
      Michael Natterer authored
      Sorry for messing with git diffs, but this unsorted mess has been
      annoying since forever.
    • Michael Natterer's avatar
      app: minor cleanup in gimpguide.c · 827faa2a
      Michael Natterer authored
    • Michael Natterer's avatar
      app: add GimpAuxItem as base class for GimpGuide and GimpSamplePoint · 2cd829eb
      Michael Natterer authored
      and GimpAuxItemUndo for their respective undo classes.
    • Michael Natterer's avatar
      app: turn GimpSamplePoint into a GObject, just like GimpGuide · b4c244b8
      Michael Natterer authored
      In fact, they are so similar now, they should get a common abstract
      parent class.
    • Michael Natterer's avatar
    • Michael Natterer's avatar
      app: rename enum GimpColorPickMode to GimpColorPickTarget · b140b283
      Michael Natterer authored
      This is just some preparation for fixing issue #1805, but actually
      "target" is a much better name so I went the full way and also changed
      GUI labels and the color picker tool options config property
      If anyone notices at all, how horrible is it to lose your saved pick
    • Michael Natterer's avatar
      app: fix GimpControllerWheel for smooth scrolling events · 8b71d326
      Michael Natterer authored
      gimp_controller_wheel_scroll(): attempt to translate smooth scroll
      deltas to GdkScrollDirection, controller events are always discrete
      Works fine on X11, no idea how it behaves on other backends, please
      check and report.
    • Ell's avatar
      app: flush async-operations queue when setting async thread count to 0 · 432a8847
      Ell authored
      In gimp-parallel, always flush the async-operations queue (by
      executing all remaining operations on the caller thread) when
      setting the async-pool thread count to 0 (as happens when setting
      GEGL_THREADS=1, per the previous commit,) and not only when
      shutting GIMP down.  Otherwise, pending asynchronous operations
      can "get lost" when setting GEGL_THREADS to 1.
      Additionally, in gimp_gegl_init(), initialize gimp-parallel before
      before connecting to GimpGeglConfig's "notify::num-processors"
      signal, so that the number of async threads is set *before*
      GEGL_THREADS, in order to avoid setting GEGL_THREADS to 1 while
      async operations are still executing.
      Also, allow setting the number of gimp-parallel-distribute threads
      while a gimp-parallel-distribute function is running (which can
      happen if gimp-parallel-distribute is used in an async operation,
      as is the case for histogram calculation), by waiting for the
      parallel-distribute function to finish before setting the number of
    • Ell's avatar
      app: disable parallel asynchronous operations when GEGL_THREADS=1 · 40854065
      Ell authored
      When GEGL_THREADS=1, concurrent access to the same buffer is not
      safe, which can result in errors if asynchronous operations are
      allowed to run in parallel to the main thread (see
      #1721 (comment 265898).)
      Disable parallel execution of asynchronous operations when
      GEGL_THREADS=1 for now, to fix this.  Ultimately, GEGL should be
      able to remain thread-safe even when GEGL_THREADS=1.  Note that we
      want to execute asynchronous operations on a separate thread even
      when GEGL_THREADS=1, since the goal here is mainly to avoid
      blocking the main thread during their execution, rather than
      speeding their execution up (in particular, it's benecifical to run
      asynchronous operations in parallel even on a single-core machine,
      while parallelizing GEGL operations generally isn't.)
  7. 14 Jul, 2018 4 commits
  8. 13 Jul, 2018 3 commits