1. 28 Aug, 2017 1 commit
  2. 24 Aug, 2017 1 commit
  3. 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().
  4. 20 Aug, 2017 1 commit
  5. 17 Aug, 2017 1 commit
    • Ell's avatar
      app: layer mode code shuffling · 71bbd88e
      Ell authored
      Commit 3635cf04 moved the special
      handling of bottom-layer compositing to GimpOperationLayerMode.
      This required giving the op more control over the process()
      function of its subclasses.  As a temporary workaround, the commit
      bypassed the subclasses entirely, using "gimp:layer-mode" for all
      modes.  This is the reckoning :)
      Add a process() virtual function to GimpOperationLayerMode, which
      its subclasses should override instead of
      GeglOperationPointComposer3's process() functions.  Reinstate the
      subclasses (by returning the correct op in
      gimp_layer_mode_get_oepration()), and have them override this
      Improve the way gimp_operation_layer_mode_process() dispatches to
      the actual process function, to slightly lower its overhead and
      fix some thread-safety issues.
      Remove the "function" field of the layer-mode info array, and have
      gimp_layer_mode_get_function() return the
      GimpOperationLayerMode::process() function of the corresponding
      op's class (caching the result, to keep it cheap.)  This reduces
      redundancy, allows us to make the ops' process() functions private,
      and simplifies SSE dispatching (only used by NORMAL mode,
      Move the blend and composite functions of the non-specialized
      layer modes to gimpoperationlayermode-{blend,composite}.[hc],
      respectively, to improve code organization.
      Move the SSE2 composite functions to a separate file, so that they
      can be built as part of libapplayermodes_sse2, allowing
      libapplayermodes to be built without SSE2 compiler flags.  This
      allows building GIMP with SSE acceleration enabled, while running
      the resulting binary on a target with no SSE accelration.
      Add a "blend_function" field to the layer-mode info array, and use
      it to specify the blend function for the non-specialized modes.
      This replaces the separate switch() statement that we used
      Remove the "affected_region" field of the layer-mode info array.
      We don't need it anymore, since we can go back to using
      GimpOperationLayerMode's virtual get_affected_region() function.
      Last but not least, a bunch of code cleanups and consistency
  6. 08 Aug, 2017 1 commit
  7. 28 Jul, 2017 2 commits
  8. 18 Jul, 2017 2 commits
    • Jehan's avatar
      app: GIMP_MAX_NUM_THREADS should follow max value of GeglConfig's... · 894d85f6
      Jehan authored
      ... "threads" property.
      Actually there is no need of having a public GEGL_MAX_THREADS as written
      in the previous commit. We can just retrieve the max for a GObject
    • Jehan's avatar
      Bug 784226 - Maximum of processing threads hard-coded to 16. · 32ffabcb
      Jehan authored
      Raise GIMP_MAX_NUM_THREADS to 64, following the changes in GEGL (see
      GEGL commits 6d128ac and f26acbb). This is still considered unstable and
      to be used at one's own risk (cf. GIMP commit 1f5739de) but at least, it
      could allow discovering and fixing bugs.
      It would be nice if GEGL_MAX_THREADS could be public so that to not have
      to edit this by hand at each change.
  9. 15 Jul, 2017 1 commit
  10. 28 Jun, 2017 2 commits
  11. 19 Jun, 2017 1 commit
  12. 02 Jun, 2017 2 commits
  13. 23 May, 2017 1 commit
    • Ell's avatar
      enums: run gimp-mkenums from the build dir · 5bcde32c
      Ell authored
      Commit 1e6acbd4 modified the
      generated enum recipes to run gimp-mkenums from the source
      directory, instead of the build directory, so that only the
      basenames of the corresponding header files would appear in
      the comment at the top of the generated files.  This was a
      mistake -- $(GIMP_MKENUMS) is expecting to be invoked from the
      build directory.
      Switch back to running gimp-mkenums from the build directory.  To
      avoid including the relative path from the build directory to the
      source directory in the generated file, add a @basename@ production
      variable to gimp-mkenums, which exapnds to the basename of the
      input file, and use it instead of @filename@ in the recipes for the
      generated enum files.
  14. 22 May, 2017 1 commit
    • Ell's avatar
      enums: don't write generated enum files to src-dir if unchanged · f9fa0d1b
      Ell authored
      When regenerating an enum file, don't copy it back to the source
      directory if it hasn't actually changed.  This allows using a read-
      only source directory where the enum header is newer than the
      generated file, as long as they're not really out of sync.
      OTOH, *do* touch the generated source-dir file even when unchanged,
      in order to avoid re-running its recipe on the next build, however,
      allow this to silently fail (which is harmless).
  15. 06 May, 2017 1 commit
    • Ell's avatar
      enums: generate enum files in source dir · 1e6acbd4
      Ell authored
      We check them into git, so this makes it easier to keep them in
      sync when using a separate build directory.
      Case in point -- this commit also syncs a few enum files that went
      out-of-sync with their headers.
  16. 04 May, 2017 2 commits
  17. 01 May, 2017 1 commit
  18. 23 Mar, 2017 1 commit
  19. 21 Mar, 2017 3 commits
    • Jehan's avatar
      app: core/gimpmarshal.h is generated after building in app/config/. · f6cb74c0
      Jehan authored
      It is a little fuzzy whether expected or not, architecturally-wise. On
      one hand, I can see some core/ header includes under config/. Though on
      the other hand, app/Makefile.am explicitly sorts config/ below core/.
      Anyway let's just use g_cclosure_marshal_VOID__VOID which is the same as
      gimp_marshal_VOID__VOID and get rid of the include.
      This fixes builds from scratch.
    • Jehan's avatar
      Bug 750180 - Fix different ways of writing Plug-in Plug-In Plugin. · bc344a99
      Jehan authored
      It was agreed that we should write "plug-in" consistently. Only possibly
      user-visible strings were updated.
      Thanks to scootergrisen for a first patch which could not make it
      after changing decision on the canonical writing.
    • Jehan's avatar
      app: add icon size auto-guess from monitor resolution. · d339aef7
      Jehan authored
      Current code only guess resolution for a single monitor. Ideally
      the widget sizes could be different depending on the window where a
      given widget is on. But that's a start.
  20. 11 Mar, 2017 2 commits
  21. 26 Feb, 2017 3 commits
  22. 17 Feb, 2017 1 commit
  23. 12 Feb, 2017 1 commit
  24. 01 Feb, 2017 1 commit
  25. 31 Jan, 2017 1 commit
  26. 22 Jan, 2017 2 commits
  27. 17 Jan, 2017 1 commit
  28. 15 Jan, 2017 1 commit
  29. 09 Jan, 2017 1 commit