1. 23 Nov, 2018 1 commit
  2. 23 Sep, 2018 1 commit
  3. 03 Sep, 2018 1 commit
    • Ell's avatar
      app: add Windows backend to GimpBacktrace · 667efc22
      Ell authored
      The Windows backend produces full, multithreaded backtraces.  When
      DrMingw is available, it also provides full symbol and (where
      available) source-location information.  Otherwise, it provides
      symbol information for most of our libraries, but not for the GIMP
      binary itself.
      667efc22
  4. 02 Sep, 2018 1 commit
    • Ell's avatar
      app: add GimpBacktrace · 80bf686c
      Ell authored
      GimpBacktrace provides an interface for creating and traversing
      multi-threaded backtraces, as well as querying symbol information.
      While we already have some backtrace functionality, it relies on
      external tools for the most part, and as such is rather expensive,
      and is only meant for producing opaque backtraces.  GimpBacktrace,
      on the other hand, is meant to be relatively cheap (we're going to
      use it for profiling,) and allow inspection of the backtrace data.
      In the future, it might make sense to replace some, or all, of the
      other backtrace functions with GimpBacktrace.
      
      GimpBacktrace currently only supports Linux.  By default, it uses
      dladdr() to query symbol information, which is somewhat limited (in
      particular, it doesn't work for static functions.)  When libunwind
      is installed, GimpBacktrace uses it to get more complete symbol
      information.  libunwind is currently an optional dependency, but it
      might make sense to promote it to a mandatory, or opt-out,
      dependency, as it's lightweight and widely available.
      
      On other platforms, the GimpBacktrace interface can still be used,
      but it always returns NULL backtraces.
      80bf686c
  5. 02 Jul, 2018 1 commit
    • Jehan's avatar
      app: add base classes for the extension manager. · b70424b2
      Jehan authored
      Right now it only loads AppStream data, which is completely useless, yet
      is a base of a managed extension system. Having proper metadata is what
      will allow to actually know what is installed.
      This is only the first draft.
      
      Note that I am not adding the extension path into GimpCoreConfig on
      purpose, since the point is not to have people manage their extension
      directories manually anymore.
      The extensions will be loaded from the build-time system path or the
      config directory, and that's all.
      What will probably be stored in the config though will be the remote
      repositories URLs (allowing third-party extension repositories).
      b70424b2
  6. 28 Jun, 2018 1 commit
  7. 13 Jun, 2018 2 commits
  8. 29 May, 2018 2 commits
    • Ell's avatar
      app: add GimpAsyncSet · 80de7230
      Ell authored
      GimpAsyncSet represents a dynamic set of running GimpAsync objects.
      The objects are automatically removed from the set once they're
      synced.
      
      GimpAsyncSet implements the GimpWaitable and GimpCancelable
      interfaces, allowing the entire set to be waited-on or canceled.
      
      Additionally, GimpAsyncSet provides an "empty" property, which
      indicates whether the set is empty or not.  This allows responding
      to the completion of all the GimpAsync objects through the set's
      "notify::empty" signal, or drive UI changes through property
      bindings.
      80de7230
    • Ell's avatar
      app: add GimpUncancelableWaitable · 4cc92ebd
      Ell authored
      GimpUncancelableWaitable is a simple proxy object for another
      GimpWaitable object, implementing only the GimpWaitable interface.
      Its main purpose is to mask away the cancelability of an object
      implementing both GimpWaitable and GimpCancelable.
      4cc92ebd
  9. 28 May, 2018 1 commit
  10. 04 Apr, 2018 1 commit
    • Ell's avatar
      app: add gimp-parallel · 86b89cf6
      Ell authored
      Add gimp-parallel.[cc,h], which provides a set of parallel
      algorithms.
      
      These currently include:
      
        - gimp_parallel_distribute():  Calls a callback function in
          parallel on multiple threads, passing it the current thread
          index, and the total number of threads.  Allows specifying the
          maximal number of threads used.
      
        - gimp_parallel_distribute_range():  Splits a range of integers
          between multiple threads, passing the sub-range to a callback
          function.  Allows specifying the minimal sub-range size.
      
        - gimp_parallel_distribute_area():  Splits a rectangular area
          between multiple threads, passing the sub-area to a callback
          function.  Allows specifying the minimal sub-area.
      
      The callback function is passed using an appropriately-typed
      function pointer, and a user-data pointer.  Additionally, when used
      in a C++ file, each of the above functions has an overloaded
      template version, taking the callback through a generic parameter,
      without a user-data pointer, which allows using function objects.
      86b89cf6
  11. 30 Mar, 2018 1 commit
    • Michael Natterer's avatar
      Stop leaking properties of the distcheck machine into the tarball · 452b1bd5
      Michael Natterer authored
      Some gimprc properties' default values depend on the machine where
      "make dist" in run. We had an ugly hack in place to force
      (num-processors 1) in the installed system gimprc and its manpage, but
      were still leaking "tile-cache-size" and "mypaint-brush-path".
      
      The files are generated by the hidden options --dump-gimprc-system
      and --dump-gimprc-manpage which exist only for this purpose.
      
      In gimpconfig-dump.c, special case the three properties in
      dump_gimprc_system() and dump_gimprc_manpage() to output constant
      default values for "num-processors" and "tile-cache-size" and
      output @mypaint_brushes_dir@ in "mypaint-brush-path" which can
      be replaced at configure time.
      
      Also introduce etc/gimprc.in so @mypaint_brushes_dir@ can actually be
      substituted for the installed system gimprc.
      452b1bd5
  12. 04 Feb, 2018 1 commit
  13. 29 Jan, 2018 2 commits
    • Jehan's avatar
      app: move git-version.h generation to the repository root. · 44f23bdf
      Jehan authored
      The reason is that this file is now included for a binary in tools/ as
      well (the debug binary) and tools/ contents needs to be built before
      app/. Even using BUILT_SOURCES in the Makefile under app/ is not enough.
      Anyway it makes sense that this file should be under the root of the
      repository since that describes the status of the source repository. So
      let's move it up one folder.
      44f23bdf
    • Jehan's avatar
      app, tools: rename app/version.[ch] to app/gimp-version.[ch]. · 1b4efd2d
      Jehan authored
      Since commit 9fdf3555, I removed the GIMP_APP_GLUE_COMPILATION check
      because we need to have the whole versioning info from the new debug
      widget. It just makes sense to go further and just make this a proper
      internal API to get version information.
      1b4efd2d
  14. 28 Jan, 2018 1 commit
    • Jehan's avatar
      app, tools: install the debug tools in libexec when appropriate. · b318694b
      Jehan authored
      AFAIK this means on all platforms but Win32 and macOS which would rather
      need relative path and therefore cannot make use of build-time
      LIBEXECDIR. Anyway on these platforms, leaving the binary in BINDIR is
      not likely to "pollute" too much as it would on Linux or BSD where
      people often use terminal.
      b318694b
  15. 06 Dec, 2017 1 commit
  16. 09 Sep, 2017 1 commit
  17. 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
      function.
      
      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,
      currently.)
      
      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
      previously.
      
      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
      adjustments.
      71bbd88e
  18. 03 Jul, 2017 1 commit
  19. 22 Mar, 2017 1 commit
    • Ell's avatar
      app: fix abbreviated commit hashes · c97209ba
      Ell authored
      The abbreviated commit hash we show in the shell and the about
      dialog is currently just the last 7 characters of 'git describe',
      based on the assumption that abbreviated hashes are always 7-digits
      long.  When the hash is longer than that, we're just showing a
      nonsense commit.
      
      This was never a good idea, since users can override this, and
      since disambiguation can result in longer hashes, but since git
      2.11, the default abbreviated hash length is determined based on
      the size of the repository, which currently results in 10 digits
      for us.
      
      Let's just do it right.
      c97209ba
  20. 31 Jan, 2017 1 commit
  21. 17 Jan, 2017 1 commit
  22. 15 Jan, 2017 1 commit
  23. 09 Jan, 2017 1 commit
  24. 15 Sep, 2016 1 commit
  25. 12 Sep, 2016 1 commit
    • Michael Natterer's avatar
      app: merge units.[ch] into core/gimp-units.[ch] · 631110e0
      Michael Natterer authored
      and initialize units in gimp_init(). This was completely
      over-engineered but in the end boils down to a bad hack that needs a
      static "the_unit_gimp" pointer anyway, so let's at least have the hacks
      in one file.
      631110e0
  26. 12 Jun, 2016 1 commit
  27. 26 May, 2016 1 commit
  28. 02 Jan, 2016 1 commit
  29. 28 Dec, 2015 1 commit
  30. 29 Sep, 2015 1 commit
  31. 27 Aug, 2015 2 commits
  32. 30 Mar, 2015 2 commits
  33. 16 Feb, 2015 1 commit
  34. 16 Sep, 2014 1 commit
  35. 12 Aug, 2014 1 commit