1. 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
      "gimp*-python".
      
      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
        catalog.
      - Getting rid of the...
      18c37f70
  2. 01 Oct, 2021 1 commit
    • Jehan's avatar
      plug-ins: various g_file_get_path() replaced by g_file_peek_path(). · 27dea4f7
      Jehan authored
      As explained in previous commits, the _peek_ call is advantageous
      because:
      - It is less bug-prone as we don't have to handle freeing the string. In
        all the cases I changed, I even spotted at least 2 cases where we were
        leaking a string (in file-mng, `temp_file_name` is never freed; and we
        were also leaking in an error case of gfig).
      - As a consequence of the previous point: simpler code with less lines.
      - In local file cases, the _peek_ variant does not even need to allocate
        an additional string.
      - In other case, if we query several times the path, it is allocated
        once and cached so it stays efficient.
      - When possible, working on the GFile rather than on a path string may
        be more robust. For instance I changed one g_unlink() into a
        g_file_delete(). Actually most reading/writing should be done with the
        GIO API when possible, but I didn't want to change too much code
        logics on this commit.
      27dea4f7
  3. 18 May, 2021 1 commit
  4. 06 Apr, 2021 1 commit
    • Jehan's avatar
      app, libgimp, pdb, plug-ins: more functions moved to get|set(). · ca8bc2bc
      Jehan authored
      The gimp_drawable_type() is an issue though as gimp_drawable_get_type()
      is already defined as a common GObject API.
      Though I'm actually wondering if GimpImageType is well called. Rather
      than Type, shouldn't we go with ColorModel?
      
      sed -i 's/\<gimp_drawable_bpp\>/gimp_drawable_get_bpp/g' "$@"
      sed -i 's/\<gimp_drawable_width\>/gimp_drawable_get_width/g' "$@"
      sed -i 's/\<gimp_drawable_height\>/gimp_drawable_get_height/g' "$@"
      sed -i 's/\<gimp_drawable_offsets\>/gimp_drawable_get_offsets/g' "$@"
      ca8bc2bc
  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
      drawable.
      
      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 wil...
      d3139e0f
  6. 23 Oct, 2019 1 commit
  7. 25 Sep, 2019 2 commits
  8. 23 Sep, 2019 1 commit
  9. 20 Sep, 2019 1 commit
  10. 11 Sep, 2019 1 commit
  11. 09 Sep, 2019 1 commit
  12. 30 Aug, 2019 1 commit
  13. 22 Aug, 2019 1 commit
  14. 19 Aug, 2019 2 commits
  15. 18 Aug, 2019 1 commit
  16. 15 Aug, 2019 1 commit
  17. 22 Oct, 2018 1 commit
  18. 12 Aug, 2018 1 commit
    • Jehan's avatar
      plug-ins: replace s/printf/g_printf/ · 0832bbd7
      Jehan authored
      When cross-compiling, I got various linking errors for printf() calls:
      > undefined reference to `libintl_printf'
      
      I am unsure why, since this is not recent code, and it used to build
      fine with mingw64 compilers (last I cross-built, which is many months
      ago). Anyway g_printf() works fine, all necessary libs are already
      linked, and it is supposed to be a synonym. So let's just go the easy
      way and use g_printf() only.
      
      (cherry picked from commit c49afa4f)
      0832bbd7
  19. 11 Jul, 2018 1 commit
  20. 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().
      e16c8a23
  21. 20 Aug, 2017 1 commit
  22. 26 Feb, 2017 1 commit
  23. 08 Jan, 2017 1 commit
  24. 16 Feb, 2016 1 commit
  25. 23 Jul, 2014 1 commit
  26. 09 Nov, 2013 1 commit
  27. 27 Nov, 2012 1 commit
  28. 22 Sep, 2012 1 commit
  29. 06 Oct, 2011 1 commit
  30. 10 Apr, 2011 1 commit
  31. 08 Apr, 2011 1 commit
  32. 05 Oct, 2010 1 commit
  33. 06 Sep, 2010 1 commit
  34. 16 Aug, 2010 1 commit
  35. 09 Dec, 2009 3 commits
  36. 21 Jul, 2009 1 commit