1. 23 Oct, 2018 1 commit
    • Elle Stone's avatar
      Issue #2345 - Add xyY to color sample readouts · 298cc570
      Elle Stone authored
      Add xyY color space to the color spaces for sampling colors.
      Also add code to xcf-load.c that makes sure the sample point loading
      code handles unknown future GimpColorPickMode values (fall back to
      PIXEL pick mode).
  2. 07 Oct, 2018 1 commit
    • Michael Natterer's avatar
      app: remove the image's "Enable Color Management" toggle · c399b894
      Michael Natterer authored
      It was not doing anything right since space invasion. We now treat the
      built-in sRGB profile like any other profile and never bypass
      conversions based on some weird toggle.
      Instead, introduce a "Use sRGB Profile" toggle which, when enabled,
      hides whatever profile away so the image actually uses the built-in
      sRGB profile.
      This is different from discarding and then re-assigning the same
      profile only by being faster and more convenient.
  3. 24 Jul, 2018 1 commit
  4. 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.
  5. 15 Jul, 2018 2 commits
  6. 09 Jun, 2018 1 commit
    • Ell's avatar
      app: add GimpTransformGridTool; derive most transform tools from it · 1dbe7659
      Ell authored
      While most of our transform tools use an interactive transform
      grid, and have similar behavior, the flip tool is an odd one out.
      The new "auto straighten" function of the measure tool introduces
      another tool that performs transformations, while not behaving like
      the rest of the transform tools.
      Factor out the parts of GimpTransformTool that handle user
      interaction into GimpTransformGridTool (with corresponding
      GimpTransformGridOptions, and GimpTransformGridToolUndo), and only
      leave the basic transform functionality and options in
      GimpTransformTool (and GimpTransformOptions).
      Derive all the transform tools (and transform-tool base classes)
      that previously derived from GimpTransformTool, from
      GimpTransformGridTool.  The one exception is GimpFlipTool, which
      still derives from GimpTransformTool directly.  The next commit
      will derive GimpMeasureTool from GimpTransformTool as well.
  7. 22 Apr, 2018 2 commits
    • Ell's avatar
      Bug 795410 - Deleting a layer group and then undoing the deletion ... · 37742a9f
      Ell authored
      ... raises a CRITICAL
      gimp_item_{start,end}_move() currently serves two different
      purposes:  It is used by GimpLayer to suspend/resume mask resizing
      of the layer's ancestors; this is necessary whenever an operation
      on a layer might affect the size of its ancestors.  It is also used
      by GimpGroupLayer to suspend/resume its own mask resizing; this, on
      the other hand, is only necessary before applying one of the
      transformation functions to the group, so that mask modification is
      handled by GimpLayer.  In other words, the effects of
      gimp_item_{start,end}_move() on group layers are only necessary in
      a subset of the cases in which these functions are used.
      While in itself this isn't a problem, it does cause issues when
      removing a group layer:  gimp_image_remove_layer() calls
      gimp_item_start_move() before removing the layer, and
      gimp_item_end_move() afterwards.  While the former function is
      called while the layer is still attached to the image, the latter
      function is called after the layer is no longer attached.  Since
      GimpGroupLayer pushes an undo step in response to these calls, only
      the call to start_move() results in an undo step, while the call to
      end_move() doesn't, resulting in an unbalanced
      GIMP_UNDO_GROUP_LAYER_START_MOVE undo step on the stack.  This
      causes problems when undoing the operation.
      Add gimp_item_{start,end}_transform() functions, and corresponding
      GimpItem::{start,end}_transform() virtual functions, which are more
      specialized versions of gimp_item_{start,end}_move(), which should
      be used instead of the former before/after transforming an item; in
      other cases, such as when removing ot reordering an item,
      gimp_item_{start,end}_move() should still be used.  The default
      implementation of GimpItem::{start,end}_transform() calls
      gimp_item_{start,end}_move(), respectively, so subclasses that
      override these functions don't have to do that themselves.
      In GimpGroupLayer, override GimpItem::{start,end}_transform(),
      instead of GimpItem::{start,end}_move(), for the same purpose of
      suspending mask resize.  This avoids these functions from being
      called when removing a layer group, fixing the bug.
    • Ell's avatar
      app: fix undo when moving a group-layer child outside the group · 577e1703
      Ell authored
      In gimp_image_reorder_item(), call gimp_item_start/end_move()
      before/after reordering the item (and use an undo group, so that
      the resulting undo actions are grouped together with the reordering
      undo action,) so that if the item is a child of a group layer, and
      reordering moves it out of the group in a way that causes the
      group's mask to be resized, the mask will be properly restored when
      undoing the operation.
  8. 25 Mar, 2018 1 commit
    • Ell's avatar
      app: fix layer-group mask cropping during move operation undo · 76a88cc6
      Ell authored
      In gimp_group_layer_{start,end}_move(), push corresponding undo
      steps, which perform the opposite operation during undo, and make
      sure that mask-cropping is frozen during group-layer move
      This fixed erroneous group-layer mask cropping when undoing/redoing
      a group-layer move operation multiple times.
  9. 12 Feb, 2018 1 commit
    • Jehan's avatar
      app: add GIMP_MESSAGE_BUG_WARNING + GIMP_MESSAGE_BUG_CRITICAL severity. · 77ed4761
      Jehan authored
      Since a few commits, I don't generate the traces anymore in errors.c but
      delay this to gui-message.c and rely on the message severity to decide
      whether or not generating traces.
      Unfortunately none of the current severities are properly describing
      this new type of messages. Even GIMP_MESSAGE_ERROR is used everywhere in
      our code NOT for actual programming bug, but often for data errors
      (which are not bugs but proper messages and should obviously not prompt
      a debug trace).
  10. 08 Feb, 2018 1 commit
    • Jehan's avatar
      app: make debugging preference finer-grained than a boolean. · d5a67cb1
      Jehan authored
      Replacing the boolean property "generate-backtrace" by an enum
      "debug-policy". This property allows one to choose whether to debug
      WARNING, CRITICAL and FATAL (crashes), or CRITICAL and FATAL only, or
      only FATAL, or finally nothing.
      By default, a stable release will debug CRITICAL and crashes, and
      unstable builds will start debugging at WARNINGs.
      The reason for the settings is that if you stumble upon a reccurring bug
      in your workflow (and this bug is not major enough for data corruption,
      and "you can live with it"), you still have to wait for a new release.
      At some point, you may want to disable getting a debug dialog, at least
      temporarily. Oppositely, even when using a stable build, you may want to
      obtain debug info for lesser issues, even WARNINGs, if you wish to help
      the GIMP project.
      It can be argued though whether the value GIMP_DEBUG_POLICY_NEVER is
      really useful. There is nothing to gain from refusing debugging info
      when the software crashed anyway. But I could still imagine that someone
      is not interested in helping at all. It's sad but not like we are going
      to force people to report. Let's just allow disabling the whole
      debugging system.
  11. 05 Feb, 2018 1 commit
    • Ell's avatar
      Bug 51112 - Support layer masks on layer groups · 36dec4e6
      Ell authored
      Add layer-mask support for group layers.  Group-layer masks work
      similarly to ordinary-layer masks, with the following
      The group's mask size is the same as group's size (i.e., the
      bounding box of its children) at all times.  When the group's size
      changes, the mask is cropped to the new size -- areas of the mask
      that fall outside of the new bounds are discarded and their data is
      lost (sans undo), and newly added areas are filled with black (and
      hence are transparent by default).
      The new gimp_group_layer_{suspend,resume}_mask() functions can be
      used to modify this behavior.  Between the outermost pair of
      suspend/resume calls, the old mask data is remembered, and is used
      to fill the newly added areas while cropping the mask when the
      group is resized.  We override GimpItem::{start,end}_move() for
      GimpLayer, to call these functions (suspend() in start_move(), and
      resume() in end_move()) for each of the layer's ancestors.
      As a result, while moving a layer, or a set of layers, atomically,
      such as while dragging with the move tool, or moving linked layers,
      the ancestors' mask data is not lost, and is only discarded at the
      end of the operation.
      This commit also takes care of properly handling undo for group-
      layer mask crops, properly invalidating the image when the group
      layer's mask is shown, and enabling the mask actions for group
      layers (obviously :).
  12. 30 Nov, 2017 3 commits
    • Piotr Drąg's avatar
      app: fix a typo (transarent) · 33d4095f
      Piotr Drąg authored
    • Ell's avatar
      app: modify unabbreviated value descriptions of GimpGradientColor · a08a9171
      Ell authored
      ... to match the old gradient editor menu labels.
    • Ell's avatar
      libgimpbase, app: add abbreviations to gradient enums · d3e527a9
      Ell authored
      The value descriptions of GimpGradientColor,
      GimpGradientSegmentColor, and GimpGradientSegmentType enums appear
      in the on-canvas gradient editor UI, as combo-box items in the tool
      GUI overlay.  Since we want to keep the overlay as small as
      possible, we previously used abbreviations for these descriptions
      (e.g., "FG (t)", instead of "Foreground (transparent)").
      Replace the abbreviated descriptions with unabbreviated ones, and
      move the abbreviations to the "abbrev" parameter.  This way we get
      the abbreviated version in the combo-box, and the full version in
      the combo-box's menu.
  13. 12 Nov, 2017 1 commit
    • Michael Natterer's avatar
      Bug 789764 - Please add Paste In Place feature · f12d0d8c
      Michael Natterer authored
      Add "In Place" variants for all sorts of pasting:
      - extend the GimpPasteType enum with IN_PLACE values
      - add the needed actions and menu items
      - merge the action callbacks into one, taking an enum value as parameter
      - refactor the pasting code in gimp-edit.c into smaller functions
      We probably have too menu items in the "Edit" menu now, needs to be
      sorted out.
  14. 09 Oct, 2017 1 commit
  15. 06 May, 2017 1 commit
    • Ell's avatar
      enums: generate enum files in source dir · 1e6acbd4
      Ell authored
      We check them into git, so this makes it easier to keep them in
      sync when using a separate build directory.
      Case in point -- this commit also syncs a few enum files that went
      out-of-sync with their headers.
  16. 21 Mar, 2017 1 commit
  17. 26 Feb, 2017 1 commit
  18. 05 Feb, 2017 2 commits
    • Michael Natterer's avatar
      app: move layer mode enums and gimp-layer-modes.[ch] to operations/ · 2950fecf
      Michael Natterer authored
      and to operations/layer-modes/, respectively.
      Add gimp_layer_modes_init() which asserts on the correct order of the
      GimpLayerModeInfo array, and switch to accessing the array directly in
    • Ell's avatar
      app: add "hard mix" blend mode · 8f4700b8
      Ell authored
      Similar to the Photoshop mode of the same name.  Assigns
      either 0 or 1 to each of the channels, depending on whether the
      sum of source and destination channel values is less than, or
      greater than (or equals to), one, respectively.
      This is equivalent to inverting the source, and using it to perform
      per-pixel, per-channel threshold against the destination, which is
      useful for various effects.
  19. 30 Jan, 2017 1 commit
  20. 29 Jan, 2017 1 commit
    • Øyvind "pippin" Kolås's avatar
      app: add darken only, lighten only that uses luminance · e9a6d931
      Øyvind "pippin" Kolås authored
      These variations on darken only and lighten only have the advantage over the
      componentvise versions that they always use the full triplet of either original
      or new layer - meaning no new colors/hues will be introduced. This is similar
      to how these modes operated/operates in picture publisher and photo-paint.
  21. 28 Jan, 2017 1 commit
  22. 26 Jan, 2017 1 commit
  23. 25 Jan, 2017 1 commit
  24. 24 Jan, 2017 1 commit
  25. 23 Jan, 2017 2 commits
  26. 15 Jan, 2017 1 commit
  27. 14 Jan, 2017 3 commits
  28. 12 Jan, 2017 1 commit
  29. 11 Jan, 2017 2 commits
  30. 10 Jan, 2017 2 commits