As I recall, this is something we in fact used to have in gimp-2-10
branch and which we lost when switching from appstream-util to
appstreamcli validation tool (the later is now recommended, but it's
also less featureful, they don't even have a relax test!). So that was a
regression in the build system.
Note that it's not just not to have to put a date too early in our
AppStream metadata, but it's also that this way, we won't forget to
update it upon release (hence shipping with a wrong release data in
metadata). Indeed, when building a non-release version, date="TODO" will
pass the test, yet moving on to a point release version, the validation
test will now fail on a TODO date.
The other way around, we were going to have the quick'n dirty exit for
the whole 3.0 stable branch, which is obviously not what we want. We
want the clean exit for all developer builds, even within a stable
branch.
I had just forgotten to add it, though fortunately (or not) it doesn't
break string freeze because the <release> description fields are not
localized right now.
Cf. discussions in #8628 and this infrastructure report:
https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/473
The color for the nib handle is pulled from
the widget's background-color style.
However, this was not defined - so it was
always (0, 0, 0).
This patch adds a GimpBlobEditor CSS
class and defines the background and
border color for it to resolve the issue.
The lua.interp file is there. Lua plug-ins are not needed at build time,
except that when I had a non-supported interpreter as my system's `lua`
binary (see #11876), so calling in-build GIMP would startup the lua goat
exercise, get the error reported in #11876, and (this part is the real
problem), it would somehow freeze the in-build-gimp.sh script. I'm not
sure how exactly, the gimp-console would in fact end correctly (and
generate the image it is supposed to), but leaving around a lua process.
And somehow the script would not continue, it would not call any further
command line, nor would it even crash. So I just had a stuck build.
In my OS, lua 5.1 binary is called 'lua-5.1' (with hyphen), so I add
this in the list. Also I improve the summary output to display the found
lua binary, which is useful for debugging and for packagers to know
which lua binary is being used (especially now that we install a
lua.interp, even on Linux).
GimpExportOptions is incomplete.
It exists so the API is stable.
For now, ScriptFu eat and ignore actual args,
binding to NULL, in calls to PDB procedures
file-export-foo having formal args of this type.
Unlikely that in the future ScriptFu will do anything else:
if a plugin needs export options, use another language.
The few file exporters used by existing ScriptFu scripts
(file-gbr-export and file-pat-export)
don't honor export options.
luajit download server to tarballs stopped to work, which is expected,
since it was advised by the team in https://luajit.org/download.html:
"Please do not use obsolete versions from older tarballs or zip files.
Please remove any outdated links to these downloads — these links will
cease to work soon."
We also will not use the official git server since it does not support
all git clone features, which makes flatpak-builder cloning stage fail.
---
Regarding lua-lgi, we will not use the latest commit since seems that
our goat exercises or gobject-introspection or lua-lgi iteself is broken
since lua-lgi commit: 3f47eb57ef5a84be878ce33c15b7ff037059b08d
Currently, the default maximum size of GIH cell-width and cell-height
is 1000. These values are increased to the current image size when
exporting via a GUI. However, it is not updated when overwritten or
exported without a GUI. If the cell-width or height was previously set
to a larger value than 1000, this throws a critical and resets the value to
1. This likely causes the "slow" exporting noted in #10816, since the cell
becomes 1x1 even for large images.
This patch sets the default value to GIMP_MAX_IMAGE_SIZE, so that
if run non-interactively, we don't run into issues with the image dimensions
going beyond the bounds of the parameter maximum.
It was made impossible to paste into a channel, as this was creating a
normal layer instead. We need to use floating selections when the pasted
target is a GimpChannel type.
Note that the UX is very ugly right now for these (except for the layer
mask case as I improved this a lot with commits 04810ec95e and
28457ce337), so I opened issue Teams/GIMP/Design/gimp-ux/89 to design
further evolutions.
This is a follow-up of commit c5db158f58, where the flickering issue was
happening when creating new windows when already in multi-window mode. I
had the same issue again when I had several tabs opened in SWM and
switched to MWM. Then it would undraw displays to move them to their own
window. In the short time when this occurs, we don't want to process
events. So now I changed the "drawn" status when undrawing ("unrealize"
event) a shell.
I also changed the implementation of gimp_displays_accept_focus_events().
What we need is to check the active shell only of each window. In SWM in
particular, it is normal that non-visible tab shells get unrealized.
First, make the script versioning system able to detect release candidates.
Otherwise, we willn't be able to use the "GIMP.GIMPPreview" identity (that
was previously tied to GIMP_UNSTABLE var, which is not set to 1 on RCs).
---
This also fixes the pseudo-revision trick when we have a zeroed micro version,
which is the case of the release candidates and the first stable version.
The versioning now have a different aproach from 8c99efd7.
I had added an assert in commit 98ebe96c1f specifically to catch other
cases where we may have run gimp_ui_manager_update() with inconsistent
user context, and I failed to catch the obvious CRITICAL (the damn Error
Console was catching it!).
Anyway we had this other obvious case when creating new displays in
gui_display_create() which would trigger the ui update with still
inconsistent context.
Now I'm in fact wondering why GimpContext is simply not returning the
active GimpDisplay's image and connecting to the "image" property of set
display so that it's always synchronized. But since we are so close to
GIMP 3, and I don't want to do too important restructuration of code
(why did we do this complicated update in 2 parts? Maybe there was a
good reason…) at this point, I'll just do the simple skip for now and
look more closely at GimpContext implementation after the release.
The previous PDB generation was losing pre-formatting inside
triple-backticked blocks. In particular we were losing indentation
(which was already ugly in C, but even syntactically wrong when
displaying Python code samples). And it was also making us add
double-newlines between every code lines, which was annoying.
This updated code now leaves triple-backticked sections as-is.
Unfortunately I was completely unable to do this by modifying the
existing functions, which were modifying the input arg in-place. So I
made them into functions returning the result. But then there is another
part of code (niceargs()) where changing array contents doesn't work
properly, and worse it seems to corrupt the array somehow (because I
have generation breakage in completely-different pieces of the PDB
generation code). I believe there is some passing-by reference/value
concepts in perl which I don't quite get (they use `&`, `\` and other
symbols and even searching for these, I don't quite understand how to
use them the right way) but I've spent already too much time on this. So
since I've got something working now by having duplicate functions, I'll
let someone else from the future, who knows better perl, re-merge these
functions if they know how.
The 'help' field needs to be single-quoted so that @-values do not look
like perl variables, hence breaking GIR annotations.
Fixing:
> Possible unintended interpolation of @Gimp in string at /home/jehan/dev/src/gimp/pdb/groups/item.pdb line 64.
I double-checked the gi-docgen docs and realized the "Note:" were all on
the same line as previous text. I had forgotten it just removed one
newline. So if I want a new paragraph (double-newline in markdown), I
need 3 newlines in the pdb file.
All the functions working with object's IDs are mostly internal. They
are still made public because they can be useful and are relevant in
specific use cases (i.e. using IDs to reference items in specific
widgets, such as drop-down lists, or when temporarily storing an item as
integer, etc.).
Yet it should be made clear that these usages are the exception rather
than the norm.
I had this one case at GIMP exit where destroying editor->selection
inside gimp_colormap_editor_set_context() was segfaulting, very likely
because the widget was already destroyed so the pointer was dangling.
Therefore set a weak pointer, and clear it in dispose, so that whatever
comes first at destruction time will reset the pointer to NULL.
This fixes a never-ending flickering blocking the GUI, until a manual
focus event (such as moving a window in front) breaks the infinite loop
of handling focus events.
Jehan