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.
While Debian testing is the sensible choice for dependency requirements while we
are in full-dev mode, now we are getting closer to 3.0 release, and Debian 12
"bookworm" barely got out.
If we continue to develop at current pace, GIMP 3.0 should be released before
the next stable Debian, so we should not use dependencies unavailable on the
latest stable (otherwise GIMP 3.0 won't be distributable soon enough on Debian,
nor on Debian derivatives such as Ubuntu, Mint, etc.).
This is why we are now basing GIMP dependency requirement on Debian bookworm.
We'll likely get back to the next "testing" after GIMP 3.0 release.
It is apparently how dependency names are supposed to be spelled to be taken
into account. The previous commits fixed some, but missed 2. I'm not sure they
will actually end up in the right-side list of the docs (it looks like when a
dependency is not actually found in the API, it isn't listed there), though it's
at least always listed in the left side, as I can see it.
And while I would prefer the upstream "display" name (i.e. GEGL and babl instead
of Gegl and Babl), better be consistent in how we list these dependencies in the
libgimp and libgimpui docs.
See discussion in !811.
So procedures can declare args and GimpProcedureDialog show chooser
widgets
Fix so is no error dialog on id_is_valid for resources
Palette.pdb changes and testing
Memory mgt changes
Gradient pdb
Font and Pattern tests
Test brush, palette
Cleanup, remove generator
Rebase, edit docs, install test-dialog.py
Whitespace, and fix failed distcheck
Fix some clang-format, fix fail distcheck
Fix distcheck
Cleanup from review Jehan
The URI will be: https://developer.gimp.org/core/maintainer/release/ (once we
merge the testing website to the main)
The new procedure also contains a wrapper step where we paste the checklist,
markdown-formatted, into a Gitlab report for better progress follow-up and also
onboarding testers into the release procedure.
- The <_p> or <_li> syntax for localizing AppData is the old code logics from
intltool.
- Mailing lists don't exist anymore. Move all usage on discourse.
- Microsoft Store is only for stable builds.
- Let's always merge `origin/testing` into `master` on gimp-web module (no
cherry-picking) as it's clearly the procedure we've been doing for quite some
time now.
Instead of storing vectors as properties, they have their own structure, which
make them able to store and load all the usual and common properties of other
items. In other words, it makes XCF now able to store locks, color tags and
several selected paths.
This file was just moved as content/core/specifications/locks.md in the
pat/bootstrap branch of the gimp-web-devel repository.
This branch will soon be merged and become our new website. Removing the
now duplicate in our source repo.
- Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated
HTML, and not an absolute path taken from build dir (otherwise this
would break, for installed docs, but also for the tarball and the
developer website!).
- Also use either gimp-logo.png or gimp-devel-logo.png depending on
whether we are on a stable or unstable branch.
- Install these in images/ inside the GIMP docs folder, which
corresponds to the relative path given to GIMP_LOGO_PATH.
- The installed root dir will be $datadir/doc/gimp-2.99/, e.g.
/usr/share/doc/gimp-2.99/
- Inside this folder, the library references will be in libgimp-3.0/ and
libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that
the root dir uses the application version (2.99) whereas the library
folder use the API versions. These are different in development phase.
- Archive the gi-docgen installed files, not taken from the build dir,
to avoid packaging temp files, such as the .toml files. Note that
`g-ir-docs` files are still taken from the build dir, as we don't
install them yet.
- Finally package all this in a directory before archiving in a tar.xz,
named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside
gimp-api-docs-2.99.13.tar.xz).
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
Bruno