Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pull] master from GNOME:master #605

Merged
merged 6 commits into from
Feb 21, 2025
Merged

[pull] master from GNOME:master #605

merged 6 commits into from
Feb 21, 2025

Conversation

pull[bot]
Copy link

@pull pull bot commented Feb 21, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.1)

Can you help keep this open source service alive? 💖 Please sponsor : )

Jehan added 6 commits February 21, 2025 18:33
…rsing fails.

In particular, we don't want to return/store a bogus GimpHelpLocale for
which the parsing actually failed.
Fixes:

> app/gimp-3.0: Gimp-Core-CRITICAL: gimp_image_remove_layer: assertion 'gimp_item_is_attached (GIMP_ITEM (layer))' failed
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 cdc2f0d in
2004, though we can actually find older commits where it was removed
(921f00c), added (1db2ada)… Looks like it used to be quite a
dance, but this is hopefully not needed anymore.
Help ID of filters with an explicit help ID got broken with commit
8c0fdb9 (which was fixing help ID for filters added to menus with a
GEGL key).
…th" key.

This is an alternative implementation for issue #12825, replacing commit
424ef17, 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.
@pull pull bot added the ⤵️ pull label Feb 21, 2025
@pull pull bot merged commit 6076c4d into kkpan11:master Feb 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants