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
Let's start up some porting guide for plug-in developers. One of the
first things to do is to get rid of any deprecated functions from 2.10
or older versions. In the current stable, these would "just" output
warnings, but in the dev version, all deprecated functions got removed
and the build would fail.
This list may not be complete. I mostly created it by some grep on
deprecated functions from libgimp 2.10.
Plug-ins that work from different bindings probably want to use their
own list-type to specify arguments, rather than working with a more
cumbersome `GimpValueArray`.
This new API should make it less verbose. For example:
```
args = Gimp.ValueArray.new(5)
args.insert(0, GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE))
args.insert(1, GObject.Value(Gimp.Image, image))
args.insert(2, GObject.Value(Gimp.Drawable, mask))
args.insert(3, GObject.Value(GObject.TYPE_INT, int(time.time())))
args.insert(4, GObject.Value(GObject.TYPE_DOUBLE, turbulence))
Gimp.get_pdb().run_procedure('plug-in-plasma', args)
```
becomes
```
Gimp.get_pdb().run_procedure('plug-in-plasma', [
GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE),
GObject.Value(Gimp.Image, image),
GObject.Value(Gimp.Drawable, mask),
GObject.Value(GObject.TYPE_INT, int(time.time())),
GObject.Value(GObject.TYPE_DOUBLE, turbulence),
])
```
The `info line` in particular was given by Ell and will make trace
handling a lot easier as it means we may not have to ask for traces with
debug symbols or gdb with Flatpak. We can indeed get these infos back
ourselves since we are guaranted to use the exact same binaries.
This together with the change in verbose version output I did 2 weeks
ago (commit bc5f6371e9), allowing us to check the exact Flatpak hash
commit used by a reporter, Flatpak debugging should be a lot easier with
just the simpler stack trace format.
Flatpak repositories can store successive builds (up to 20 in the
Flathub repository in particular), even though by default it installs
only the last build.
I added in `debugging-tips.txt` the commands to search for and
explicitly install an older build of our official GIMP build. This can
be useful to compare some behaviorial changes as reported by users,
without having to re-compile old commits just for a quick test.
`gimp_unit_store_get_value()` clashes with the `get_value()` method of
its parent class GtkTreeStore. This means trouble for bindings, as seen
here in some pseudocode:
```vala
var unit_store = new Gimp.UnitStore();
// Which function are we referencing here, the one from GtkTreeStore or
// the one from GimpUnitStore? Worse, they both have different arguments
unit_store.get_value( ... )
```
The GIR parser is giving warnings because both e.g. a signal, a
corresponding vfunc and a method emitting it are named
"channel_changed", which can and will give issues in some bindings.
The easiest option is to follow the general convention of starting the
signal emitters with `emit_`, which also makes clear the intention of
the method.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
Found via `codespell -q 3 -S ./ChangeLog*,*.po -L als,ang,ba,chello,daa,doubleclick,foto,hist,iff,inport,klass,mut,nd,ower,paeth,params,pard,pevent,sinc,thru,tim,uint`
Though the description of the POINTER type clearly tells of the new type
size, it was still refered as 32-bit only in this introductory text.
Let's fix this.
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.
It's just too weird to be public. Remove its properties from the wire
protocol and from pluginrc. Instead, have all GParamSpecs' flags on
the wire and in pluginrc, so we can use stuff like
GIMP_PARAM_NO_VALIDATE.
Port the remaining few places to GIMP_PROC_ARG_STRING().
I'm sure something is broken now wrt UTF-8 validation,
will add tighter checks in the next commit.
Jehan