1. 05 Jul, 2022 1 commit
  2. 04 Jun, 2022 1 commit
    • Jehan's avatar
      plug-ins, libgimp: override set_i18n() for all our core plug-ins. · 18c37f70
      Jehan authored
      Hence avoiding the stderr messages. These are going to be localized with
      centrally installed catalogs "gimp*-std-plugins", "gimp*-script-fu" and
      We now handle core plug-in localizations differently and in particular,
      with kind of a reverse logic:
      - We don't consider "gimp*-std-plugins" to be the default catalog
        anymore. It made sense in the old world where we would consider the
        core plug-ins to be the most important and numerous ones. But we want
        to push a world where people are even more encouraged to develop their
        own plug-ins. These won't use the standard catalog anymore (because
        there are nearly no reasons that the strings are the same, it's only a
        confusing logic). So let's explicitly set the standard catalogs with
        DEFINE_STD_SET_I18N macro (which maps to a different catalog for
        script-fu plug-ins).
      - Doing something similar for Python plug-ins which have again their own
      - Getting rid of the...
  3. 14 Oct, 2021 1 commit
    • Jehan's avatar
      Issue #5313: consistent "file-pat-save-internal" procedure with… · 6905b0bb
      Jehan authored
      … multiple drawables as parameter.
      Previous commit 7bb892f3 was "making it work" by making the API
      inconsistent and also only using the first drawable, which is making the
      logics meaningless.
      Instead accept multiple drawables, and export only the selected drawable
      (when alone) or the merged-down image containing only the selected
      drawables (when many).
      Note that in current implementation, this is not useful from GUI calls
      because the fully merged image is always exported when run interactively
      or with last vals (i.e. from the GUI) because gimp_export_image()
      flattens the image. So this change would only work when called
      non-interactively from other plug-ins. In such a case, multi-layer
      images do no longer return an error and whatever items are selected
      would change the export result.
      See also #7370 for a discussion about how to handle the selected items
      during export (because currently the `drawables` parameter of
      GimpSaveProcedure's run function is clearly a mostly bogus parameter).
  4. 09 Aug, 2021 1 commit
  5. 17 May, 2020 1 commit
    • Jehan's avatar
      app: support saving/exporting with multi-selection. · d3139e0f
      Jehan authored
      This commit just changes our saving API (i.e. the GimpSaveProcedure
      class) to take an array of drawables as argument instead of a single
      It actually doesn't matter much for exporting as the whole API seems
      more or less bogus there and all formats plug-ins mostly care only
      whether they will merge/flatten all visible layers (the selected ones
      don't really matter) or if the format supports layers of some sort. It
      may be worth later strengthening a bit this whole logics, and maybe
      allow partial exports for instance.
      As for saving, it was not even looking at the passed GimpDrawable either
      and was simply re-querying the active layer anyway.
      Note that I don't implement the multi-selection saving in XCF yet in
      this commit. I only updated the API. The reason is that the current
      commit won't be backportable to gimp-2-10 because it is an API break. On
      the other hand, the code to save multi-selection can still be backported
      even though the save() API will only pass a single drawable (as I said
      anyway, this argument was mostly bogus until now, hence it doesn't
      matter much for 2.10 logics).
  6. 25 Sep, 2019 2 commits
  7. 24 Sep, 2019 1 commit
  8. 23 Sep, 2019 1 commit
  9. 20 Sep, 2019 1 commit
  10. 10 Sep, 2019 1 commit
  11. 09 Sep, 2019 1 commit
  12. 30 Aug, 2019 1 commit
  13. 29 Aug, 2019 1 commit
    • Michael Natterer's avatar
      app, libgimp: get rid of all ID GTypes and ID param specs · 392f00ba
      Michael Natterer authored
      Turn all ID param specs into object param specs (e.g. GimpParamImageID
      becomes GimpParamImage) and convert between IDs and objects in
      gimpgpparams.c directly above the the wire protocol, so all of app/,
      libgimp/ and plug-ins/ can deal directly with objects down to the
      lowest level and not care about IDs.
      Use the actual object param specs for procedure arguments and return
      values again instead of a plain g_param_spec_object() and bring back
      the none_ok parameter.
      This implies changing the PDB type checking functions to work on pure
      integers instead of IDs (one can't check whether object creation is
      possible if performing that check requires the object to already
      For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
      not involved in automatic object creation magic at the protocol
      level. Added wrappers which still say gimp_foo_is_valid() and take the
      respective objects.
      Adapted all code, and it all becomes nicer and less convoluted, even
      the generated PDB wrappers in app/ and libgimp/.
  14. 22 Aug, 2019 1 commit
  15. 19 Aug, 2019 3 commits
  16. 18 Aug, 2019 1 commit
  17. 14 Aug, 2019 1 commit
  18. 13 Aug, 2019 1 commit
  19. 11 Aug, 2019 3 commits
  20. 10 Aug, 2019 1 commit
  21. 16 Feb, 2019 1 commit
  22. 12 Feb, 2019 2 commits
    • Michael Natterer's avatar
    • Michael Natterer's avatar
      app, plug-ins: move pattern saving to the core · b29ecfb5
      Michael Natterer authored
      but only the actual saving code, not the export magic and dialog.
      Add new internal procedure file-pat-save-internal which is not
      registered as a file procedure and always works non-interactively on
      the passed arguments and only saves the passed drawable. Use the new
      internal procedure from the file-pat-save code and remove all file
      writing code from the plug-in.
      This way all pattern file writing code duplication is killed, while
      the whole export mechanism is completely unchanged.
  23. 11 Feb, 2019 1 commit
  24. 27 Nov, 2018 1 commit
    • Jehan's avatar
      plug-ins: make various usage of g_file_replace() safer. · 66ec4672
      Jehan authored
      As I did on app/, finalizing an output stream also implicitly flushes
      and closes it. Hence if an export ended with an error, we'd end up with
      incomplete data file (possibly overwriting a previously exported image).
      Only 2 plug-ins I haven't fixed yet are file-tiff-io and file-gif-save.
      The later one don't even clean up its memory (which somehow is good here
      as at least the output stream is never finalized hence sane files are
      not overwritten in case of errors). As for the former (TIFF plug-in), it
      doesn't even seem to have any error control AFAICS, apart from printing
      error messages on standard error output.
  25. 11 Jul, 2018 1 commit
  26. 07 Jul, 2018 1 commit
  27. 06 Jul, 2018 2 commits
  28. 20 May, 2018 1 commit
  29. 21 Dec, 2017 1 commit
  30. 21 Aug, 2017 1 commit
    • Michael Natterer's avatar
      Move the new "default_new_layer_mode" APIs to the image... · e16c8a23
      Michael Natterer authored
      ...in both the core and libgimp.
      Images now know what the default mode for new layers is:
      - NORMAL for empty images
      - NORMAL for images with any non-legacy layer
      - NORMAL_LEGAVY for images with only legacy layers
      This changes behavior when layers are created from the UI, but *also*
      when created by plug-ins (yes there is a compat issue here):
      - Most (all?) single-layer file importers now create NORMAL layers
      - Screenshot, Webpage etc also create NORMAL layers
      Scripts that create images from scratch (logos etc) should not be
      affected because they usually have NORMAL_LEGACY hardcoded.
      3rd party plug-ins and scripts will also behave old-style unless they
      get ported to gimp_image_get_default_new_layer_mode().
  31. 20 Aug, 2017 1 commit
  32. 05 Mar, 2017 1 commit
  33. 26 Feb, 2017 1 commit