… gimp_procedure_is_internal().
I realized we were already naming these "internal procedures" in the
Procedure Browser and this is in fact a better naming than "core
procedure".
When closing the last image, it seems that we'd remove twice the
"windows-display-0001" item, first when making the action invisible,
then when gimp_ui_manager_remove_ui() is called on emptying the display.
And gtk_menu_tracker_remove_items() doesn't handle correctly a NULL
list.
Some people reported cases where gdb doesn't even seem to understand
Python scripts (the error in #12904 implies it is looking for standard
gdb commands, because apparently -x option allows both styles).
Others had issues in sandbox building (#12956).
I don't really want to spend too much time understanding each case,
especially as it's a self-debugging tool, not absolutely necessary for a
successful compilation.
So let's just make this optional, and default to "false".
The original code from 9eec33ba was wrong because it was not downloading at
CI_PROJECT_DIR. Now, it does, and only downloads on parent dir if locally.
Also, fix .NET Runtime download URL.
Similar to 333499265d,
since we need 'AppxManifest.xml' and 'data_associations.list'.
Also, fix build_dir code when script is called from 'installer' or
'store' dir.
Now, we don't need to set a lot of params when calling 'issc' anymore.
The version vars will be taken from Meson, being more future-proof.
This is not 100% future-proof, however, because we unfortunately can not
take 'config.h' vars directly due to Meson limitations:
https://github.com/mesonbuild/meson/issues/14260
This a bandaid for an issue on MacOS:
an IO event is received that says a read pipe from a plugin has data,
but the pipe is actually empty and reads hang, and hang the app.
Possibly this is an issue with GLib and could be fixed there,
to not send such a spurious IO event.
Possibly an alternative fix is to determine whether the app side of the
plugin protocol is in a state where no messages from the plugin
are expected. In that case, the read pipe should be flushed
i.e. data discarded, with non-blocking reads, until a read returns nothing.
Resolves#12973
Since the standard 'drawables' argument for procedures
is now a GimpCoreObjectArray, the suggested syntax for
setting it in a Python call was incorrect. This impacts other
parameters as well, so we add a check for the argument type
being Gimp.ParamCoreObjectArray and then provide the
correct Python code to set them.
This is an alternative implementation for issue #12825, replacing commit
424ef17bac, after further discussion with Jacob.
Basically we don't need a new key "gimp:help-id" anymore. Instead, for
every action we add through a "gimp:menu-path" key AND when its name is
prefixed with "gegl:", we generate a help ID from the operation name.
The first few operations in such case already have a help page for them,
with corresponding help ID, in gimp-help repository.
In the future, we may expand this help ID generation rule to any
core operation (i.e. any operation prefixed with "gegl:") but for the
time being, we only do for the ones with a menu path, otherwise we'd
have too many missing pages.
Also fix again gimp_gegl_procedure_get_help_id() so that it searches a
help ID within all existing operations in the "filters" group, as I
realized that this was still broken in some cases.
I pondered a lot about this one. In particular I wished we saw the leaks
earlier so that this change were in a RC (really unsure we'll have any
more RCs now).
On the one hand, I could tweak signal callbacks so that the callback
gui_exit_after_callback() is called before the fast exit(). But it feels
more and more like a hack over a hack.
Having 2 code paths depending on whether we are in a release or not is
ugly and would only hide bugs during the whole development cycle (as
proven here). Now when I read the comment, the part about speeding up
the quit process doesn't seem like it makes much sense these days (maybe
back then when this was implemented?). GIMP is fast to quit with or
without this.
Now the part where I worry is the problem of plug-in possibly still
running. Does it mean there used to be cases where GIMP would be stuck
at exit because of buggy plug-ins? I don't think I ever saw one of these
during the whole unstable cycle, and pretty sure we have code able to
kill plug-ins when needed. Even if not, by now, my preference would be
that, if ever someone were to report a similar case, we should just
improve our exiting code to kill (SIGKILL, without any chance of
avoiding it) any guitly plug-in.
This is why I finally decided to just get rid of this very old code.
For reference, the last time it was added was commit cdc2f0ded6 in
2004, though we can actually find older commits where it was removed
(921f00c13d), added (1db2ada311)… Looks like it used to be quite a
dance, but this is hopefully not needed anymore.
I had a case where the GIO API ended just stuck and never returning.
This API is made to work in a thread so that you can cancel loading URIs
from the main thread. Let's make use of that.
Seems that Debian Testing 'apt' defaults to 'dialog' mode by default, which
produces warnings since the Docker image don't come with 'noninteractive' set.
These warnings are inoffensive but they pollute the job output. Indeed,
they were making some GIMPers a bit worried on IRC.
---
Also, added a comment about why we always use Debian Testing for crossbuilds.
Let's call 'C:\msys64' $MSYS_ROOT as vcpkg guys do (since
it is not a prefix, the real MSYS prefix is $MSYS_ROOT/usr)
and call the various shells by MSYSTEM_PREFIX.
When converting a CMYK JPEG 2000 image to RGB, we freed
the Key array. Since it is still in use, this caused the
plug-in to crash. This patch replaces this with lowering
the component content and letting the OpenJPEG clean up
process handle this work instead.
Some ABR brush files have 16 bit grayscale masks, which fail to load.
This patch adds support for uncompressed versions of these brushes,
based on a provided sample file.
First of all, let's init with the main procedure label (stripped of
leading/traling spaces, of mnemonic underscore and of ellipsis) as
progress status for gimp_progress_init().
Then reuse this main label for all subsequent progress updates by the
same top procedure.
Finally "pulse" the progress at each update to make it more like
progression actually happens.
This is a first experiment to see if not having progress API in
Script-Fu is fine (#12948), by having better progression defaults.
Note that I don't touch the GimpFileProcedure and children because they
are special-cased anyway. As for GimpBatchProcedure, ALWAYS is a good
default too.
This was removed by commit 38b18de709 because this operation doesn't
exist anymore and was replaced years ago. Even though it was not wrong,
let's be over-cautious rather than not enough. What if someone had still
a binary of this old operation lying around?
This doesn't cost much to keep it in the list, so let's just do it (with
a comment to still document it doesn't even exist anymore).
