- 02 Aug, 2020 1 commit
-
- 30 Jul, 2020 4 commits
-
- 16 Jun, 2020 1 commit
-
-
lillolollo authored
-
- 06 May, 2020 1 commit
-
- 17 Mar, 2020 1 commit
-
- 16 Feb, 2020 1 commit
-
-
Ell authored
-
- 15 Jan, 2020 2 commits
- 06 Jan, 2020 2 commits
- 16 Nov, 2019 1 commit
-
- 12 Oct, 2019 1 commit
-
- 26 Sep, 2019 1 commit
-
-
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)
-
- 23 Jul, 2019 2 commits
-
-
Michael Natterer authored
-
Michael Natterer authored
-
- 06 Jun, 2019 1 commit
-
- 23 Jan, 2019 3 commits
-
- 16 Jan, 2019 1 commit
-
- 27 Dec, 2018 1 commit
-
-
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)
-
- 19 Dec, 2018 2 commits
-
- 04 Dec, 2018 1 commit
-
-
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)
-
- 10 Nov, 2018 1 commit
-
-
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.
-
- 08 Nov, 2018 5 commits
-
- 30 Oct, 2018 1 commit
-
- 16 Sep, 2018 1 commit
-
-
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)
-
- 20 Aug, 2018 1 commit
-
- 17 Jul, 2018 1 commit
-
-
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)
-
- 14 Jul, 2018 1 commit
-
-
Michael Natterer authored
Including all user-visible link and links called from code, like the help pages. (cherry picked from commit bab75b73)
-
- 11 Jul, 2018 1 commit
-
-
Michael Natterer authored
(cherry picked from commit 8eb77376)
-
- 27 Jun, 2018 1 commit
-
-
Jehan authored
As discussed on IRC with Mitch and Samm. Older versions may work, and Samm says he will build for 10.9 actually, but we officially only supports for 10.10.
-