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.
GimpConfigWriter contains several constructors with the convention
`gimp_config_writer_new_* ()`. This will lead to problems however with
languages like Vala, where it cannot disambiguate the following:
```
// calls config_writer_new_string()
Gimp.ConfigWriter w = new ConfigWriter.string("xxx");
// calls config_writer_string()
w.string("xxx")
```
Using `from_` in constructors is general practice in GObject-bsed
libraries because of this.
This also fixes an error when trying to use vapigen on the GIMP .GIR
file.
Right now, we get the following warnings when building the docs:
> gtk-doc.xsl: For acronym (nullable) no value found
This is because we're not adding the generated annotation glossary to
the docs sgml (presumably because we didn't need it as we didn't use
GObject-Introspection yet). This commit adds those lines and thus fixes
the warnings.
and make them build again without any wrong symbols.
This does not enable the devel-docs build yet, I'll fix
module by module before enabling the build again.
Add a "markers" page to the performance-log viewer, which lists
the event markers contained in the log, and allows navigating
between them.
Update docs accordingly.
In the perofmance-log viewer, add header-bar buttons to clear and
invert the selection, and allow inverting the selection by ctrl-
right-clicking on the sample-selection area.
Update the docs.
This commit completely removes the "Edit -> Fade..." feature,
because...
- The main reason is that "fade" requires us to keep two buffers,
instead of one, for each fadeable undo step, doubling (or worse,
since the extra buffer might have higher precision than the
drawable) the space consumed by these steps. This has notable
impact when editing large images. This overhead is incurred even
when not actually using "fade", and since it seems to be very
rarely used, this is too wasteful.
- "Fade" is broken in 2.10: when comitting a filter, we copy the
cached parts of the result into the apply buffer. However, the
result cache sits after the mode node, while the apply buffer
should contain the result of the filter *before* the mode node,
which can lead to wrong results in the general case.
- The same behavior can be trivially achieved "manually", by
duplicating the layer, editing the duplicate, and changing its
opacity/mode.
- If we really want this feature, now that most filters are GEGL
ops, it makes more sense to just add opacity/mode options to the
filter tool, instead of having this be a separate step.
The NULL terminator of the tile-offset array of dummy buffer-levels
is erroneously written as an int32, instead of an offset, even in
version-11+ XCFs, in which offsets are 64-bit.
Since the dummy levels aren't actually used by GIMP, we're going to
keep these fields as int32 as an exception, in order to remain
consistent with existing XCFs, and just add a comment in the code,
and update the docs. If we ever make use of the higher buffer
levels, we should change these fields to offsets, and bump the XCF
version.
GimpSpinButton is a drop-in replacement for (and a subclass of)
GtkSpinButton. Unlike GtkSpinButton, it avoids updating the
adjustment value when losing focus, unless the entry text has
changed. This prevents accidental loss of precision, when the
adjustment value can't be accurately displayed in the entry.
Add devel-docs/performance-logs/performance-logs.md, which
describes how to record and view performance logs, and how to
report perofrmance-related issues.
Nicknames on IRC/gitlab are hard, even more when they change depending
on the media! I realize we are regularly asking them or unsure of who to
contact (for instance here for releases). Let's associate each package
with its current maintainer to make it easy to contact the right person
to prepare our official packages before a release.
Add a gimp-register-file-handler-priority procedure, which can be
used to set the priority of a file-handler procedure. When more
than one file-handler procedure matches a file, the procedure with
the lowest priority is used; if more than one procedure has the
lowest priority, it is unspecified which one of them is used. The
default priority of file-handler procedures is 0.
Add the necessary plumbing (plus some fixes) to the plug-in manager
to handle file-handler priorities. In particular, use two
different lists for each type of file-handler procedures: one meant
for searching, and is sorted according to priority, and one meant
for display, and is sorted alphabetically.
Pass the current icon theme directory to plug-ins through the
config message, and add a gimp_icon_theme_dir() libgimp function
for retrieving it. Note that we already have a similar
gimp_icon_get_theme_dir() PDB function, which we keep around, since
it can be used to dynamically query for the current icon dir,
unlike the former, and since it returns a dynamically-allocated
string, while the rest of the config-related functions return
statically allocated strings.
Use the new function, instead of gimp_get_icon_theme_dir(), in
gimp_ui_init(). This allows gimp_ui_init() to run without making
any PDB calls. Consequently, this allows us to start plug-ins that
call gimp_ui_init() without entering the main loop in the main app.
We're going to add a plug-in that displays an interactive dialog
while the main app is blocking waiting for an operation to
complete, and we need to be able to start the plug-in without
entering the main loop, to avoid the possibility of arbitrary code
being executed during the wait.
Bump the protocol version.
GimpBusyBox is used to show a message indicating an operation is in
progress. It's basically just a spinner and a label, with some
styling.
We're going to use it both in app/ and in a plug-in.
Explaining in the intro that the reference is the code, and where to
find it.
Rather than writing uint32/64 for every offset, use "pointer" as a
proper and well defined basic data type, whose detailed description is
in the "BASIC CONCEPTS" section at the start of the file.
... for layer modes.
KDE developers asked me where the code was so that they could reproduce
actual algorithms in their XCF reader. This is obviously interesting
information to have around in our docs.
Jehan