1. 05 Jul, 2022 2 commits
    • Jehan's avatar
      plug-ins: label and documentation of plug-ins localized plug-in side. · df074bfe
      Jehan authored
      This is the consequence of previous commit. Plug-ins' label and
      documentation are now localized before sending these data to GIMP core.
      In other words, we replace N_() macros with basic gettext calls.
    • Jehan's avatar
      Issue #8124: plug-in localization now totally moved plug-in side. · 81b569cb
      Jehan authored
      Plug-in localization was always partially plug-in side, especially for
      things like custom GUI. But labels or blurb in GIMP (such as in menus or
      action search) were localizing GIMP side.
      It had many drawbacks:
      - To get menu localization, a plug-in had to set up gettext, even though
        they might want to use something else for their GUI (after all, giving
        facilities for gettext is a good idea, but there is no reason to force
        using this system).
      - There was a complex internal system passing the localization domain
        name, as well as the catalog file system path to core, then through
        various classes which we can now get rid of.
      - There could be domain name clashes, if 2 plug-ins were to use the same
        i18n domain name. This was handled in now removed functions
        gimp_plug_in_manager_get_locale_domains() by simply keeping a unique
        one (and gimp_plug_in_manager_bind_text_domains() would just bind the
        domain to the kept directory). In o...
  2. 04 Jul, 2022 1 commit
    • Lloyd Konneker's avatar
      ScriptFu: Extract informal class SFArg from script-fu-script.c · fadae206
      Lloyd Konneker authored and Lloyd Konneker's avatar Lloyd Konneker committed
      Why: puts most methods for SFArg (a struct) in one place, for ease of maintenance.
      Prepares to fix issue 8328.  Prepares to make SF use GimpProcedureDialog.
      Mostly moving code, with no intended change in functionality,
      except fixed an property.nick for an arg is now what a script author provided,
      instead of generated.
      All internal to libscriptfu.  No changes to the exported API or to i18n.
      Lightly tested, since more substantive changes coming for issue 8328.
      ScriptFu>Test>Sphere is the test case.
  3. 03 Jul, 2022 3 commits
  4. 02 Jul, 2022 3 commits
    • Jehan's avatar
      NEWS: update. · 5df6c735
      Jehan authored
    • Jehan's avatar
      app: s/g_warning/g_printerr/ to warn about duplicate actions. · 420f1f53
      Jehan authored
      g_warning() (as well as g_critical() and g_return_*()) are reserved for
      core code bugs, and therefore triggers a debug dialog with a backtrace
      to report.
      Here I encountered such duplicate because ts-helloworld.scm was moved
      around from scripts/ to plug-ins/ since commit d5a83429 and I hadn't
      done a clean uninstall (so of course someone with package installation
      should not have such a debug dialog). Yet it could actually happen for
      various reasons, such as third-party plug-ins actually registering
      identically named actions. Such reasons are not core code bugs and we
      don't want to trigger a debug dialog (and have people report bugs to us
      which are not actual bugs and which we have no power to fix) each time a
      plug-in developer uses a too generic action name.
      So instead let's just print to stderr for now. I also add the
      information on which plug-in was discarded (otherwise if you actually
      have 2 different plug-ins doing different things, you wouldn't know
      which one is the visible one and which one can't be called).
      Note that I hesitated with a g_message() which would pop-up a
      user-facing error and would help them better handle their plug-in
      conflict. But I'm not sure it's ideal in current state of things either.
      It might be much better handled when we will have moved to recommending
      extensions wrapping plug-ins.
    • Alx Sa's avatar
      core: Add softproof profile to GimpImage · 0d7fed93
      Alx Sa authored and Jehan's avatar Jehan committed
      Adds a simulation_profile to GimpImage to allow plug-ins to access it
      for CMYK import/export.
      Two pdb functions were added to enable this access:
      image_get_simulation_profile () and image_set_simulation_profile()
      Next, it updates menu options and code to support GimpImage's
      internal simulation profile. Menu items are moved from View to Image's
      Color Management section.
      New 'simulation-profile-changed' signal is emitted via
      GimpColorManagedInterface so that relevant tools (such as the
      CYMK color picker, GimpColorFrame, and future dockable
      dialogue) are aware of these changes.
  5. 01 Jul, 2022 7 commits
  6. 30 Jun, 2022 5 commits
  7. 29 Jun, 2022 1 commit
  8. 28 Jun, 2022 1 commit
  9. 27 Jun, 2022 4 commits
    • Jehan's avatar
      plug-ins: use list() variants in bindings. · 69f6f574
      Jehan authored
      Cf. previous commit.
    • Jehan's avatar
      Issue #5946: skip gimp_*get_*() API from GObject Introspection. · 15ec2541
      Jehan authored
      The get() API are sometimes nicer in C code because it's just simpler to
      loop through C arrays, but they end up with similar API to the list()
      variants for binding, or with a useless size return value (since most
      higher level languages have length-aware array types, which is what
      GList are transformed into).
      So let's use the list() variants as the main ones and skip the get()
      variants. I hesitated to rename the list() variants to get() with
      `(rename-to)` annotations but since I am unsure if the get() bindings
      are absolutely useless, I don't think it's the best idea. Maybe on some
      other language usable as GI binding, the get() variant might be
      different again and nicer to use. So if we shadowed these by renaming
      list() ones, the day we change our mind, we'd have to rename get() ones
      too (which would be very confusing), or else break bindings' API. To
      avoid this, I just skip the get() ones altogether in bindings but leave
      their name available ...
    • Niels De Graef's avatar
      po-tips: Fix gettext translation · 3473883e
      Niels De Graef authored
    • Nathan Follens's avatar
      Update Dutch translation · 1e8f2d0a
      Nathan Follens authored and Administrator's avatar Administrator committed
  10. 26 Jun, 2022 6 commits
  11. 25 Jun, 2022 7 commits
    • Yuri Chornoivan's avatar
      Update Ukrainian translation · cac8f7f5
      Yuri Chornoivan authored and Administrator's avatar Administrator committed
    • Yuri Chornoivan's avatar
      Update Ukrainian translation · ca4e6d0d
      Yuri Chornoivan authored and Administrator's avatar Administrator committed
    • Yuri Chornoivan's avatar
      Update Ukrainian translation · 4eb29abf
      Yuri Chornoivan authored and Administrator's avatar Administrator committed
    • Lukas Oberhuber's avatar
      app, macOS: Remove crash handling conflict · 87752089
      Lukas Oberhuber authored and Jehan's avatar Jehan committed
    • Jehan's avatar
      build: intltool is still needed by libmypaint. · dfa1f0fc
      Jehan authored
    • Jehan's avatar
      build: fix the distcheck. · 66812c88
      Jehan authored
      MR !653 was merged too early as Gitlab bugged on us! Anyway this fixes
      the distribution contents.
    • Jehan's avatar
      extensions: fix builds after MR !653 (migrating to gettext). · 8122e8cf
      Jehan authored
      (1) On recent meson versions, it fixes this error:
      > extensions/goat-exercises/meson.build:108:0: ERROR: i18n.merge_file keyword argument 'output' was of type array[str] but should have been str
      As docs explains, 'output' only accepts one item in i18n.merge_file().
      This bug also happens on older meson (but there the reported error is a
      lot less useful as it doesn't mention local meson build code).
      (2) `setup.isl.xml` is a temporary intermediary file used to create the
          Windows installer. It must not be installed.
      (3) `gimp30-windows-installer.mo` itself is only used to create
          `setup.isl.xml`. It must not be installed as well.
      (4) gimp-tips.(its|loc) files (same for gimp-tags ones) should not be
          installed. They are only temporary data.
      (5) Fix environment variable: s/GETTEXT_DATA_DIRS/GETTEXTDATADIRS/
      > /usr/bin/msgfmt: cannot locate ITS rules for ../../../data/tips/gimp-tips.xml.in
      (6) Fix various bugs in the *.setup.isl files creation in autotools
          build (typo, wrong files used, order of options in `xsltproc`
          apparently meaningful, and so on. I guess the autotools build was
          not as well tested as the meson one :P).
      (7) Fixing the unit test verifying language lists consistency.
      (8) `setup.isl.xml.in` must be added to the distribution.