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
intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
We regularly have package issues which are discovered soon after
release. Let's try a new step in the release process where we would
build packages in advance just for testing.
See issue #1307.
There doesn't seem to be anything blocking us to publish to the
Microsoft Store, now that there is this new "traditional desktop
application" process allowing us to publish using our existing
installer. So GIMP 2.10.32 should normally be our first published
version there.
The urlmap file allows gi-docgen to generate links for namespaces that
are also generated by gi-docgen. For example, with this commit, a
reference to `GObject` will now be properly linked to the GObject
documentation.
This will work around such errors from the g-ir-doc build:
> devel-docs/g-ir-docs/pages/python/Gimp-3.0/Gimp.checks_get_colors.page:46: parser error : EntityRef: expecting ';'
> gimp_checks_get_colors (gimp_check_type (), &color1, &color2);
> ^
Similar to commit 7123b6c466, it cannot really be considered a proper
fix, barely a workaround for g-ir-doc-tool not even able to produce
valid XML. Here we have ampersands which it should have espaced into XML
entities.
Anyway this will do for now (until we just decide to drop the g-ir-docs
tools?).
In the original gimp-2-10 branch where this feature was originally
worked on, we had to keep gimp_checks_get_shades(). But on `master`
where we will reset and break API, let's get rid of this function which
should not be used anymore.
Why: MR !389 changed the signature of PDB procedures to return GStrv instead of (int, GimpStringArray)
This changes handling of results from a call to such a changed signature, in a Scheme script.
The symptom was a cryptic TinyScheme "Error: car: argument 1 must be : pair"
Most changed procedures are named like "-list".
I did a cursory grep to look for other instances.
Updated porting guide doc.
To work around the issue, I just wrote a stupid sed script. Of course,
it means that if we encounter again the issue on some other docs, we'll
have to update it. In other words, it's neither robust nor a proper
long-term fix. Just a temporary hack.
See: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/425
Also fixing this issue, I encountered another bug, this time in meson,
which changes backslashes in slashes on 'command' arguments, in a
completely uninvited manner! The only workaround to this is apparently
to call an external script, which is ridiculous for such a basic stuff.
But well… here is why I implement this with a script, instead of
directly calling sed in the meson 'command'.
See: https://github.com/mesonbuild/meson/issues/1564
As I review and tweak various aspects of GIMP UI, I also write down
specifications for these subparts. Here is one for the locks behaviors.
We worked on these specifications with Aryeom and tried to make the most
useful and also somehow obvious logics for these locks, in particular
the cases when applied to layer groups which can have wider ranges of
meaning (on leaf items, it is much simpler). The various previous
commits are implemented based on these specifications.
XCF 17 includes the new visibility locks and the ability to add position
and alpha locks on layer groups.
I am going to push the various commits implementing these different
features together which is why we gather them as a single XCF version.
Also adding the CODING_STYLE.md. There is actually the question whether
we still want to track this docs files to package them in the tarballs.
It made sense 20 years ago when devs were working from tarballs, but
nowadays, devs are expected to work from git HEAD.
Anyway this fixes the CI.
- ps-menurc removed in GIMP 2.7.2 (i.e. stable 2.8.0) according to
NEWS.pre-2-8.
- in our main README, redirect now to devel-docs/README.md as entry
point for contributors.
- move HACKING to devel-docs/ and specialize it into a "how to build
from git and contributed" docs:
* Make it markdown.
* Remove some now obsolete or redundant recommendations (to be fair,
we can probably clean up the file a bit more, but we'll see).
* Add/improve relevant information.
* Make more obvious when you want to build from tarball or git.
* Just keep a single short paragraph about the coding style to
redirect people to the appropriate CODING_STYLE.md file.
* Don't recommend sending patches to the mailing list anymore.
- move CODING_STYLE.md to devel-docs/.
Makes more sense and I am trying to make the devel-docs more readable
(which includes less crowded, especially with scripts which are not
really docs).
I was wondering what this version file was for. After some git
archeology, turns out this was used for gtk-docs. Since we replaced
gtk-docs with gi-docgen in commit 92e80d12e8, this can be removed as
well.
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.
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).
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).
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.
Also called "feature" option in meson, so that by default it depends on
auto-detection of the gi-docgen hence won't break the configuration when
the tool is missing (the feature is simply disabled).
Also move the program check into the root meson file, which is anyway
much better to have a better visibility of features, otherwise we'd end
up just having tests everywhere in any possible random directory of the
repo.
Finally add a line in the summary of the configuration step, displaying
the docs generation being enabled or disabled.
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
We now save and load layer and channel item sets. Only missing set types
are path ones, but the whole path item is just its own exception in the
XCF format, and adding support for it, while keeping compatibility with
older XCF seem like a small headache. I could do it, but I actually
wonder if it is worth it. Would people really need to store sets of
paths?
Also this commit finally gets rid of any remnant of the old item "link"
concept (I think), so we are getting close to merging the branch.
I cleaned many remaining places where the concept of linked item still
survived.
On loading an XCF file with linked items, we are now going to create a
named sets for the linked items, allowing people to easily select these
back if the relation was still needed.
We don't remove gimp_item_get_linked() yet and in particular, we don't
save stored items into XCF files. This will come in an upcoming change.
When running tests, the data are not meant to be necessarily installed.
Therefore icons won't be found when calling gimp_widgets_init().
Add some special-casing to find them relatively to the install
directory.
Over the last few years, we seem to have been in agreement that .ui
files are not so desirable anymore.
For plug-ins, they are completely deprecated in favor of our much nicer
dialog generation API from properties (the metadata plug-in(s) are the
only ones which still have .ui files but we plan to get rid of these
eventually).
For core code even, we also prefer to generate GUI when we can (as we do
for GEGL ops, for symmetries and other places).
GtkBuilder files actually make for more complicated code, imbricated in
both the C code and .ui files, more bug-prone too and we don't seem to
gain anything from the additional complexity.
So let's get rid of this dev guide.
- The trick to fetch automatically all MRs in read-only branches.
- How to temporarily checkout and push to a contributor's remote without
actually hard-naming their remote repo and polluting your local repo
with every new MR.
Saving a thumbnail is closely related to the other metadata preferences,
but so far this was the only one that didn't have a preference for a
default user value.
This commit adds a preference in the metadata section where a user can
select whether thumbnail saving is enabled by default or not.
Commit 59f2ba44c7 changed the devel docs to tell that on Linux, just
running the gdb command `continue` is enough to restart the plug-in
process. Maybe it is true on some specific setups, so I leave this part
of the note, but for sure it never worked for me. I may run `continue`
as many times as I want, the process stays stopped until I explicitly
send a SIGCONT signal (our code raises itself a SIGSTOP which requires a
SIGCONT for continuation of the process).
Maybe in some configurations, gdb actually sends a SIGCONT when
`continue` is run but not in others? No idea.
Anyway I add back the part about sending a SIGCONT too, then people can
test and choose which procedure works for them.
How to create the packages through MR labels and where to find the
resulting test packages…
Note that it would be nice if we had automatic messages on the MR
writing down the procedure (with generated links for the specific
pipeline ID) once a pipeline succeeds.
It would simplify the whole process even further. We can see some other
day how such a thing could be automated.
In particular add the need to wait a bit for installers before actually
publishing news. Also add a few usage examples for the gimp-web helper
tools for binary file publishing (torrent creation and mirror checking).
Update in particular the tarball creation steps. We now use tarballs
generated by the CI. I still leave information for doing it locally in
this howto, but mostly so that we can easily find this info for testing
or fixing dist bugs when needed. Other than this, if the CI works
flawlessly, a successful pipeline ends up with a proper tarball.
The main advantages of this approach are:
- Transparency: the full distribution process is now fully accessible on
Gitlab, from the source, through the build (including all the logs)
and up to the final tarball. Even the checksums are generated by the
CI, making it easy to recognize if different tarballs were published
on the download website or mirrors. This makes for a much safer and
trustworthy publication process.
- Less bus factor: we don't rely as much on a single person to take care
of the whole process.
- More automatization: a release still has to be prepared and verified
manually (it always will), but at least the whole tarball creation is
now automated. The next step will be to automate also the publication
on the download server.
… and s/gimp_parasite_flags/gimp_parasite_get_flags/
It is better to have a consistent API and the fact is that most
getter/setter functions use the _get|set_ naming, but these didn't.
I wondered if this was such a great idea to rename these anyway because
even though we are breaking API in GIMP 3, is it the best idea to rename
when no functional change happened? After discussing with Wormnest, we
still agreed it was still better to go for consistency rather than
regret later (and be stuck with these names for many more years).
Also this fixes these warnings:
> [649/1205] Generating gimp-3.0.vapi with a custom command
> Gimp-3.0.gir:24162.7-24162.56: warning: Field `Gimp.Parasite.flags' conflicts with method of the same name
> Gimp-3.0.gir:24318.7-24318.52: warning: Field `Gimp.Parasite.name' conflicts with method of the same name
For debugging the flatpak, we often ask people to install the SDK and
debug data. Yet there might be several branches of the GNOME SDK
installed at once, hence flatpak will ask which version to install.
This quick command can be copy-pasted as it's a way to detect which
runtime is being used by your flatpak-ed GIMP.
It isn't being used by any plug-in or any code in GIMP at all even.
Let's get rid of it while we can still break API, so we can cut down on
all the complexity of the gimp-param stuff a bit.
Allow guides with off-canvas position since we can now view and work
outside the canvas.
The guide deletion interaction does not change too much, except you
don't delete a guide because it's dropped off-canvas but off the display
viewport area instead.
The XCF format is technically unchanged as PROP_GUIDES was already
expecting an int32 coordinate (with max value at GIMP_MAX_IMAGE_SIZE,
way below uint32 max anyway). Yet our code and XCF docs was explicitly
asking to ignore negative coordinate guides, which makes a change in
behavior for the XCF parser, hence a new version XCF 15. Loading will
still ignore negative position guides (even also bigger than image
dimension guides now) for XCF 14 and below, but will now accept any
position for XCF 15 and above.
Similar to the --enable-g-ir-doc option I just added on autotools. Also
separate this option from gtk-doc as it is unrelated (not everything
under devel-docs is related to gtk-doc!).
Based on the proposed process proposed by Akkana Peck. Thanks Akk!
For now, it's only in the meson build, which is fairly terrible to use
as soon as we do custom build rules. Here are the list of issues:
- meson does not allow building in subdir (issue 2320 on meson tracker).
Sure I could make several subdirs with meson in them. But here the
future goal would be to be able to generate docs for other
introspected languages, and maybe also other output formats (epub or
whatnot). For this, since these are basically the same commands which
are used, the best practice would be to have loops generating one
target per language/format combination, reusing code rather than ugly
copy-pasting in subdirectories' meson files).
- custom_target() requires the output parameter to be the complete list
of generated files. But we have more than a thousand of them. It's not
practical. Maybe we could try to find a way to generate the list from
the contents of the .def files which are already exhaustive and exact.
- Install also requires the output list to be complete.
- I temporarily have these docs not generated by default (because the
gtk-doc option is already crazy slow as it is, making meson near
unusable for development if it's enabled). If you want to generate the
docs, the commands are as following (yeah I don't understand what the
target names are for since meson does not actually create targets with
these names, so we have to use fake output names instead):
> ninja devel-docs/g-ir-docs/Gimp-python-html
> ninja devel-docs/g-ir-docs/GimpUi-python-html
