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.
Jehan