1. 22 Aug, 2020 4 commits
  2. 19 Aug, 2020 2 commits
  3. 18 Aug, 2020 1 commit
    • Jacob Boerema's avatar
      plug-ins: improve psp image reader stability by always using the block/chunk length. · 15ad9522
      Jacob Boerema authored
      Starting from psp file version 4 the specification recommends to always use the
      block/chunk length to determine the next part of the image. This way it is
      possible to skip parts you don't know or don't care about or additions in
      newer versions.
      This change makes sure to always do this which fixes reading several images
      which crashed the plug-in before.
      Also only try to read layer data if it is a raster layer.
  4. 17 Aug, 2020 3 commits
    • Jehan's avatar
      app: "drawable-linked" multi-drawable aware. · e50f522d
      Jehan authored
    • Jehan's avatar
      app: GimpSelectionEditor multi-drawable aware. · 84e587d2
      Jehan authored
      When clicking on the selection mask (in the dockable view) or when
      dropping a color on this same view, we can now select by color based on
      the selected layer composition (not only one single layer, nor the whole
      image as sample merged, but also a specific list of composited layers).
      gimp_channel_select_by_color() is made multi-drawable aware as a
      consequence of this.
    • Jehan's avatar
      app: (selection editor) fix clicking on selection mask or dropping color · bd452d7d
      Jehan authored
      I discover that the selection editor has these hidden features that (1)
      you can click on the selection mask (in the editor dockable) and it
      behaves like the Select by Color tool (not sure exactly how useful this
      feature is as you can't really see where you click though) and (2) you
      can drop a color and it will select this color also as though clicked by
      the Select by Color tool (which looks quite useful!).
      These features use the option values as set in the Select by Color tool.
      Unfortunately both these features were broken when a non-zero threshold
      was set because it expects a [0-1] range whereas threshold is [0-255].
      Fix the parameters in gimp_channel_select_by_color() call.
  5. 16 Aug, 2020 1 commit
    • Jehan's avatar
      Issue #5530: do not fail font loading on broken user/GIMP fonts.conf. · c5f9b8e1
      Jehan authored
      Additionally to loading the default fontconfig configuration file, GIMP
      also looks up /etc/gimp/<version>/fonts.conf and
      $XDG_CONFIG_HOME/GIMP/<version>/fonts.conf (or equivalent in other
      OSes). If these don't exist (which is the most common case), this is not
      considered a bug. Fontconfig had a regression bug of
      FcConfigParseAndLoad() in 2.13.92, which was fixed in a later commit:
      As a consequence of this bug, font loading failed in Windows when these
      non-mandatory files were absent.
      The current commit, originally proposed by Jacob Boerema (@Wormnest) and
      slightly reviewed works around the issue, because anyway there is never
      any reason why failing to load these files should break font loading as
      a general rule. Even if these files exist and are broken (wrong syntax
      or whatnot), we should just output some warning on stderr and continue
      loading without these additional confs.
      With fontconfig 2.13.92, warnings will be also outputted (wrongly), but
      at least it won't block loading anymore.
      Also let's unref() the `config` object even when the whole font loading
      succeeds. Man of FcConfigSetCurrent() clearly says that the reference
      count of config is incremented since 2.12.0 (our current minimum
      fontconfig is 2.12.4) so let's not leak one reference.
  6. 15 Aug, 2020 1 commit
  7. 11 Aug, 2020 2 commits
  8. 09 Aug, 2020 2 commits
  9. 08 Aug, 2020 4 commits
  10. 07 Aug, 2020 3 commits
  11. 06 Aug, 2020 2 commits
    • Piotr Drąg's avatar
      Update Polish translation · 30d73c63
      Piotr Drąg authored
    • Jehan's avatar
      gitlab-ci: rename the CI jobs. · bd6abe06
      Jehan authored
      The Linux CI job names are too long and are not recognizable on the web
      GUI unless you hover the widgets with the mouse to read tooltips. Remove
      the "/testing" part (if people want to know exactly which Debian we use
      for our builds, they can always look at the script) and move left the
      differenciating parts (i.e. autotools/meson/clang/distcheck) so that
      these are visible in a glance, even when ellipsing long job names.
  12. 05 Aug, 2020 5 commits
    • Anders Jonsson's avatar
      Update Swedish translation · b8d15136
      Anders Jonsson authored
    • Jehan's avatar
      libgimpwidgets: improve/fix more of GimpMemSizeEntry. · d886bb1b
      Jehan authored
      Looking further at this widget, many things are not right. Here are the
      - Use binary prefixes (i.e. kibibyte, mebibyte and gibibyte) instead of
        decimal ones. We are making binary shifts so we were actually showing
        the wrong units.
      - Round the value to the closest integer when showing it, not towards 0.
        Otherwise I had cases where it was showing 7GiB for an actual value of
        7.69GiB (default as computed by GIMP from my actual physical memory).
        Note that I am actually unsure even rounding makes sense. Shouldn't we
        rather show double values with a few digits after the decimal points?
        For such values, I think it would make sense.
      - Do not edit the internally saved accurate value when the entry is
        edited to the same less accurate value as our saved value would be
        shown too. In particular when changing the display unit to a bigger
        one, we don't want to lose accuracy. This is especially true for low
        values. Say you don't have a lot of memory and you set the Tile cache
        size to 1.5GiB (1536MiB), you certainly don't want it to become either
        1 or 2GiB when switching display unit to GiB. Now even if the number
        will still display with less accuracy, the internal value will stay
    • Jehan's avatar
      libgimpwidgets: fix setting GimpMemSizeEntry value with unit change. · 0be4e5c1
      Jehan authored
      This bug doesn't happen when setting value through the GUI as in such
      case, the unit never changed. It happened when setting a value which
      could not be properly displayed by current unit (typically smaller than
      1 in this unit, or with remainder).
      In such a case, we should not manually set private->shift before
      gimp_int_combo_box_set_active(), or the callback was failing to
      reconfigure the GtkAdjustement, in particular min and max values.
      As a consequence, hitting a Preferences reset, with a GimpMemSizeEntry
      in Gigabytes, it got reset to Kilobytes with the max values capped at
      4096. So I realized a Reset ended me with a Tile cache size of 4096 KB
      in particular, which is of course ridiculously small and would be a
      problem if one doesn't notice the issue immediately.
    • Marco Ciampa's avatar
      Updated Italian translation · b8d96c49
      Marco Ciampa authored
    • Dimitris Spingos's avatar
      Updated Greek translation · a68989e7
      Dimitris Spingos authored
  13. 04 Aug, 2020 1 commit
  14. 03 Aug, 2020 4 commits
  15. 02 Aug, 2020 5 commits