See: Infrastructure/gimp-web-devel#9
gitlab-mr.md was removed without replacement since the
package generation info is now on the MR template for
everyone's benefit (6245e4ee) and the test of the
text was mainly personal annotations.
See: Infrastructure/gimp-web-devel#9
Except API-for-resources.md, which is ugly and
not linked in the README. And GIMP3-API-Changes,
which seems to be just a personal annotation.
DWMWA_USE_IMMERSIVE_DARK_MODE and activeCodePage were introduced on "1903"
The Store version manifest was already using this as minimum version since
day 1, so the commit just extends that minimum version to the Installer.
While is unlikely that users will be affected, we can revert this commit if:
1) LTSC/LTSB users report on tracker that is not possible to install GIMP;
2) we confirm that GIMP works on this machine even with that incompatible API.
This is already documented and updated on gitlab-ci.yml's
"There are five "TYPES" of pipelines on our CI" section so
maintaining two explanations is pointless and not future-proof.
Per the (quite off-topic) discussion in #12772, the fact it's quite
broken on Windows, apparently not too maintained anymore and its syntax
clashes with gi-docgen syntax…
Every artifact from our CI have a pretty name with some reason for it:
- Installer: it is this way on download.gimp.org since ever(?) and that's fine
- Store: follows Microsoft de facto spec of .msix files naming
- AppImage: follows AppImage draft spec of .appimage files naming
But the .flatpak just looks like AUR pkg. So, let's use reverse DNS
naming which is used at least for .flatpakref files. This makes more sense.
Leaves the mechanism in place, but erases all rows of the alias map data.
Update devel-doc to say ScriptFu has its own mechanism for aliasing.
For major release 3.0
As suggested by reviewers, use a better word.
Regular denotes size.
Procedure is the same word used in the classes in the code.
Procedure denotes a general procedure, without specialization.
Renames only where visible externally by script authors.
Internally, some functions are still named "_regular".
That can be changed later as a style issue.
Ported from ca5688bf6d
Just to note, we are already not using Assembly code
in 10bit and 12bit libraries. So, no feature dropped.
---
Also, little fixes to some dev docs regarding Clang.
...to path.
Changes the names of
gimp_vectors_* () API to
gimp_path[s]_* (). Renames related files
to [path] instead of [vectors], along with
relevant enums and functions.
...to paths
The first step in converting GimpVectors
to GimpPath. The PDB API for any
gimp_image_*_vectors () is now
gimp_image_*_paths ().
This commit only covers libgimp, and
the app/core versions will be renamed in
a following commit.
- Drops HACKING file (it is outdated and we have the "same thing",
updated, in the devel site), but moved PDB content to the README
* Update various links now to the devel site
+ Added 'TODOs' to avoid confusion from titles with empty content
and removed some that are already implemented
The Inno installer scripts contents (only 3 files: files, gimp3264 and
32on64) and filenames have been organized, making them much easier to
read, and slightly less hardcoded so less prone to being misunderstood
and pervasively receiving packaging stuff.
Just to be clear, one more time: the Inno installer (or future MSIX)
scripts never should be the center of attention. This "installcentrism"
caused a domino effect of partially "abandoning" the packaging, build.sh
and the meson scripts, which explains the existence of this MR...
(Some things still hardcoded since wildcards in Inno are very limited.
Also, the rational ordering principles of this MR were not applied since
these scripts are heavily based on the x86 .zip package and changing the
order of things here, according to my tests, breaks things quite easily)
… function gimp_font_get_pango_font_description().
Also updating file-pdf-save which is the only plug-in using these right now.
Note that I am not fully happy with the new function
gimp_font_get_pango_font_description() because I experienced some weird behavior
in file-pdf-save which is that some fonts were wrong if this is called after
pango_cairo_font_map_set_resolution().
But let's say this is a first step looking for improvements.
Generating the devel docs fails on Windows because it can't find
Babl-0.1.gir, which is only available for me in GIMP's prefix.
Adding that path with -add-include-path fixes the issue for me.
After discussions on IRC with ender/Jernej and frogonia:
* exchndl.dll (drmingw) requires dbgcore.dll and dbghelp.dll which seem to ship
with win10+, but not win7 (we don't know for Win8). So for Win7, Jernej had to
manually add it back (otherwise, building then running on Win10, it looks
fine, but GIMP fails to start on Win7).
* MSYS2 dropped Win7 support anyway and supports now Win 8.1+.
See: https://www.msys2.org/docs/windows_support/
So even though it looks like GIMP works fine on Win7 (after special-casing the
2 DLLs above by adding them manually in the installed files), there might be
unforeseen issues in the long run.
* Win7 official support by Microsoft now ended. And Win8 support is soon to be
(it actually already has, "except for Server 2012 [based on Win8], which's
supported for another 2 months"). Win8 never had much adoption anyway.
* frogonia confirms they didn't see many Win 7 reports, if at all, in the last
year.
So based on all these, and in order not to make our life over-complicated, we
drop Win 7/8 support for the next 2.99 versions and for the upcoming stable 3.0
series.
Though we keep support to these versions in the 2.10 series, in order not to
disrupt current usage too much.
