1. 12 Dec, 2018 6 commits
    • Ask Hjorth Larsen's avatar
    • Alan Mortensen's avatar
      Updated Danish translation · 15049da9
      Alan Mortensen authored
    • Ell's avatar
      app: in the warp tool, blink behavior combo when the current behavior is invalid · 7958387d
      Ell authored
      In the warp tool, when the warp is empty and the current behavior
      has no effect as a result (i.e., when it's ERASE or SMOOTH), show
      an error message in the status bar, and blink the behavior combo
      widget in the tool options, to hint at the source of the error.
    • Ell's avatar
      app: in the warp tool, blink stroke frame when no events are selected · 17cc44a7
      Ell authored
      In the warp tool, when no stroke events are selected, blink the
      stroke frame widget in the tool options, in addition to showing an
      error message in the status bar, to hint at the source of the
    • Ell's avatar
      Ell authored
      The enumerators of the GimpWarpBehavior enum, except for MOVE, had
      a GEGL_ prefix, rather than a GIMP_ prefix, for some reason.
      Change all of them to GIMP_.
    • Jehan's avatar
      app: do not make line art bucket fill a GimpSelectCriterion anymore. · cd924f45
      Jehan authored
      This was my initial choice, but the more I think about it, the less I am
      sure this was the right choice. There was some common code (as I was
      making a common composite bucket fill once the line art was generated),
      but there is also a lot of different code and the functions were filled
      of exception when we were doing a line art fill. Also though there is a
      bit of color works (the way we decide whether a pixel is part of a
      stroke or not, though currently this is basic grayscale threshold), this
      is really not the same as other criterions. In particular this was made
      obvious on the Select by Color tool where the line art criterion was
      completely meaningless and would have had to be opted-out!
      This commit split a bit the code. Instead of finding the line art in the
      criterion list, I add a third choice to the "Fill whole selection"/"Fill
      similar colors" radio. In turn I create a new GimpBucketFillArea type
      with the 3 choices, and remove line art value from GimpSelectCriterion.
      I am not fully happy yet of this code, as it creates a bit of duplicate
      code, and I would appreciate to move some code away from gimpdrawable-*
      and gimppickable-* files. This may happen later. I break the work in
      pieces to not get too messy.
      Also this removes access to the smart colorization from the API, but
      that's probably ok as I prefer to not freeze options too early in the
      process since API needs to be stable. Probably we should get a concept
      of experimental API.
  2. 11 Dec, 2018 2 commits
    • Jehan's avatar
      Issue #2495: different code for Windows and Linux on duplicate devices. · 74a7a5d3
      Jehan authored
      After discussing with Mitch, it turn out commit 717c183a was fixing
      (or rather working around) actual issues of broken device/usb stack
      issues on Linux, as expected.
      Nevertheless on Windows, this broke in turn many tablets (see commit
      ce24e160). Therefore we do a very ugly #ifdef to bail from duplicate
      devices on Windows whereas we continue on Linux. This fix and difference
      of behavior is completely empirical, rather than based on actual good
      logics, so that's quite annoying, but well… not much choice here.
      Also note that since we had no report of breakage on other OSes (such as
      macOS/BSD), at least that I know of, I let them with the Linux code
    • Jehan's avatar
  3. 10 Dec, 2018 11 commits
  4. 09 Dec, 2018 1 commit
  5. 08 Dec, 2018 2 commits
    • Piotr Drąg's avatar
      Update POTFILES.in · 8868dc95
      Piotr Drąg authored
    • Ell's avatar
      Issue #2635 - Segfault when using measuring tool · ad831dbc
      Ell authored
      In gimp_tool_compass_update_angle(), use fuzzy comparisson when
      determining whether to update the angle properties, to avoid
      infinite recursion due to floating-point inaccuracies.  In
      partcicular, on x86, when using the x87 FPU rather than SSE, the
      floating-point registers are 80-bit, while the properties are
      stored as 64-bit, which can create small discrepancies between the
      calculated angles and the stored values.
  6. 07 Dec, 2018 2 commits
    • Jehan's avatar
      app: reorganize the line art code inside a GimpLineArt object. · db18c679
      Jehan authored
      The code was too much spread out, in core and tool code, and also it was
      made too specific to fill. I'll want to reuse this code at least in the
      fuzzy select tool. This will avoid code duplication, and also make this
      new process more self-contained and simpler to review later (the
      algorithm also has a lot of settings and it is much cleaner to have them
      as properties rather than passing these as parameters through many
      The refactoring may not be finished; that's at least a first step.
    • Alexandre Prokoudine's avatar
      Improve pixel format choice UI in PNG exporting options · 27aa87ba
      Alexandre Prokoudine authored
      The former UI did not conform to what we do elsewhere.
      Use label + combo now.
  7. 06 Dec, 2018 2 commits
    • Jehan's avatar
      Issue #2495: many tablets broken by GIMP 2.10.8. · ce24e160
      Jehan authored
      We had many reports of tablets from various brands (Huion, Gaomon,
      XP-Pen…) broken in the last release (though working fine when
      downgrading to 2.10.6). Latest Huion drivers seem to fix the issue
      (according to at least one report), but this is not the case for other
      Though unable to test myself, provided stderr logs indicate that we hit
      the case when 2 devices with the same name are registered. Therefore
      this commit is basically reverting commit 717c183a (though keeping and
      completing the comments). I don't think there is an ultimate solution
      here but with this regression, experience shows us there seem to be a
      lot more breakage when overwriting the device with newer occurences (at
      least on Windows). It is unclear though if commit 717c183a was also
      supposed to fix another case actually encountered. If so, we will need
      to get an even more advanced solution.
    • Ell's avatar
      app: in GimpProjection, fix reinit. of current row when chunk height changes · c9c2397b
      Ell authored
      In GimpProjection's chunk renderer, when the chunk height changes
      in the middle of a row, we need to merge the remainder of the
      current render area back into the renderer's update region, and
      refetch the remainder of the row as the new render area, so that we
      don't miss any unrendered area, or re-render already-rendered area,
      due to the change in chunk height.  However, we should previously
      fail to verify that the fetched area is, in fact, the remainder of
      the current row, which could cause us to render the wrong area,
      missing parts of the update region.
      Fix this, by breaking up some of the chunk-renderer fucntions into
      smaller sub-functions, and using those in order to explicitly set
      the new render area to the remainder of the current row when the
      chunk height changes.  This also avoids erroneously merging the
      unflushed update region of the projection into the renderer's
      update region.
  8. 05 Dec, 2018 3 commits
  9. 04 Dec, 2018 4 commits
    • Michael Natterer's avatar
    • Michael Natterer's avatar
      libgimp: need to expand config->swap_path in gimp_config() · cc835e87
      Michael Natterer authored
      or the file system will be polluted with folders called
    • Ell's avatar
      Issue #2604 - XCF saving bug in xcf_save_buffer() · 2168d91c
      Ell authored
      The NULL terminator of the tile-offset array of dummy buffer-levels
      is erroneously written as an int32, instead of an offset, even in
      version-11+ XCFs, in which offsets are 64-bit.
      Since the dummy levels aren't actually used by GIMP, we're going to
      keep these fields as int32 as an exception, in order to remain
      consistent with existing XCFs, and just add a comment in the code,
      and update the docs.  If we ever make use of the higher buffer
      levels, we should change these fields to offsets, and bump the XCF
    • Michael Natterer's avatar
      Integrate the logic of profile saving with metadata saving · c667fdc5
      Michael Natterer authored
      Add flag GIMP_METADATA_SAVE_COLOR_PROFILE to GimpMetadataSaveFlags and
      initialize it from gimp_export_color_profile() in
      Adapt all plug-ins to use the bit from the suggested export flags and
      pass the actually used value back to
      This changes no behavior at all but creates hooks on the libgimp side
      that are called with the context of an image before and after the
      actual export, which might become useful later. Also, consistency
      is good even though the color profile is not strictly "metadata".
  10. 03 Dec, 2018 6 commits
  11. 02 Dec, 2018 1 commit