GitLab

Currently it's a mandatory option (and it has been the case for years,
ever since commit 43e21885) so let's update the info.

Note that there are still discussions going on about this dependency and
it being hard or impossible to build on many platforms (which are stuck
on old C version, before the move to Rust). See #6821.
We'll see how it goes.

This includes:
- "copy-icon" set
- Permission and cleanup rules updated
- Exiv2 bumped to 0.27.5
- Adding an x-checker-data for OpenEXR
- Poppler bumped to 22.01.00
- OpenBlas bumped to 0.3.19
- graphviz bumped to 2.50.0

We should really get back to a single shared list as we have in
gimp-2-10.

Also just keeping the "no SVG icons" option feels wrong to me, yet it
turns out librsvg is quite a problem because of Rust, so recent versions
are just not available on many platforms (see #6821). This is what
blocked me so far to remove this whole listing of PNG variants for our
vector icon themes. Otherwise they would be gone by now.

I really wonder as well about all these size categories. Not that they
are not needed when in PNG format, but because it feels like nobody has
really taken the time to list which icons are needed in which size for
years. We really need to do some cleaning in this area.

Lukas Oberhuber authored Jan 23, 2022 and Jehan committed Jan 24, 2022

This moves to standard fullscreen behavior for Gimp.

Added benefit is that it no longer requires gdkquartz-cocoa-access.h
which the Gtk team wish to stop supporting gtk!4303.

Bug 756178 also no longer manifests, cdc7542d
so it is now safe to do.

Finally, removes dependency on objective c in the app/display directory.

Since I removed some files and forgot to change these rules. Though I
actually wonder if this still makes sense to distribute all these files
within the tarball anymore. It made sense in the way software was
distributed 20 years ago, but nowadays people who want to develop would
clone the git repo not get a tarball. We'll see.

This change makes sure that plugins can load when gimp is built with
meson. This is because .typelibs and .gir files do not have full library
paths when build using meson (this is different from autotools).

Add some more text and links to existing documents.

I also remove 3 files which are now either outdated or whose contents is
also written (with more or less similar text) in other more up-to-date
files.

Add more links to other files after I reviewed they were still relevant.

The `gitlab-milestones.txt` in particular had to be updated because the
contents was outdated (though we still need to manage milestones, simply
now we are a bit more fine-grained).

Also remove the now deprecated Jenkins tutorial. We have not had this CI
system running for some time now, and the Gitlab CI has totally replaced
it.

Loosely based on the old structure.xml, except it was widely outdated.
So I removed or updated what was obsolete and added missing folders.

Obviously getting rid of the old `structure.xml` (now we have easier doc
generation through Gitlab).

Finally, I fix the table of contents and replaced the title with some
metadata-style stuff which Gitlab docs suggest (otherwise the document
title ends up in the table of contents, which is a bit silly).

Sometimes we want to make quick tests on old versions of GIMP.
Rebuilding from source is definitely still an option, yet with flatpak,
we have many past builds available easily to us (at time of writing: 19
stable builds, 12 dev point-release builds and at least 3 nightlies —
though I seem to have issues with signatures on gnome-nightly right now,
so maybe there are more!).

There are some command lines needed to check the build history, then to
install a specific build, which I explained in developer docs (see
devel-docs/debugging-tips.txt, section "Testing older GIMP versions").
Yet it's clearly cumbersome and slow so I wrote this script today to
automatize the process a bit.

Running simply this command will list all available releases on the
Flathub repository (adding --beta or --nightly will list the development
releases and nightly builds instead):

$ tools/flatpak-releases

The listing will contain a topic describing the build as well as the
date, all this prefixed by a number. For instance, this is an excerpt of
the output for the dev releases:

$ tools/flatpak-releases --beta
 0: Update dependencies (127a0fa7) [2022-01-13 16:59:43 +0000]
 1: Issue #106:  File->Create->From Screenshot not working. (9c831b14) [2021-12-14 21:46:52 +0000]
 2: Release GIMP 2.99.8. (908bf5b0) [2021-10-20 20:29:00 +0000]
 3: Release GIMP 2.99.6. (e04355dd) [2021-04-26 14:08:32 +0000]
 …

The last build updates dependencies, the previous one fixes some
specific issue and the 2 previous ones are point releases.
Now say I needed to test/compare some behavior with how it was in 2.99.6
(e.g. to verify a regression), I would then run:

$ tools/flatpak-releases --beta -3

This would install this specific dev build number 3. In just 2
easy-to-remember commands and a few seconds, we can therefore list and
install specific Flatpak builds.

This will be the root page for the developer documentation. Note that
there are other files in this directory (old `README` included) which
will need to be deleted but I don't do it just yet on purpose until I
checked them and integrate anything which could be of interest back into
the new documentation.

Let's make the devel-docs folder a bit less crowded.

There are still deprecations going around but for GExiv2 0.14.0 so we
can't change these yet.

Note also that I try a slightly different approach as I don't set a
GError for well-known tags as there is no reason these fail. I only add
a GError when we construct tags or similar calls.

Last deprecated usages in this file. Actually there are a few other
calls but deprecated on GExiv2 0.14.0, hence over our current
requirement. So we'll have to handle these later.

Replace functions gexiv2_metadata_set_xmp_tag_struct() and
gexiv2_metadata_get_tag_type() with their _try_ variants.

Note that I print to stderr rather than raising a warning here as I am
quite unsure where the list of XMP metadata we are gathering comes from.
Is it fully validated by GExiv2, and therefore no errors are ever
supposed to happen? (in such case, we should raise a warning if it does)
Or is it user-provided data (e.g. from a file loaded in GIMP which can
contain broken metadata)? In such a case, we should probably handle the
error slightly differently to warn for non-processable data (hence
possibly metadata loss at export time).

For the time being, then go with this weak handling and take care of
this better when we can look further into this.

… gexiv2_metadata_try_set_tag_string().

These are usage where we have full control over tag names and values so
no error is supposed to happen. This is why we use them as code warnings
and not returned error (because if an error did happen, this would be a
bug rather than a user error or a system error).

Here are the changes:
- Separate the check for comment contents and the one of whether or not
  it starts with "charset=Ascii ". Indeed in my tests, we still want to
  handle the empty string case or the "binary comment" case even without
  the charset prefix (currently it was both or none, so I encountered
  cases with a broken "binary comment" comment because the charset
  prefix was absent).
- Add some #warning in order not to forget to remove the bogus "binary
  comment" test. Indeed after some digging in Exiv2 code, I could
  confirm this return value got removed in commit 9b510858 of Exiv2
  repository, i.e. since Exiv2 0.27.4. Now in my test case where I had a
  tag containing only 0s, Exiv2 returns an empty string, which is
  perfectly fine (and it's up to us to keep or ignore it).
- Use gexiv2_metadata_try_get_tag_interpreted_string() instead of their
  deprecate non-try counterparses. Right now, I am just outputting any
  error message to stderr, as I'm not sure if this is the kind of errors
  we want to warn people about. I guess it would depend on which type of
  errors exactly are returned, so let's see if we encounter some case in
  the future. For now stderr is fine to detect these.

GimpColorRenderingIntent and BablIccIntent are actually 1-on-1
equivalent (for the common base values), but it's better anyway to call
with the right type. Also fixes this warning:

> libgimpcolor/gimpcolortransform.c:215:53: warning: implicit conversion
> from 'enum <anonymous>' to 'GimpColorRenderingIntent'
> [-Wenum-conversion]

- Align macro values.
- Align backslashes to escape newlines.
- Added explicit PointerAlignment though this one seems unneeded.
- Increase the column limit (even though 80 is really the official one)
  and add some penalty on breaking on very unexpected places, such as
  around assignments or on first parameters in calls/declaration. We
  want short lines but this is more of a soft rule which should not
  override sensible line breaking rules.
- Group some rules and reorder rule names alphabetically within groups.

It looks like origin is the same as mr-origin when the contributor
pushes to one's branch. But when a reviewer rebases through the Gitlab
"Rebase" button on web GUI, I got a fatal error:

> fatal: ambiguous argument 'origin/asalle/use-dynamics-flag': unknown
  revision or path not in the working tree.

Possibly `origin` is then the remote of the person who rebased (it would
be weird, yet it's a fact the branch is not found). Let's go with this
assumption.

Asa authored Jan 19, 2022 and Jehan committed Jan 19, 2022

Fixes #950

`.gitlab/search-common-ancestor.sh`'s original authors are
Philip Withnall and Frederic Martinsons.
(Jehan/reviewer's note: script further improved by Asalle)

- Add recommendations on whether to break MRs into 1 or more commits.
- Add style for one-line struct initialization.
- Protect some texts in backticks' markdown syntax.

This is the same issue as with IM000001.dcm mentioned in issue #313.

There are two problems: incorrect endian conversion for 16 bits per pixel,
and not handling photometric interpretation "MONOCHROME1", which means
minimum value is white instead of black.

The endian conversion was fixed as suggested in issue #313.
For "MONOCHROME1" we added a variable bw_inverted and we invert the pixel
value if that variable is true.

Exporting an image to TGA fails with a crash when it's an indexed image
with alpha channel. We were not taking into account that even though
the output is 1 byte per pixel, the input should allocate memory for
2 bytes per pixel (1 color index and 1 alpha channel).