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.
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.
As Cheesequake noted in !1673, there may be cases where one would want
to run gimp_help_connect() while also setting a tooltip. So they also
run gimp_help_set_help_data(), even though the latter is implied by the
former. Worse, it makes the order matter too much because if you call
gimp_help_connect() after gimp_help_set_help_data(), the tooltip would
be removed.
Now the reason is that gimp_help_connect() was clearly made to be run on
windows whereas gimp_help_set_help_data() was for other widgets, which
usually don't need to react to F1. Yet the previous commit does add
F1-connect for the lock buttons, which kind of makes sense. So why not
just add this tooltip argument.
As a side fix, I am removing a bunch of gimp_help_connect() on each
button in the layers effect popover. Just run it once on the top
container.
This patch adds gimp_help_connect () calls before
gImp_set_help_data () to set up F1 keybind to work
properly. It also adds lock_visibility_help_id to channel
view.
Resolves#11718
Copying filters over from one image to a partial copy was broken on
multiple level by doing it on an additional loop, and assuming that the
originally selected layers and the newly created ones had the same
structure:
1. First the actually copied layers may be more numerous. For instance,
we'd also copy parent layers. Typically copying a layer under a layer
group, both the layer and its parent layer group would be in the clip
image.
2. Second, because this structure may change, the assumptions made so
that filters were not copied to the right image.
3. And as a last consequence, sometimes we could have crashes, assuming
the same structure and therefore directly dereferencing a NULL
pointer. I had such a crash when copy-pasting a layer group, while
also selecting its children layers (though this crash also got hidden
by my previous commit, but just by chance).
Instead just copy filters in the same time as layers are copied, so that
we can easily associate the filter from the correct original layer we
copied from.
app/text/gimptextlayout.c gives warnings
on MSYS2 about xres and yres not being
initialized.
plug-ins/file-tiff/file-tiff-load.c gives
warnings about read_unit not being
initialized.
plug-ins/file-bmp/bmp.c has a typo on
the label of the rgbx-8888 option for
rgb-format.
Main dev branch of GIMP always depends on the HEAD of babl and GEGL
anyway, but that's just so that we maybe have less people reporting GIMP
not building because they use a stable release version of GEGL (though
it won't take care of the case of people using an older 0.4.49 build
which also won't have the newer API).
In GTK2 and GIMP 2.10, you can use the mouse scroller to
switch between dockable tabs if you hover over the bar.
This behavior was removed from GtkNotebook in GTK3.
This patch follows other GTK3 applications in re-implementing
the behavior with a scroll-event callback.
I broke MR !1660 commits into 2 commits so that the strings are added
now (freeing this up for the upcoming string freeze), with this commit.
A next commit will be needed when we'll have the proper version update
infrastructure on GEGL side, because right now, all we can do when
filter versions don't match is ignoring the filter.
- Fix annotations for gimp_export_options_get_image() to make it
actually introspectable with the GimpImage being both input and
output. Even though the logic doesn't change much (the input image may
be overriden or not), it doesn't matter for introspection because
images are handled centrally by libgimp and therefore must not be
freed. Actually deleting the image from the central list of images
though remains a manual action depending on code logic, not some
automatic action to be handled by binding engines.
- Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image()
because ignoring the returned value is rarely a good idea (as you
usually want to delete the image).
- Remove gimp_export_options_new(): we don't need this constructor
because at this point, the best is to tell plug-in developers to just
pass NULL everywhere. This leaves us free to create a more useful
default constructor if needed, in the future. Main description for
GimpExportOptions has also been updated to say this.
- Add a data_destroy callback for the user data passed in
gimp_export_procedure_set_capabilities().
- Fixing annotations of 'export_options' object from pdb/pdb.pl: input
args would actually be (nullable) and would not transfer ownership
(calling code must still free the object). Return value's ownership on
the other hand is fully transfered.
- Add C and Python unit testing for GimpExportOptions and
gimp_export_options_get_image() in particular.
- Fix or improve various details.
Note that I have also considered for a long time changing the signature
of gimp_export_options_get_image() to return a boolean indicating
whether `image` had been replaced (hence needed deletion) or not. This
also meant getting rid of the GimpExportReturn enum. Right now it would
work because there are no third case, but I was considering the future
possibility that for instance we got some impossible conversion for some
future capability. I'm not sure it would ever happen; and for sure, this
is not desirable because it implies an export failure a bit late in the
workflow. But just in case, let's keep the enum return value. It does
not even make the using code that much more complicated (well just a
value comparison instead of a simple boolean test).
This patch creates a GimpExportOptions class in both
libgimpbase and in libgimp. Currently it is a mostly empty
object, but it will be added to after 3.0 to allow for
additional export options (like resizing on export while
leaving the original image intact)
libgimp/gimpexport.c was removed, and most of its content
was copied into libgimp/gimpexportoptions.c. gimp_export_image ()
was replaced with gimp_export_options_get_image () in all
export plug-ins.
GimpExportProcedure has a new function to set the default
image capabilities for each plug-in on creation. It also sets up
a new callback function, which allows the options to respond to
user setting changes (such as toggling 'Save as Animation' in the
GIF or WEBP Plug-in).
This is a followup of previous commit. As well diagnosed by Anders, this
value relies on "gegl:gaussian-blur" operation's argument's range.
Also adding a comment to make it easier for future developers seeing
this value.
gimp-buffer-get-image-type returns the output of
gimp_babl_format_get_image_type (), which itself returns
a GimpImageType enum. However, the PDB claims that
it's a GimpImageBaseType enum instead. This patch fixes
the documentation to match the actual output enum type.
Liam was hitting Backspace on "histogram" which is an action section and
would likely not return a proper GimpAction through
gimp_action_view_get_accel_action().
Therefore let's make sure we initialize properly the action to NULL.
The submenu labels for tool-options-popup were
hardcoded as English in GimpToolOptionsEditor's calls
to the Save, Restore, and Delete Tool Presets buttons.
This meant that these menus always fail when called in
non-English UIs, since we compare the path name and
submenu labels to only load the correct submenu items.
This patch attaches the English labels to the submenu
object so that we can retrieve it for comparison in
gimp_menu_model_get_submodel ().
to stop for instance
When using the scale tool and the layer has a selection, then after
finishing the scaling we get a critical in the terminal like this:
(gimp-2.99.exe:31824): GLib-GObject-CRITICAL **: 18:22:05.689:
../glib-2.80.2/gobject/gsignal.c:1184: no emission of signal
"tool-changed" to stop for instance '000002e8a0f91df0'
This commit moves the call to `g_signal_stop_emission_by_name` inside
the if active_tool != tool_type.
gimp_item_mask_bounds() does not actually return if there is intersected
contents between the item and the image's selection, but whether there
is a selection. So when it returns FALSE, it will also return the full
item's dimensions.
This patch resizes the selection mode
icons based on the user's icon size
settings. It creates a new function in
gimpenumwidgets.c to update sizes,
then connects to GimpGuiConfig's icon
size update notifications in GimpSelectionOptions.
This is the only "language" from the list whose name is special and
should be localized at runtime, yet before we set any Preferences
language. It needs to be localized as the System Language itself which
will be run-dependant.
For instance, if your system is in French, it will be displayed as
"Langue système" but if you change your system to Korean, at next run,
it would show "시스템 언어". It is a per-run localization, independant
from the language selected in Preferences, and even less dependant from
build-time system language.
Unlike the GimpTranslationStore which can use a list of pre-localized
languages (each language in its own name), the GimpLanguageStore must be
displayed in the currently used locale.
Instead of always parsing the ISO-639 listing at each and every startup,
let's just generate the list of languages, their English name, and the
self-localized names as static struct.
This will just be much faster, and no worrying on the size of the XML
(or json) to parse.
We have translations for ckb (Central Kurdish), which is only
available in iso codes 639_3. For our language selection we only
parse 639(_2), which causes this language to show up as `??? (ckb)`.
This is of course not a good user experience since users need to know
that ckb is the abbreviation of their language.
We fix this by parsing `iso_639_3.xml` instead of `iso_639.xml`. This
works, but, since this file is a lot bigger, it takes a lot more time
(more than 1 second difference) to parse this.
Now, this is only done on startup, but this can certainly be a
noticeable delay.
… to keyboard input.
Removing a GtkBindingSet entry actually removes it from all GtkTreeView.
It's not limited to the ones contained in GimpContainerTreeView (which
makes sense, since it relies on the class) so it broke various
interactions across the software.
Let's just connect to signal key-press-event instead and block further
propagation. Not sure anyway why GTK has so many ways to handle key
interactions!
I'm also moving the implementation to GimpItemTreeView because this
enhanced keyboard handling is really about the items tree dockables
only, for the time being at least.
… icon name.
As akk was reporting on IRC, the huge question mark from the
dialog-question icon really makes it feel like it's an help button
(especially when used as an actual button, e.g. in GEGL filter generated
dialogs with aux inputs, when no viewable has been set as input yet).
Currently we can't serialize GimpDrawable, which is necessary for us
to store filters with Aux Nodes. Therefore, they will automatically be
applied destructively as a workaround until we can.
