1. 02 Aug, 2020 1 commit
  2. 30 Jul, 2020 4 commits
  3. 16 Jun, 2020 1 commit
  4. 06 May, 2020 1 commit
  5. 17 Mar, 2020 1 commit
    • luz.paz's avatar
      Fix typos · 83da81f3
      luz.paz authored
      Found via `codespell -q 3 -S ./ChangeLog*,*.po -L als,ang,ba,chello,daa,doubleclick,foto,hist,iff,inport,klass,mut,nd,ower,paeth,params,pard,pevent,sinc,thru,tim,uint`
      
      (cherry picked from commit a928452e)
      83da81f3
  6. 16 Feb, 2020 1 commit
  7. 15 Jan, 2020 2 commits
  8. 06 Jan, 2020 2 commits
  9. 16 Nov, 2019 1 commit
  10. 12 Oct, 2019 1 commit
  11. 26 Sep, 2019 1 commit
    • Jehan's avatar
      Issue #3990: make the status of the XCF docs a bit clearer (hopefully). · 8a400e30
      Jehan authored
      Though it may have started as an unofficial document, it is clearly now
      an official one (which should be obvious since it is in our source
      repository, but apparently some people get misled by the historical
      "Status" text to think this to be somehow unofficial).
      So first of all, change the s/official/unofficial/ mention.
      
      Secondly, add a small paragraph explicitly telling that the document is
      complete (and meant to be), to the best of our knowledge. This document
      is a detailed, full and exhaustive written "specification" of the XCF
      format up to GIMP 2.10.x (even though the normative spec is still the
      code itself). Now we are humans, we may have missed something, and if
      so, this is just to be considered as any other bug, and reported to us
      nicely to be fixed.
      
      (cherry picked from commit 80e2e0a5)
      8a400e30
  12. 23 Jul, 2019 2 commits
  13. 06 Jun, 2019 1 commit
  14. 23 Jan, 2019 3 commits
  15. 16 Jan, 2019 1 commit
  16. 27 Dec, 2018 1 commit
    • Ell's avatar
      app: remove "Edit -> Fade..." · 23ae869f
      Ell authored
      This commit completely removes the "Edit -> Fade..." feature,
      because...
      
      - The main reason is that "fade" requires us to keep two buffers,
        instead of one, for each fadeable undo step, doubling (or worse,
        since the extra buffer might have higher precision than the
        drawable) the space consumed by these steps.  This has notable
        impact when editing large images.  This overhead is incurred even
        when not actually using "fade", and since it seems to be very
        rarely used, this is too wasteful.
      
      - "Fade" is broken in 2.10: when comitting a filter, we copy the
        cached parts of the result into the apply buffer.  However, the
        result cache sits after the mode node, while the apply buffer
        should contain the result of the filter *before* the mode node,
        which can lead to wrong results in the general case.
      
      - The same behavior can be trivially achieved "manually", by
        duplicating the layer, editing the duplicate, and changing its
        opacity/mode.
      
      - If we really want this feature, now that most filters are GEGL
        ops, it makes more sense to just add opacity/mode options to the
        filter tool, instead of having this be a separate step.
      
      (cherry picked from commit ed7ea51f)
      23ae869f
  17. 19 Dec, 2018 2 commits
  18. 04 Dec, 2018 1 commit
    • Ell's avatar
      Issue #2604 - XCF saving bug in xcf_save_buffer() · b06ffe43
      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
      version.
      
      (cherry picked from commit 2168d91c)
      b06ffe43
  19. 10 Nov, 2018 1 commit
    • Ell's avatar
      libgimpwidgets: add GimpSpinButton · d928ed72
      Ell authored
      GimpSpinButton is a drop-in replacement for (and a subclass of)
      GtkSpinButton.  Unlike GtkSpinButton, it avoids updating the
      adjustment value when losing focus, unless the entry text has
      changed.  This prevents accidental loss of precision, when the
      adjustment value can't be accurately displayed in the entry.
      
      Note that libgimpwidgets already defines a (deprecated)
      gimp_spin_button_new() function.  This commit stays compatible with
      the old function, by defining GimpSpinButton's _new() function as
      gimp_spin_button_new_(), and defining a variadic
      gimp_spin_button_new() macro, which expands to either the old or
      the new function, based on the number of arguments, so that either
      function can be used transparently as gimp_spin_button_new().  This
      is all gone in master.
      d928ed72
  20. 08 Nov, 2018 5 commits
  21. 30 Oct, 2018 1 commit
  22. 16 Sep, 2018 1 commit
    • Jehan's avatar
      devel-docs: add the package maintainers in the release-howto. · eb227b1d
      Jehan authored
      Nicknames on IRC/gitlab are hard, even more when they change depending
      on the media! I realize we are regularly asking them or unsure of who to
      contact (for instance here for releases). Let's associate each package
      with its current maintainer to make it easy to contact the right person
      to prepare our official packages before a release.
      
      (cherry picked from commit dc9a3044)
      eb227b1d
  23. 20 Aug, 2018 1 commit
  24. 17 Jul, 2018 1 commit
    • Ell's avatar
      app, pdb: add gimp-register-file-handler-priority procedure · c5c0f873
      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.
      
      (cherry picked from commit b4ac9568)
      c5c0f873
  25. 14 Jul, 2018 1 commit
  26. 11 Jul, 2018 1 commit
  27. 27 Jun, 2018 1 commit