1. 08 Jan, 2019 1 commit
    • Jehan's avatar
      app: push a temporary status when picking layer with alt-midclick. · 496bc02b
      Jehan authored
      Though the layer list will also show updated, it is much easier to look
      at the layer name in the status bar whose position never changes.
      Anyway it makes sense to just show a temporary status info message
      giving the picked layer name, making it all the easier to find the layer
      you are looking for.
  2. 07 Jan, 2019 1 commit
    • Jehan's avatar
      app: make layer picking a generic modifier of the shell. · 4c337353
      Jehan authored
      Instead of having layer picking only on paint tools with alt-click, make
      it available everywhere with alt-middle click. Moving through layers is
      also a way to navigate an image, so it actually makes sense to be with
      other modifiers (panning, zooming, rotating), while making the feature
      more generic (this is definitely useful whatever the selected tool).
  3. 29 Sep, 2018 2 commits
    • Ell's avatar
      app: avoid double-initialization of operation tools when changing layers · a2166782
      Ell authored
      When re-activating an operation tool by clicking on a different
      drawable while the tool is active, we re-call the corresponding
      procedure to re-activate the tool, which implictly initializes it.
      Avoid initializaing it explicitly in addition to that, since this
      leads to the creation of a new config object by the filter tool,
      while the GUI still refers to the old, now-dead, config object,
      causing CRITICALs or segfaults when changing any parameter.
    • Ell's avatar
      Issue #1180 - Warp tool aborts changes to layer A when ... · ed20393f
      Ell authored
      ... changing layers and warping layer B
      Add a new GimpToolControl::dirty_action field, which specifies the
      tool action to perform when the a dirty event matching the tool
      control's dirty mask occurs; this field defaults to HALT.  Apply
      this action to the active tool in tool-manager in response to a
      matching dirty event, instead of unconditionally halting the tool.
      Likewise, use this action to stop the active tool in response to a
      button-press event on a different drawable in the same image.
      Set the dirty action of the gradient and warp tools to COMMIT, so
      that they get comitted, rather than stopped, in cases such as
      switching layers (including switching to/from quick-mask mode),
      and, for the warp tool, changing the selection.
  4. 11 Jul, 2018 1 commit
  5. 03 Jul, 2018 1 commit
  6. 04 Jun, 2018 1 commit
  7. 20 May, 2018 7 commits
  8. 19 May, 2018 1 commit
    • Michael Natterer's avatar
      Bug 796252 - Mouse wheel zooming should center on cursor... · ef2cf21f
      Michael Natterer authored
      ... _even at low zoom levels_
      Pass GIMP_ZOOM_FOCUS_POINTER to gimp_display_shell_scale() when
      wheel-scrolling, and change the scaling code to really honor
      GIMP_ZOOM_FOCUS_POINTER and not apply magic image centering.
      This keep the same point centered under the mouse for wheel-scrolling
      and the zoom tool (== when the zooming is really triggered at a
      certain mouse position).
  9. 16 May, 2018 1 commit
    • Michael Natterer's avatar
      Bug 787919 - Tool options are lost when switching device · 2f629072
      Michael Natterer authored
      GimpDeviceInfo is the only way to store per-device settings like
      color, brush etc. It used to be derived from GimpContext and therefore
      limited to the context's properties, causing everything else (all
      tool-individual options) to be lost on device change.
      Derive it from GimpToolPreset instead, so it's capable of storing
      arbitrary tool options.
      Adapt things to the new class hierarchy and add a bunch of signal
      handlers that make sure the active device's GimpDeviceInfo is updated
      properly when the tool changes. Also change device switching
      Change GimpDeviceStatus to only show the stuff that is relevant to
      each device's tool.
      And various small changes to make things work properly...
  10. 14 Apr, 2018 1 commit
    • Jehan's avatar
      Bug 724692 - Canvas rotation stuck with specific order of actions. · 3ac79481
      Jehan authored
      Commit b279c2d2 was breaking a specific use case, which I oversaw:
      when space bar activates the move tool, you may want to release the
      space bar while mouse button is pressed, and expect to still be able to
      move the layer/selection/guide, but releasing space was stopping the
      move immediately. The move tool must only be deactivated when both space
      and button 1 are released, and the move itself must continue as long as
      button 1 is pressed (when started while space was pressed).
      As a nice side effect of this commit, panning and canvas rotation are
      also improved since now they can be continued while releasing space
      (respectively shift-space) if mouse button 1 was pressed, and up until
      the mouse button is released. Pressing space again, then releasing the
      mouse, back and forth, also work as expected (i.e. move tool stay
      activated though the move stops; and panning or rotation continue).
      Of course now we don't get anymore panning/rotation stuck while neither
      space nor mouse buttons are pressed (which was the original bug). At
      least one of these need to stay pressed for panning/rotation/move to
      stay activated. And initial activation is obviously always through
      (shift-)space only.
  11. 16 Mar, 2018 2 commits
    • Jehan's avatar
      app: return from gimp_display_shell_space_pressed() immediately when... · 8aaf77ba
      Jehan authored
      ... scrolling in progress.
      In particular, this could happen while panning with mouse middle click
      and hitting space. This space should simply be ignored.
    • Jehan's avatar
      Bug 724692 - Canvas rotation stuck with specific order of actions. · b279c2d2
      Jehan authored
      The bug was affecting actually both canvas rotation and panning when
      done with space key. If the first mouse button was also clicked, then
      released after the space key, we ended up in some stuck action. It could
      only be unstuck by hitting/releasing space again.
      I am actually unsure that this was not originally done on purpose,
      especially since the code has these 2 status variables space_pressed and
      space_release_pending, but really apart from looking at this code, the
      behavior just looks very buggy and impracticable.
      The new behavior is to just stop the canvas panning/rotation as soon as
      space is released (which is also how it is documented in our manual, and
      how everyone seems to use the feature). I only kept the variable
      space_release_pending, which I use as was used space_pressed before.
  12. 04 Jan, 2018 3 commits
  13. 11 Jun, 2017 2 commits
    • Ell's avatar
      app: fix event reordering during motion compression · b737463a
      Ell authored
      ... due to commit 5543a9da
    • Ell's avatar
      app: compress tool motion evnets more conservatively · 5543a9da
      Ell authored
      When compressing tool motion events, only compress motion events
      at the front of the event queue, targeted at the same widget as,
      and having similar characteristics to, the initial motion event;
      stop compressing upon the first mismatched event.
      Previously, all pending motion events targeted at the canvas were
      compressed, stopping only at a button-release event targeted at the
      canvas.  As a result, when adding a guide by dragging from a ruler,
      there could be a situation where a pending button-release event
      targeted at the ruler would be followed by motion events targeted at
      the canvas, with a cleared state mask.  These motion events would
      get compressed to the initial motion event targeted at the ruler,
      resulting in a motion event with a cleared state mask being processed
      before the said button-release event.  This, in turn, would cause the
      guide tool's cursor_update function to be called, while the tool is
      still active, emitting a CRITICAL.  Sheesh.
      The moral of the story is: let's play it safe.
  14. 11 May, 2017 1 commit
  15. 22 Jan, 2017 1 commit
    • Michael Natterer's avatar
      Bug 776370 - Changing active layer breaks the GEGL operation dialog · dba909a9
      Michael Natterer authored
      We can't just switch to a GimpOperationTool by using the normal
      gimp_context_set_tool() or gimp_context_tool_changed() because it
      needs additional initialization like setting an operation at all.
      In gimp_gegl_procedure_execute_async(), g_object_set_data() the used
      procedure on the newly created tool.
      In gimp_display_shell_initialize_tool(), when we re-create the active
      tool because of a drawable change, check for the procedure and invoke
      it again, instead of simply creating an empty operation tool by
      calling gimp_context_tool_changed().
  16. 16 Nov, 2016 1 commit
  17. 14 Oct, 2016 1 commit
    • Michael Natterer's avatar
      Bug 759939 - Ghost brush outline in FG Select tool · 151b44e4
      Michael Natterer authored
      Fix the check that keeps events on overlay widgets from entering the
      tool event mechanism, they have no business there.
      gimp_overlay_child_realize(): set the embedding widget's event mask on
      all overlay children, so their windows will be used as event window,
      so their events become distinguishable from events on the parent (the
      gimp_display_shell_canvas_tool_events(): fix the check for events on
      overlays, and skip them for real this time.
  18. 22 Sep, 2016 1 commit
  19. 15 Apr, 2016 1 commit
  20. 14 Apr, 2016 1 commit
    • Michael Natterer's avatar
      Bug 732160 - menu activation with alt-somekey makes tools stay... · 2a31b96f
      Michael Natterer authored
      ...in "alt-pressed" mode
      Menu activation doesn't cause a focus-out becaus menu keyboard
      grabbing is implemented with a simple gtk_grab_add() (the menu popup
      never gets the focus). Therefore, the canvas never gets a focus-out
      event and the pressed modifiers are stuck.
      Fixed by connecting to "grab-notify" on the canvas, and artificially
      releasing all modifiers when the canvas is shadowed by a grab.
  21. 03 Apr, 2016 1 commit
    • Michael Natterer's avatar
      Bug 668016 - Accidentally clicking ruler loses active tool's state · 7889ec08
      Michael Natterer authored
      Add two new tools, GimpGuideTool and GimpSamplePointTool. They are
      one-trick-ponies and can only create new or move existing guides and
      sample points. They can't be selected from the toolbox, only
      temporarily pushed as active tools on top of any active tool using
      their public start() APIs.
      Use that API to enable them when the rulers are clicked, and replace
      the entire guide and sample point moving code in GimpMoveTool and
      GimpColorTool by simple calls to that API.
      This might look like overkill but can easily be used for other
      features like moving guides from within the paint tools (mirror
      painting) or gegl filters (preview curtain).
  22. 28 Dec, 2015 2 commits
  23. 18 Apr, 2015 1 commit
  24. 09 Jan, 2015 1 commit
  25. 16 Nov, 2014 2 commits
  26. 10 Feb, 2014 1 commit
  27. 08 Jun, 2013 1 commit