GitLab

Commit c83ee61c got overridded by commit b5cc2a97.
Reintroducing the changes.

skal authored Nov 24, 2016 and Jehan committed Nov 26, 2016

webp-save: Add UI elements for 'minimize size' toggle, and a dependent
'max key-frame distance' setting.
* If 'minimize size' is active, max-kf is disabled (which is equivalent to
  setting it to infinity). Key-frame cost file size, that's why.
* If 'minimize size' is disabled, you get to choose how far key-frames
  (=cue points) will be inserted at max.

and use it where possible instead of gimp_dialog_factory_get_singleton().
Also reduce using this function in some other places.

This reverts commit eab4929a.

Oups it would seem gtk_accel_map_change_entry() could return FALSE even
when the expected shortcut is correctly set (my guess is that it was
already the same shortcut, so indeed no "change" happened, though it is
not a failure either; yet I haven't checked if that is the actual
reason).
Let's just revert this. It's not always a good thing to be too thorough!
Sorry for this!

These are used for display switching, and even though you could
remap these shortcuts, it would work only until you close an image,
open a new one, or reorder tabs in SWM, in which case your shortcut
would end up forcefully overrided, which is a bad user experience.
If we want to give more flexibility and allow one to map these
shortcuts, we must also make sure the display showing actions won't
override customized shortcuts. In the meantime, it is better to
simply forbid these in our preferences.

... for "windows-display-*" actions.
I should not happen, but let's be thorough and properly handle failure
with a message since this is a runtime issue.

gtk_action_group_remove_action() removes the action from the group while
not actually cleaning any accelerator. This is a problem for transient
actions which have only a meaning within the current session, such as
the display switching actions named with the display ID (unique within
the session only).
Current commit, combined with the previous one (commit c0ee9599), fix
"windows-display-*" actions being saved inside menurc.

Some actions are not meant to be saved, in particular the
"windows-display-*" which have only a meaning during a same session
since display IDs are session-dependent. So let display deletion
happen first so that proper cleaning of action is done when writing
menurc.

Revert "app: action search should search accross all available actions."

This reverts commit 53b3673b.

Had to revert these two commits, quoting comment 6 of the bug:

Thinking again, that entire change is unfortunately wrong, the only
right UI manager is in fact

gimp_ui_managers_from_name ("<Image>")->data

because it's the global popup <Image> UI manager which is independent
of a display and it always in the right state for the currently
active image, all other UI managers are wrong.

Revert "app: do not show the actions from <Dockable> GimpUIManager."

This reverts commit b795ae22.

Current defaults are from another time. Acceptable defaults could be
common screen resolutions. 1366x768 is apparently the most common
(according to various stats on the web), but since we target advanced
graphics artists, let's go for 1920x1080, which is the second most
common resolution, also known as Full HD.
For unstable builds, let's have at least one odd number, uncommon ratio
and higher values, encouraging tests with less common numbers and bigger
images. I chose 2001x1984. Feel free to update to any other funky values
following these "unstable" rules.

... with something more suitable.
72 PPI is from a time where people thought this was a common screen
resolution. This is not the case nowadays, and anyway images targetted
for screen display should not bother with PPI resolution at all, only
with actual pixel dimensions.
PPI resolution is more useful for printing. And for this case, 300 is
quite an accepted OK value for most cases. So this is likely a better
default for GIMP.

- WebPPictureImportRGB(A)() docs say these functions return "false in
  case of memory error". Handle such cases.
- status was not updated when WebPEncode() would fail in save_layer().
- gegl_buffer_flush() is unnecessary just before last unref-ing GEGL
  buffers. This is done automatically at destruction.
- Destroy resources at the same level as they were created if possible.
  This makes the code more readable and maintainable. Consequently
  better not unref parameter GEGL buffers inside combine_buffers().
- Some minor formatting cleanup.

skal authored Nov 23, 2016 and Jehan committed Nov 23, 2016

when saving as animated-webp, use Gegl:over to composite current layer
with the previous frame if needed.

Add GimpMenuFactory can always be found in a GimpDialogManager, use
gimp_dialog_factory_get_menu_factory() where we have a dialog factory
instead of accessing "global_menu_factory" or redundantly passing a
menu factory around where we already pass around a dialog factory.

<Dockable> has this whole list of actions named similarly to dialogs-*
actions, and we don't want these to take precedence, especially since
they would always create a new dock instead of just showing the existing
one if already present.
Also fix the redundancy check on already added actions.

It was only searching through the "<Image>" GimpUIManager, so several
action groups were ignored, for instance all palettes-* actions.

... in commit ac50da2a, respectively into filters-repeat and
filters-reshow.

There is no reasons not to translate the "occurs" text which will be
in the color names in palettes extracted from images. It indicates on
how many pixels a given extracted color was occuring. We should also
translate the full string (not just "occurs") since some language will
have to reorder words, and may even use different bracket characters.
So I also add a translator comment to make sure the translators get
what the %s and %d stand for in this string.

Forgot GimpControllerMouse when fixing this bug. Also apply
the cleanup from the commit below.

to not use two nested if()s, and always return the result of
gimp_controller_event() when an event matches.

Always check pointer before dereferencing it, when it can be NULL.

Duplicate accelerators are not supposed to happen. It is not possible
to set them through the GUI in particular. Nevertheless
gtk_accel_map_load() would apparently let duplicates pass, which could
happen after editing the menurc directly, or using the development
version (no action name migration happens there), or simply after a
potential bug. This is then very annoying because you may see several
actions displaying the same shortcut but only one actually work. And
trying to re-set through GUI the shortcut to the one action you wish to
run does not fix the duplicate issue (you have to laboriously find which
other action use the same accelerator and delete it first).
Better be safe than sorry and make a quick check at startup, then delete
the accelerator on one of the duplicates (you can't guess which one was
actually wanted, but at least you will facilitate manual reset through
the GUI).