1. 05 Dec, 2017 11 commits
    • Alexandre Prokoudine's avatar
      Update Russian translation · 7b6d040f
      Alexandre Prokoudine authored
    • Ell's avatar
      app: handle visbility/excludes-backdrop changes in floating sel. · 6a7c0d62
      Ell authored
      When attaching a layer as a floating selection to a drawable,
      unbind its visiblility from its activeness, as per the previous
      commit, and use its visibility to control the activeness of the
      drawable's floating selection filter.
      Properly update the drawable when the floating selection's
      visibility and excludes-backdrop properties change.
    • Ell's avatar
      app: add GimpFilter::active property; move ::visible to GimpItem · f5d1686a
      Ell authored
      Add an "active" property to GimpFilter, which replaces its
      "visible" property.  The new property assumes the lower-level role
      "visible" had -- controlling whether the filter has any effect as
      part of its parent filter-stack.
      Add a "visible" property to GimpItem, separate from the "active"
      property, which assumes the higher-level role "visible" had --
      controlling whether the item is considered "visible", as per the
      GUI.  By default, the item's "visible" property is bound to the
      filter's "active" property, so that changes in visibility directly
      affect the filter's "activeness"; this binding can be controlled
      using the new gimp_item_bind_visible_to_active() function.
      This distinction is currently necessary for floating selections.
      Floating selection layers must not be active in their parent stack,
      regardless of their visibility, in particular, so that their mode
      node doesn't hide the entire backdrop when their composite mode
      excludes the backdrop (i.e., when it's dst-atop or src-in).
      Instead, their visibility should affect the activeness of the
      floating-selection filter of the drawable they're attached to.
      This is handled by the next commit.
    • Ell's avatar
      app: exclude invisible filters from filter-stack graph · e02cb6ad
      Ell authored
      Currently, when a GimpFilter's visibility changes, we rely on its
      various visibility-changed signal handlers to rewire the filter
      node's graph to reflect the change.  This has two main
        - There's no easy, generic way to toggle a filter's  effect,
          especially one that is not subclassed, since GimpFilter only
          takes care of the case where visibility becomes FALSE, and does
          nothing by itself when it becomes TRUE again.
        - While GimpDrawable does handle the visibility => TRUE case, it
          doesn't disconnect the filter's input from its mode and
          (potentially) source nodes when it becomes invisible.  As a
          result, while none of the drawable's graph is processed as part
          of the composition when not visible, the mode and source nodes
          do get invalidated when the filter's input is invalidated, such
          as while painting on a layer below the drawable.  This is
          particularly bad for pass-through groups, since their source
          node can be an arbitrarily complex graph, whose invlidation
          incurs a nontrivial overhead.
      Instead, don't touch the filter's node at all when visibility
      changes, and rather have GimpFilterStack remove it from the graph
      entirely when the filter becomes invisible, and re-add it once it
      becomes visible again.  This solves both of the above problems, as
      well as simplifies the code.
    • Ell's avatar
      app: restore operation src node in gimp_gegl_apply_[cached_]operation() · 73d7a81a
      Ell authored
      When merging a drawable filter, we call
      gimp_gegl_apply_cached_operation() on a node that's part of the
      drawable's filter stack graph.  The function rewires the node's
      input, and doesn't restore its original input connection before
      returning, leaving the graph in an inconsistent state.  Currently,
      this doesn't matter, since we remove the filter right after that,
      but the next commit expects the filter stack graph to remain
      Remember the original source node of "operation" in
      gimp_gegl_apply_cached_operation(), and restore it upon exit, to
      fix that.
    • Alexandre Prokoudine's avatar
    • l's avatar
      Update Spanish translation · 9f1e3de4
      l authored and Administrator's avatar Administrator committed
    • Marco Ciampa's avatar
      Updated Italian translation · 94a6ba90
      Marco Ciampa authored
    • Jehan's avatar
      app: migrate plug-in-gauss shortcuts to filters-gaussian-blur. · 5aa94284
      Jehan authored
      Since commit ff59aebb, blur-gauss plug-in and the associated
      "plug-in-gauss" action don't exist anymore. Migrate any custom shortcut
      to "filters-gaussian-blur", which is the expected replacement.
      See also bug 775931.
    • Jehan's avatar
      app: reorder alphabetically changed action paths in migration code. · 482b907c
      Jehan authored
      This allows for easier code reading and changing.
    • Jehan's avatar
      Bug 775931 - Shortcut for non-existing action shadows existing one. · 81d9da0c
      Jehan authored
      Current logics of dealing with duplicate accelerators was just to delete
      one randomly. This works ok in most case since we can't be in the head
      of people and can't know which one they want to keep (yet we can't keep
      both because that makes it very complicated to reset the shortcut
      appropriately by hand/GUI, without a tedious work of researching which
      other action uses the same shortcut. See commit 2a232398).
      There is still some cases where we can be a bit more clever than random
      deletion: when one of the accelerator is mapped to a non-existing
      action. In this case, let's delete this accelerator in priority. Not
      only the chances of this being the expected result are higher; but even
      worse, there is anyway no GUI way to delete the accelerator for the
      non-existing action! Thus you could try and reset your existing action's
      shortcut as many times as you want in the GUI, it would always end up
      deleted at next startup!
      Note that if the non-existing action's shortcut has no duplicate, it
      won't be deleted. This ensure that you could uninstall a plugin, then
      reinstall it later and still have your custom shortcuts saved in the
      meantime. A shortcut of a non-existing action will *only* be cleaned out
      if it is redundant with the shortcut of an existing action.
  2. 04 Dec, 2017 4 commits
    • Ell's avatar
      Bug 790810 - Nested layer groups lead to a deadlock with multithreading · 4e4c1cd5
      Ell authored
      Use gimp:buffer-source-validate, introduced in the previous commit,
      for the source node of GimpDrawables.  This avoids threading issues
      with layer groups, or any other drawables that may use a validating
      buffer, by making sure the buffer is validated before any
      succeeding operations, and hence the associated graph is processed
      on the same thread as the parent composition.
      Restore multithreaded processing in GimpOperationLayerMode.
    • Ell's avatar
      app: add gimp:buffer-source-validate operation · dec2375a
      Ell authored
      gimp:buffer-source-validate is a drop-in replacement for
      gegl:buffer-source, however, if the attached buffer has a
      validating tile-handler, it makes sure the required region is
      validated during process().  This avoids a situation in which
      validation happens in different worker threads at the same time
      during the processing of a succeeding operation; since validation
      is protected by the buffer's tile-storage mutex, this can result in
      either a deadlock (currently), or an effective fallback to single-
      threaded processing.
    • Ell's avatar
    • Ell's avatar
      configure.ac: require perl >= 5.10.0 · fd9cce57
      Ell authored
      Commit 4b521435 uses recursive
      regex patterns in gimp-mkenums, which requires perl >= 5.10.0.
  3. 03 Dec, 2017 2 commits
  4. 02 Dec, 2017 9 commits
  5. 01 Dec, 2017 11 commits
  6. 30 Nov, 2017 3 commits