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 INIT_I18N macro since now all the locale domain
        binding is done automatically by libgimp when using the set_i18n()
        method infrastructure.
  3. 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
      - 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.
  4. 24 Sep, 2020 1 commit
    • Jehan's avatar
      app, libgimp, plug-ins: move Orientation metadata handling into core. · 67e2e1b5
      Jehan authored
      Orientation is now handled by core code, just next to profile conversion
      One of the first consequence is that we don't need to have a non-GUI
      version gimp_image_metadata_load_finish_batch() in libgimp, next to a
      GUI version of the gimp_image_metadata_load_finish() function in
      libgimpui. This makes for simpler API.
      Also a plug-in which wishes to get access to the rotation dialog
      provided by GIMP without loading ligimpui/GTK+ (for whatever reason)
      will still have the feature.
      The main advantage is that the "Don't ask me again" feature is now
      handled by a settings in `Preferences > Image Import & Export` as the
      "Metadata rotation policy". Until now it was saved as a global parasite,
      which made it virtually non-editable once you checked it once (no easy
      way to edit parasites except by scripts). So say you refused the
      rotation once while checking "Don't ask again", and GIMP will forever
      discard the rotation metadata without givin...
  5. 11 Sep, 2019 1 commit
  6. 30 Aug, 2019 1 commit
  7. 22 Aug, 2019 1 commit
  8. 19 Aug, 2019 1 commit
  9. 15 Aug, 2019 2 commits
  10. 26 Jun, 2019 1 commit
  11. 25 Jun, 2019 1 commit
  12. 11 Jul, 2018 1 commit
  13. 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().
  14. 20 Aug, 2017 1 commit
  15. 26 Feb, 2017 1 commit
  16. 08 Jan, 2017 1 commit
  17. 29 Apr, 2016 1 commit
  18. 24 Apr, 2016 1 commit
  19. 22 Apr, 2016 3 commits
  20. 18 Apr, 2016 1 commit
  21. 20 Sep, 2015 2 commits
  22. 23 Jul, 2014 1 commit
  23. 23 Jun, 2013 1 commit
    • Michael Natterer's avatar
      Add support for both gamma-corrected and linear for all bit depths · caf73f5f
      Michael Natterer authored
      - Add new enum GimpComponentType which contains u8, u16, u32 etc.
      - Change GimpPrecision to be u8-linear, u8-gamma, u16-linear etc.
      - Add all the needed formats to gimp-babl.c
      - Bump the XCF version to 5 and make sure version 4 with the old
        GimpPrecision enum values is loaded correctly
      This change blows up the precision enums in "New Image" and
      Image->Precision so we can test all this stuff. It is undecided what
      format will be user-visible options in 2.10.
  24. 07 May, 2013 1 commit
  25. 04 May, 2013 2 commits
    • Mukund Sivaraman's avatar
    • Mukund Sivaraman's avatar
      file-exr: Add initial implementation (loader) · 8d89efaf
      Mukund Sivaraman authored
      This is a basic implementation of an OpenEXR loader. This
      "infrastructure" is required for any further work. It consists of:
      * The build system changes.
      * A C wrapper around the OpenEXR library, which is necessary as it's not
        possible to intermix GIMP's code with C++ code.
      * A basic image loader. Chroma is not supported currently, and some
        other weird files like multi-view files are unsupported. These can be
        added when necessary. There is no UI, but it should be straightforward
        to add new features like this on top of this work.