If you were to select a layer group and some/all its children, current
implementation was "flattening" all these at the same level, which is
weird.
Now the whole questioning of what to do in this situation is a very good
UX discussion to have, in particular when you only select *some* (not
all) of the children. Does it mean something? Does it mean you want to
copy part of the tree structure with only part of the children? What
when it's not a copy, but a move (e.g. a dnd in the same image). You
can't move part of the children (what do you do with the rest?).
Anyway that's many questions which I prefer to leave for a real gimp-ux
discussion and specification. For the time being, at least not
flattening a whole tree structure seems a better behavior.
When selecting by color with the Fuzzy Selection, Color Selection,
or Bucket Fill tool, we use gimp_pickable_get_buffer (). This only looks
at the raw pixels and not any active filters, which can result in some
unexpected selections (for example, an NDE offset filter will make it
appear as if you are selecting the wrong area).
There are plans to let users decide whether to select the raw
pixels or the filtered layer. For now, this sets the default action to
consider the layer as seen by the user, with filters included in the
calculation.
In 06bd1f1289 the max number of
dimensions was set to 1000, but the plug-in runs into a
segfault when dimension >4. The rest of the plug-in uses
GIMP_PIXPIPE_MAXDIM as max (4), so use it for the dimension argument
as well.
In particular, we want the new Script-Fu plug-in to be able to handle
their progress status themselves, which is possible with
(gimp-progress-set-text) except that it is far too quickly overriden
because each procedure call generates a new progress message.
I hesitated to make (gimp-pdb-proc-exists) public but I don't think it's
a good idea as it would be redundant with gimp_pdb_procedure_exists() in
the C API.
Instead, just implement (gimp-pdb-procedure-exists) specifically for
Script-Fu, with a name mapped to the C function.
Adding an is_internal value was a mistake, or rather it was redundant.
We already had a procedure type and all internal procedure are set as
GIMP_PDB_PROC_TYPE_INTERNAL.
I also double-checked that it is not possible for a plug-in to create a
procedure with this type (it is rejected), so it's very fine.
… 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.
