dnrops
/
gimp
mirror of https://github.com/GNOME/gimp.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gimp/app/display/gimpdisplayshell-tool-events.c

2501 lines
90 KiB
C
Raw Normal View History

app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
Change the license URL from http://www.gnu.org/licenses/ to https://
2018-07-12 05:27:07 +08:00
* along with this program. If not, see <https://www.gnu.org/licenses/>.
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
*/
#include "config.h"
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
#include <math.h>
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include <gegl.h>
#include <gtk/gtk.h>
#include <gdk/gdkkeysyms.h>
app: Implement canvas support for touchpad gesture rotation by pinch
2022-03-17 05:59:20 +08:00
#include "libgimpmath/gimpmath.h"
Add gimp_button_event_triggers_context_menu() and use it instead of checking for event->button == 3, so context menus work correctly on the Mac. Didn't change the image menu yet because thet requires some more refactoring.
2011-09-19 06:45:36 +08:00
#include "libgimpwidgets/gimpwidgets.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "display-types.h"
#include "tools/tools-types.h"
#include "config/gimpdisplayconfig.h"
#include "core/gimp.h"
Bug 776370 - Changing active layer breaks the GEGL operation dialog 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().
2017-01-23 07:00:03 +08:00
#include "core/gimp-filter-history.h"
Bug 787919 - Tool options are lost when switching device 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 accordingly. Change GimpDeviceStatus to only show the stuff that is relevant to each device's tool. And various small changes to make things work properly...
2018-05-16 04:31:19 +08:00
#include "core/gimpcontext.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "core/gimpimage.h"
app: make layer picking a generic modifier of the shell. 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).
2018-12-23 02:09:34 +08:00
#include "core/gimpimage-pick-item.h"
Bug 776370 - Changing active layer breaks the GEGL operation dialog 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().
2017-01-23 07:00:03 +08:00
#include "core/gimpitem.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
#include "widgets/gimpaction.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "widgets/gimpcontrollers.h"
#include "widgets/gimpcontrollerkeyboard.h"
#include "widgets/gimpcontrollerwheel.h"
#include "widgets/gimpdeviceinfo.h"
#include "widgets/gimpdeviceinfo-coords.h"
app: GimpDeviceManager refactoring part two - change gimp_devices_get_list() to gimp_devices_get_manager() - remove gimp_devices_get_current() - let GimpDeviceStatus connect to the manager's "notify::current-device" directly and remove device status updating code from gui.c - cleanup in gimpdevices.c
2011-02-28 21:37:00 +08:00
#include "widgets/gimpdevicemanager.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "widgets/gimpdevices.h"
#include "widgets/gimpdialogfactory.h"
app: new double action "tools-mypaint-brush-pixel-size-set", used as… … new action_pixel_size of GimpMyBrushTool. MyPaint brush tool clearly shows the limits of my trick to have some enum actions work with absolute values whereas others work with per-mille values between the property min and max. Indeed firstly MyBrush's "radius" value is logarithmic and can be negative. Since the enum trick relies on the fact that negative values are the semantic enumerated constants, it's broken in such case. The second issue is that while it was acceptable to use int size for most paint tools (even though they were double), here radius only goes from -2.0 to 6.0; so using int values only would leave us with jumping brush sizes. So now I create a proper double action which simply takes pixel size and use this from the on-canvas brush size changing. No weird trick, no int or sign limitations. I also add a new optional action_pixel_size in GimpToolControl. Note: I'm also updating a bit the logic for the MyPaint brush outline function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit through mypaint-brush.c code in libmypaint, I am not sure at all we need to use the offset_by_random like this. And really this shown outline seems more indicative than anything else when I see the actual size printed by the various brushes. Finally here it was counter-productive as I needed to get easily the logarithmic radius from the pointer interaction on canvas.
2022-04-03 04:29:46 +08:00
#include "widgets/gimpdoubleaction.h"
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
#include "widgets/gimpenumaction.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "widgets/gimpuimanager.h"
app: forgot to #include "widgets/gimpwidgets-utils.h"
2011-02-24 23:54:39 +08:00
#include "widgets/gimpwidgets-utils.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 668016 - Accidentally clicking ruler loses active tool's state 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).
2016-04-03 22:27:41 +08:00
#include "tools/gimpguidetool.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "tools/gimpmovetool.h"
app: display the brush outline (or fallback or circle) when resizing. Bypass temporarily the "Show brush outline" settings when resizing on-canvas.
2022-03-15 02:15:43 +08:00
#include "tools/gimppainttool.h"
Bug 668016 - Accidentally clicking ruler loses active tool's state 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).
2016-04-03 22:27:41 +08:00
#include "tools/gimpsamplepointtool.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "tools/gimptoolcontrol.h"
#include "tools/tool_manager.h"
Bug 759939 - Ghost brush outline in FG Select tool 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 canvas). gimp_display_shell_canvas_tool_events(): fix the check for events on overlays, and skip them for real this time.
2016-10-15 04:08:02 +08:00
#include "gimpcanvas.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "gimpdisplay.h"
#include "gimpdisplayshell.h"
#include "gimpdisplayshell-autoscroll.h"
#include "gimpdisplayshell-cursor.h"
#include "gimpdisplayshell-grab.h"
#include "gimpdisplayshell-layer-select.h"
Bug 55367 - Rotated view of the canvas (view is rotated, not image contents) First version of display rotation, inspired by gimp-painter. The rotation always happens around the image's center. The only "UI" for rotating is currently shift+middle-drag and shift+space-drag. Control constrains the angle to 15 degrees and is currently the only way to go back to "no rotation".
2013-04-19 22:22:19 +08:00
#include "gimpdisplayshell-rotate.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "gimpdisplayshell-scale.h"
#include "gimpdisplayshell-scroll.h"
#include "gimpdisplayshell-tool-events.h"
#include "gimpdisplayshell-transform.h"
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
#include "gimpmodifiersmanager.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "gimpimagewindow.h"
app: add GimpMotionBuffer class to swallow all the event smoothing code This commit only adds the class and removes the members from GimpDisplayShell, so everything looks more ugly than before, but I wanted the member moving separate from any refactorings.
2011-04-18 00:53:42 +08:00
#include "gimpmotionbuffer.h"
app: push a temporary status when picking layer with alt-midclick. 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.
2019-01-09 07:11:37 +08:00
#include "gimpstatusbar.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: push a temporary status when picking layer with alt-midclick. 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.
2019-01-09 07:11:37 +08:00
#include "gimp-intl.h"
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
#include "gimp-log.h"
/* local function prototypes */
static GdkModifierType
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
gimp_display_shell_key_to_state (gint key);
app: use gdk_event_triggers_context_menu() for the image menu and clean up button event handling a bit.
2011-10-06 02:04:42 +08:00
static GdkModifierType
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
gimp_display_shell_button_to_state (gint button);
static void gimp_display_shell_proximity_in (GimpDisplayShell *shell);
static void gimp_display_shell_proximity_out (GimpDisplayShell *shell);
static gboolean gimp_display_shell_check_device (GimpDisplayShell *shell,
GdkEvent *event,
gboolean *device_changed);
static void gimp_display_shell_check_device_cursor (GimpDisplayShell *shell);
static void gimp_display_shell_start_scrolling (GimpDisplayShell *shell,
const GdkEvent *event,
GdkModifierType state,
gint x,
gint y);
static void gimp_display_shell_stop_scrolling (GimpDisplayShell *shell,
const GdkEvent *event);
static void gimp_display_shell_handle_scrolling (GimpDisplayShell *shell,
GdkModifierType state,
gint x,
gint y);
app: Implement canvas support for touchpad gesture rotation by pinch
2022-03-17 05:59:20 +08:00
static void gimp_display_shell_rotate_gesture_maybe_get_state (GtkGestureRotate *gesture,
GdkEventSequence *sequence,
guint *maybe_out_state);
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
static void gimp_display_shell_space_pressed (GimpDisplayShell *shell,
const GdkEvent *event);
static void gimp_display_shell_released (GimpDisplayShell *shell,
const GdkEvent *event,
const GimpCoords *image_coords);
static gboolean gimp_display_shell_tab_pressed (GimpDisplayShell *shell,
const GdkEventKey *event);
static void gimp_display_shell_update_focus (GimpDisplayShell *shell,
gboolean focus_in,
const GimpCoords *image_coords,
GdkModifierType state);
static void gimp_display_shell_update_cursor (GimpDisplayShell *shell,
const GimpCoords *display_coords,
const GimpCoords *image_coords,
GdkModifierType state,
gboolean update_software_cursor);
static gboolean gimp_display_shell_initialize_tool (GimpDisplayShell *shell,
const GimpCoords *image_coords,
GdkModifierType state);
static void gimp_display_shell_get_event_coords (GimpDisplayShell *shell,
const GdkEvent *event,
GimpCoords *display_coords,
GdkModifierType *state,
guint32 *time);
static void gimp_display_shell_untransform_event_coords (GimpDisplayShell *shell,
const GimpCoords *display_coords,
GimpCoords *image_coords,
gboolean *update_software_cursor);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
app: new double action "tools-mypaint-brush-pixel-size-set", used as… … new action_pixel_size of GimpMyBrushTool. MyPaint brush tool clearly shows the limits of my trick to have some enum actions work with absolute values whereas others work with per-mille values between the property min and max. Indeed firstly MyBrush's "radius" value is logarithmic and can be negative. Since the enum trick relies on the fact that negative values are the semantic enumerated constants, it's broken in such case. The second issue is that while it was acceptable to use int size for most paint tools (even though they were double), here radius only goes from -2.0 to 6.0; so using int values only would leave us with jumping brush sizes. So now I create a proper double action which simply takes pixel size and use this from the on-canvas brush size changing. No weird trick, no int or sign limitations. I also add a new optional action_pixel_size in GimpToolControl. Note: I'm also updating a bit the logic for the MyPaint brush outline function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit through mypaint-brush.c code in libmypaint, I am not sure at all we need to use the offset_by_random like this. And really this shown outline seems more indicative than anything else when I see the actual size printed by the various brushes. Finally here it was counter-productive as I needed to get easily the logarithmic radius from the pointer interaction on canvas.
2022-04-03 04:29:46 +08:00
static void gimp_display_shell_activate_action (GimpUIManager *manager,
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
const gchar *action_desc,
app: new double action "tools-mypaint-brush-pixel-size-set", used as… … new action_pixel_size of GimpMyBrushTool. MyPaint brush tool clearly shows the limits of my trick to have some enum actions work with absolute values whereas others work with per-mille values between the property min and max. Indeed firstly MyBrush's "radius" value is logarithmic and can be negative. Since the enum trick relies on the fact that negative values are the semantic enumerated constants, it's broken in such case. The second issue is that while it was acceptable to use int size for most paint tools (even though they were double), here radius only goes from -2.0 to 6.0; so using int values only would leave us with jumping brush sizes. So now I create a proper double action which simply takes pixel size and use this from the on-canvas brush size changing. No weird trick, no int or sign limitations. I also add a new optional action_pixel_size in GimpToolControl. Note: I'm also updating a bit the logic for the MyPaint brush outline function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit through mypaint-brush.c code in libmypaint, I am not sure at all we need to use the offset_by_random like this. And really this shown outline seems more indicative than anything else when I see the actual size printed by the various brushes. Finally here it was counter-productive as I needed to get easily the logarithmic radius from the pointer interaction on canvas.
2022-04-03 04:29:46 +08:00
GVariant *value);
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
static gboolean gimp_display_triggers_context_menu (const GdkEvent *event,
GimpDisplayShell *shell,
Gimp *gimp,
const GimpCoords *image_coords,
gboolean force);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
/* public functions */
gboolean
gimp_display_shell_events (GtkWidget *widget,
GdkEvent *event,
GimpDisplayShell *shell)
{
Gimp *gimp;
gboolean set_display = FALSE;
/* are we in destruction? */
if (! shell->display || ! gimp_display_get_shell (shell->display))
return TRUE;
gimp = gimp_display_get_gimp (shell->display);
switch (event->type)
{
case GDK_KEY_PRESS:
case GDK_KEY_RELEASE:
{
GdkEventKey *kevent = (GdkEventKey *) event;
if (gimp->busy)
return TRUE;
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
/* do not process most key events while BUTTON1 is down. We do this
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
* so tools keep the modifier state they were in when BUTTON1 was
* pressed and to prevent accelerators from being invoked.
*/
if (kevent->state & GDK_BUTTON1_MASK)
{
if (kevent->keyval == GDK_KEY_Shift_L ||
kevent->keyval == GDK_KEY_Shift_R ||
kevent->keyval == GDK_KEY_Control_L ||
kevent->keyval == GDK_KEY_Control_R ||
kevent->keyval == GDK_KEY_Alt_L ||
app: treat Meta_L and Meta_R as tool-relevant modifiers for the Mac, they are still unhandled by tools though.
2011-10-06 01:44:24 +08:00
kevent->keyval == GDK_KEY_Alt_R ||
kevent->keyval == GDK_KEY_Meta_L ||
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
kevent->keyval == GDK_KEY_Meta_R ||
kevent->keyval == GDK_KEY_space ||
kevent->keyval == GDK_KEY_KP_Space)
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
break;
}
return TRUE;
}
switch (kevent->keyval)
{
case GDK_KEY_Left: case GDK_KEY_Right:
case GDK_KEY_Up: case GDK_KEY_Down:
case GDK_KEY_space:
case GDK_KEY_KP_Space:
case GDK_KEY_Tab:
app: make sure overlay widgets are keyboard navigatable Tab key events are not handled by the widget itself, they are supposed to bubble up until they hit the generic keyboard navigation code that knows about the focus chain, therefore: gimp_display_shell_canvas_tool_events(): if an overlay widget is focussed, don't handle Tab events and toggle dock visibility. Instead, simply bail out with FALSE so the event reaches te keyboard navigation code. Also treat GDK_KEY_KP_Tab like GDK_KEY_Tab all over the place.
2013-06-08 21:27:14 +08:00
case GDK_KEY_KP_Tab:
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
case GDK_KEY_ISO_Left_Tab:
case GDK_KEY_Alt_L: case GDK_KEY_Alt_R:
case GDK_KEY_Shift_L: case GDK_KEY_Shift_R:
case GDK_KEY_Control_L: case GDK_KEY_Control_R:
app: treat Meta_L and Meta_R as tool-relevant modifiers for the Mac, they are still unhandled by tools though.
2011-10-06 01:44:24 +08:00
case GDK_KEY_Meta_L: case GDK_KEY_Meta_R:
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
case GDK_KEY_Return:
case GDK_KEY_KP_Enter:
case GDK_KEY_ISO_Enter:
case GDK_KEY_BackSpace:
case GDK_KEY_Escape:
break;
default:
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
if (shell->space_release_pending ||
shell->button1_release_pending ||
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
shell->mod_action != GIMP_MODIFIER_ACTION_NONE)
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
return TRUE;
break;
}
set_display = TRUE;
break;
}
case GDK_BUTTON_PRESS:
case GDK_SCROLL:
set_display = TRUE;
break;
case GDK_FOCUS_CHANGE:
{
GdkEventFocus *fevent = (GdkEventFocus *) event;
if (fevent->in && shell->display->config->activate_on_focus)
set_display = TRUE;
}
break;
default:
break;
}
/* Setting the context's display automatically sets the image, too */
if (set_display)
gimp_context_set_display (gimp_get_user_context (gimp), shell->display);
return FALSE;
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
static gboolean
gimp_display_shell_canvas_no_image_events (GtkWidget *canvas,
GdkEvent *event,
GimpDisplayShell *shell)
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
switch (event->type)
{
display - run the file-open command when double-clicking in an empty shell.
2012-12-01 21:26:36 +08:00
case GDK_2BUTTON_PRESS:
{
GdkEventButton *bevent = (GdkEventButton *) event;
if (bevent->button == 1)
{
GimpImageWindow *window = gimp_display_shell_get_window (shell);
GimpUIManager *manager = gimp_image_window_get_ui_manager (window);
gimp_ui_manager_activate_action (manager, "file", "file-open");
}
return TRUE;
}
break;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_BUTTON_PRESS:
app: reduce nesting in gimp_display_shell_canvas_no_image_events()
2011-12-16 05:35:44 +08:00
if (gdk_event_triggers_context_menu (event))
{
app: gimp_ui_manager_ui_popup_at_pointer() and use it where appropriate Only one call to gimp_ui_manager_ui_popup() left...
2018-05-02 18:19:32 +08:00
gimp_ui_manager_ui_popup_at_pointer (shell->popup_manager,
"/dummy-menubar/image-popup",
(GdkEvent *) event,
NULL, NULL);
app: reduce nesting in gimp_display_shell_canvas_no_image_events()
2011-12-16 05:35:44 +08:00
return TRUE;
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
break;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_KEY_PRESS:
{
GdkEventKey *kevent = (GdkEventKey *) event;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: make sure overlay widgets are keyboard navigatable Tab key events are not handled by the widget itself, they are supposed to bubble up until they hit the generic keyboard navigation code that knows about the focus chain, therefore: gimp_display_shell_canvas_tool_events(): if an overlay widget is focussed, don't handle Tab events and toggle dock visibility. Instead, simply bail out with FALSE so the event reaches te keyboard navigation code. Also treat GDK_KEY_KP_Tab like GDK_KEY_Tab all over the place.
2013-06-08 21:27:14 +08:00
if (kevent->keyval == GDK_KEY_Tab ||
kevent->keyval == GDK_KEY_KP_Tab ||
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
kevent->keyval == GDK_KEY_ISO_Left_Tab)
{
app: gimpdisplayshell-tool-events.c: move Tab handling to a utility function instead of having separate utility functions for the different functions triggered by various Tab combinations.
2011-05-31 15:24:14 +08:00
return gimp_display_shell_tab_pressed (shell, kevent);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
}
break;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
default:
break;
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
return FALSE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
gboolean
gimp_display_shell_canvas_tool_events (GtkWidget *canvas,
GdkEvent *event,
GimpDisplayShell *shell)
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
GimpDisplay *display;
GimpImage *image;
Gimp *gimp;
GimpModifiersManager *mod_manager;
GimpCoords display_coords;
GimpCoords image_coords;
GdkModifierType state;
guint32 time;
gboolean device_changed = FALSE;
gboolean return_val = FALSE;
gboolean update_sw_cursor = FALSE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
g_return_val_if_fail (gtk_widget_get_realized (canvas), FALSE);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
/* are we in destruction? */
if (! shell->display || ! gimp_display_get_shell (shell->display))
return TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
/* set the active display before doing any other canvas event processing */
if (gimp_display_shell_events (canvas, event, shell))
return TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 759939 - Ghost brush outline in FG Select tool 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 canvas). gimp_display_shell_canvas_tool_events(): fix the check for events on overlays, and skip them for real this time.
2016-10-15 04:08:02 +08:00
/* events on overlays have a different window, but these windows'
* user_data can still be the canvas, we need to check manually if
* the event's window and the canvas' window are different.
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
*/
Bug 759939 - Ghost brush outline in FG Select tool 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 canvas). gimp_display_shell_canvas_tool_events(): fix the check for events on overlays, and skip them for real this time.
2016-10-15 04:08:02 +08:00
if (event->any.window != gtk_widget_get_window (canvas))
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
{
Bug 759939 - Ghost brush outline in FG Select tool 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 canvas). gimp_display_shell_canvas_tool_events(): fix the check for events on overlays, and skip them for real this time.
2016-10-15 04:08:02 +08:00
GtkWidget *event_widget;
gdk_window_get_user_data (event->any.window, (gpointer) &event_widget);
/* if the event came from a different window than the canvas',
* check if it came from a canvas child and bail out.
*/
if (gtk_widget_get_ancestor (event_widget, GIMP_TYPE_CANVAS))
return FALSE;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
display = shell->display;
gimp = gimp_display_get_gimp (display);
image = gimp_display_get_image (display);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
if (! image)
return gimp_display_shell_canvas_no_image_events (canvas, event, shell);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: replace a wrong G_LIKELY() by G_UNLIKELY() in tool_events()
2011-02-27 18:08:36 +08:00
GIMP_LOG (TOOL_EVENTS, "event (display %p): %s",
display, gimp_print_event (event));
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
if (gimp_display_shell_check_device (shell, event, &device_changed))
return TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
gimp_display_shell_get_event_coords (shell, event,
&display_coords,
&state, &time);
gimp_display_shell_untransform_event_coords (shell,
&display_coords, &image_coords,
&update_sw_cursor);
/* If the device (and maybe the tool) has changed, update the new
* tool's state
*/
if (device_changed && gtk_widget_has_focus (canvas))
{
app: add "gboolean focus_in" to gimp_display_shell_update_focus() and use it to update the tool's state also when the canvas gets a FOCUS_OUT.
2011-04-04 01:01:13 +08:00
gimp_display_shell_update_focus (shell, TRUE,
&image_coords, state);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
mod_manager = GIMP_MODIFIERS_MANAGER (shell->display->config->modifiers_manager);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
switch (event->type)
{
case GDK_ENTER_NOTIFY:
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
GdkEventCrossing *cevent = (GdkEventCrossing *) event;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
if (cevent->mode != GDK_CROSSING_NORMAL)
return TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
/* ignore enter notify while we have a grab */
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
if (shell->grab_pointer)
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
return TRUE;
app: redo the last commit and call proximity_in() at all logical places Keep the comment at the place where calling it isn't immediately obvious, and add checks to proximity_in() and out() so they bail out when the proximity state is already set correctly.
2011-02-27 19:16:51 +08:00
gimp_display_shell_proximity_in (shell);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
update_sw_cursor = TRUE;
tool_manager_oper_update_active (gimp,
&image_coords, state,
shell->proximity,
display);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
break;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_LEAVE_NOTIFY:
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
GdkEventCrossing *cevent = (GdkEventCrossing *) event;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
if (cevent->mode != GDK_CROSSING_NORMAL)
return TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
/* ignore leave notify while we have a grab */
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
if (shell->grab_pointer)
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
return TRUE;
app: add utility functions proximity_in() and proximity_out() and use them instead of manually setting proximity. Also add comments about why we call the proximity functions where we call them (instead of calling them where it seems more logical).
2011-02-27 19:08:09 +08:00
gimp_display_shell_proximity_out (shell);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
tool_manager_oper_update_active (gimp,
&image_coords, state,
shell->proximity,
display);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
break;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_PROXIMITY_IN:
app: redo the last commit and call proximity_in() at all logical places Keep the comment at the place where calling it isn't immediately obvious, and add checks to proximity_in() and out() so they bail out when the proximity state is already set correctly.
2011-02-27 19:16:51 +08:00
gimp_display_shell_proximity_in (shell);
app: add utility functions proximity_in() and proximity_out() and use them instead of manually setting proximity. Also add comments about why we call the proximity functions where we call them (instead of calling them where it seems more logical).
2011-02-27 19:08:09 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
tool_manager_oper_update_active (gimp,
&image_coords, state,
shell->proximity,
display);
break;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_PROXIMITY_OUT:
app: add utility functions proximity_in() and proximity_out() and use them instead of manually setting proximity. Also add comments about why we call the proximity functions where we call them (instead of calling them where it seems more logical).
2011-02-27 19:08:09 +08:00
gimp_display_shell_proximity_out (shell);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
tool_manager_oper_update_active (gimp,
&image_coords, state,
shell->proximity,
display);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
break;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_FOCUS_CHANGE:
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
GdkEventFocus *fevent = (GdkEventFocus *) event;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
if (fevent->in)
{
if (G_UNLIKELY (! gtk_widget_has_focus (canvas)))
g_warning ("%s: FOCUS_IN but canvas has no focus", G_STRFUNC);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
/* ignore focus changes while we have a grab */
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
if (shell->grab_pointer)
app: completely ignore focus change events while we have a grab in order to be safe against whatever windowing system / event manager depending event order. Also properly update the tool's state after a button reelease, and after a space release.
2011-04-07 03:35:29 +08:00
return TRUE;
/* press modifier keys when the canvas gets the focus */
gimp_display_shell_update_focus (shell, TRUE,
&image_coords, state);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
else
{
app: replace a wrong G_LIKELY() by G_UNLIKELY() in tool_events()
2011-02-27 18:08:36 +08:00
if (G_UNLIKELY (gtk_widget_has_focus (canvas)))
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
g_warning ("%s: FOCUS_OUT but canvas has focus", G_STRFUNC);
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
/* ignore focus changes while we have a grab */
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
if (shell->grab_pointer)
app: completely ignore focus change events while we have a grab in order to be safe against whatever windowing system / event manager depending event order. Also properly update the tool's state after a button reelease, and after a space release.
2011-04-07 03:35:29 +08:00
return TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
/* release modifier keys when the canvas loses the focus */
app: add "gboolean focus_in" to gimp_display_shell_update_focus() and use it to update the tool's state also when the canvas gets a FOCUS_OUT.
2011-04-04 01:01:13 +08:00
gimp_display_shell_update_focus (shell, FALSE,
&image_coords, 0);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
}
break;
case GDK_BUTTON_PRESS:
{
Bug 686521 - Zoom Tool Displays Wrong Cursor When Zooming In/Out When updating the tool cursor on BUTTON_PRESS, pass a state *without* the newly pressed button's mask to gimp_display_shell_update_cursor(), or it will simply never call the cursor update function. Tool cursors don't normally change when a mouse button is down.
2012-11-07 05:46:47 +08:00
GdkEventButton *bevent = (GdkEventButton *) event;
GdkModifierType button_state;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: ignore new button events on the canvas while another button is down Fixes tons of possibly dangerous warnings, and likely some weird crashes.
2011-12-10 03:53:11 +08:00
/* ignore new mouse events */
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
if (gimp->busy ||
shell->mod_action != GIMP_MODIFIER_ACTION_NONE ||
shell->grab_pointer ||
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
shell->button1_release_pending)
app: ignore new button events on the canvas while another button is down Fixes tons of possibly dangerous warnings, and likely some weird crashes.
2011-12-10 03:53:11 +08:00
return TRUE;
Bug 686521 - Zoom Tool Displays Wrong Cursor When Zooming In/Out When updating the tool cursor on BUTTON_PRESS, pass a state *without* the newly pressed button's mask to gimp_display_shell_update_cursor(), or it will simply never call the cursor update function. Tool cursors don't normally change when a mouse button is down.
2012-11-07 05:46:47 +08:00
button_state = gimp_display_shell_button_to_state (bevent->button);
state |= button_state;
app: improve ignoring other buttons while one down
2011-12-10 05:26:22 +08:00
app: ignore new button events on the canvas while another button is down Fixes tons of possibly dangerous warnings, and likely some weird crashes.
2011-12-10 03:53:11 +08:00
/* ignore new buttons while another button is down */
app: merge if() madness into one single even bigger madness
2011-12-10 05:34:44 +08:00
if (((state & (GDK_BUTTON1_MASK)) && (state & (GDK_BUTTON2_MASK |
GDK_BUTTON3_MASK))) ||
((state & (GDK_BUTTON2_MASK)) && (state & (GDK_BUTTON1_MASK |
GDK_BUTTON3_MASK))) ||
((state & (GDK_BUTTON3_MASK)) && (state & (GDK_BUTTON1_MASK |
GDK_BUTTON2_MASK))))
app: ignore new button events on the canvas while another button is down Fixes tons of possibly dangerous warnings, and likely some weird crashes.
2011-12-10 03:53:11 +08:00
return TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
/* focus the widget if it isn't; if the toplevel window
* already has focus, this will generate a FOCUS_IN on the
* canvas immediately, therefore we do this before logging
* the BUTTON_PRESS.
*/
if (! gtk_widget_has_focus (canvas))
gtk_widget_grab_focus (canvas);
/* if the toplevel window didn't have focus, the above
* gtk_widget_grab_focus() didn't set the canvas' HAS_FOCUS
app: remove the hackish "button_press_before_focus" from GimpDisplayShell and simply *always* set the tool to the right state before sending it a button_press. GimpTool's state setting functions are now smart enough to simply ignore setting the same state again. When recieving a FOCUS_IN, skip state setting when the pointer is grabbed, which is a safe indicator for tool interaction going on. This hopefully fixes states for both click-to-focus and focus-follows-mouse *and* fixes the previously warning case where a new image was opened into an already focussed canvas (the warning then happened on button press, and the tool was in an inconsistent state).
2011-04-04 00:42:50 +08:00
* flags, and didn't trigger a FOCUS_IN, but the tool needs
* to be set up correctly regardless, so simply do the
* same things here, it's safe to do them redundantly.
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
*/
app: add "gboolean focus_in" to gimp_display_shell_update_focus() and use it to update the tool's state also when the canvas gets a FOCUS_OUT.
2011-04-04 01:01:13 +08:00
gimp_display_shell_update_focus (shell, TRUE,
&image_coords, state);
app: remove the hackish "button_press_before_focus" from GimpDisplayShell and simply *always* set the tool to the right state before sending it a button_press. GimpTool's state setting functions are now smart enough to simply ignore setting the same state again. When recieving a FOCUS_IN, skip state setting when the pointer is grabbed, which is a safe indicator for tool interaction going on. This hopefully fixes states for both click-to-focus and focus-follows-mouse *and* fixes the previously warning case where a new image was opened into an already focussed canvas (the warning then happened on button press, and the tool was in an inconsistent state).
2011-04-04 00:42:50 +08:00
gimp_display_shell_update_cursor (shell, &display_coords,
Bug 686521 - Zoom Tool Displays Wrong Cursor When Zooming In/Out When updating the tool cursor on BUTTON_PRESS, pass a state *without* the newly pressed button's mask to gimp_display_shell_update_cursor(), or it will simply never call the cursor update function. Tool cursors don't normally change when a mouse button is down.
2012-11-07 05:46:47 +08:00
&image_coords, state & ~button_state,
FALSE);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
if (bevent->button == 1)
app: use gdk_event_triggers_context_menu() for the image menu and clean up button event handling a bit.
2011-10-06 02:04:42 +08:00
{
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
if (! gimp_display_shell_pointer_grab (shell, event,
GDK_POINTER_MOTION_MASK |
GDK_BUTTON_RELEASE_MASK))
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
return TRUE;
app: add gimp_display_shell_initialize_tool() in tool-events.c so another big block of logic is gone from "the huge function".
2011-04-04 00:27:03 +08:00
if (gimp_display_shell_initialize_tool (shell,
&image_coords, state))
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
GimpTool *active_tool;
GimpMotionMode motion_mode;
GimpCoords last_motion;
active_tool = tool_manager_get_active (gimp);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
motion_mode = gimp_tool_control_get_motion_mode (active_tool->control);
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
if (motion_mode == GIMP_MOTION_MODE_EXACT)
{
/* enable motion compression for the canvas window for the
* duration of the stroke
*/
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
gdk_window_set_event_compression (gtk_widget_get_window (canvas), FALSE);
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
}
app: add start_stroke() and finish_stroke() API to GimpMotionBuffer where finish_stroke() is the former flush_event_queue() and start_stroke() is used in BUTTON_PRESS instead of poking into the motion buffer's internals. Also, call finish_stroke() also when the tool is not active, so the event buffer is flushed (the "motion" callback will ignore the events if the tool is not active).
2011-04-18 06:29:32 +08:00
app: add the point of code removed in previous commit back in
2015-12-29 05:04:13 +08:00
/* Use the last evaluated velocity&direction instead of the
app: add gimp_display_shell_initialize_tool() in tool-events.c so another big block of logic is gone from "the huge function".
2011-04-04 00:27:03 +08:00
* button_press event's ones because the click is
* usually at the same spot as the last motion event
app: add the point of code removed in previous commit back in
2015-12-29 05:04:13 +08:00
* which would give us bogus derivate dynamics.
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
*/
app: GimpMotionBuffer API cleanup and refactoring - start_stroke()/finih_stroke() -> begin_stroke()/end_stroke() - process_event_queue() -> process_stroke() - GimpMotionBuffer::motion() -> GimpMotionBuffer::stroke() - add GimpMotionBuffer::hover() and process_hover() - remove push_event_history() and pop_event_queue() from API The thing works like this: - Motion events are continuously fed into the buffer using motion_event() - begin_stroke()/end_stroke() correspond to BUTTON_PRESS/BUTTON_RELEASE, the period between them is a "stroke" - If motion_event() returns TRUE, we request "stroke" signals by calling process_stroke() and "hover" signals by calling process_hover()
2011-04-18 17:08:24 +08:00
gimp_motion_buffer_begin_stroke (shell->motion_buffer, time,
app: add start_stroke() and finish_stroke() API to GimpMotionBuffer where finish_stroke() is the former flush_event_queue() and start_stroke() is used in BUTTON_PRESS instead of poking into the motion buffer's internals. Also, call finish_stroke() also when the tool is not active, so the event buffer is flushed (the "motion" callback will ignore the events if the tool is not active).
2011-04-18 06:29:32 +08:00
&last_motion);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: add the point of code removed in previous commit back in
2015-12-29 05:04:13 +08:00
image_coords.velocity = last_motion.velocity;
image_coords.direction = last_motion.direction;
app: add gimp_display_shell_initialize_tool() in tool-events.c so another big block of logic is gone from "the huge function".
2011-04-04 00:27:03 +08:00
tool_manager_button_press_active (gimp,
&image_coords,
time, state,
GIMP_BUTTON_PRESS_NORMAL,
display);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
app: use gdk_event_triggers_context_menu() for the image menu and clean up button event handling a bit.
2011-10-06 02:04:42 +08:00
}
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
else
app: use gdk_event_triggers_context_menu() for the image menu and clean up button event handling a bit.
2011-10-06 02:04:42 +08:00
{
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
GdkDevice *device;
GimpModifierAction action;
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
const gchar *action_desc = NULL;
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
device = gdk_event_get_source_device (event);
action = gimp_modifiers_manager_get_action (mod_manager, device,
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
bevent->button, bevent->state,
&action_desc);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
shell->mod_action = action;
switch (action)
{
case GIMP_MODIFIER_ACTION_MENU:
gimp_display_triggers_context_menu (event, shell, gimp, &image_coords, TRUE);
break;
case GIMP_MODIFIER_ACTION_PANNING:
case GIMP_MODIFIER_ACTION_ZOOMING:
case GIMP_MODIFIER_ACTION_ROTATING:
case GIMP_MODIFIER_ACTION_STEP_ROTATING:
case GIMP_MODIFIER_ACTION_LAYER_PICKING:
case GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE:
app: new modifier action to set brush size diameter. Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the brush size on-canvas, starting from center to border. The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size from one border to another.
2022-08-12 06:18:22 +08:00
case GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE:
app: add a modifier action for opacity change. Opacity and brush size are among the 2 most common tool options which people might want to often change, though we should likely later add all other common types of tool settings angle, aspect ratio, spacing, etc. I am also unsure using the enum action is the right call because what it does is just taking into account the distance from initial click to compute an opacity. Instead it might be more interesting to increase or decrease slowly or rapidly by going right or left from the initial click. We'll see. But it's a first step.
2022-08-17 22:46:26 +08:00
case GIMP_MODIFIER_ACTION_TOOL_OPACITY:
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
gimp_display_shell_start_scrolling (shell, event, state,
bevent->x, bevent->y);
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
break;
case GIMP_MODIFIER_ACTION_ACTION:
app: properly release shell scrolling on button release. If we released first the modifiers, then the pointer button during scrolling, we could end up blocked on scrolling. This makes sure the button release is the finale scroll unlock, allowing modifiers to be only used for starting the scroll. It also fixes activating custom actions, by storing the action description from the initial modifiers at press time, not release time.
2022-08-21 23:38:04 +08:00
shell->mod_action_desc = g_strdup (action_desc);
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
break;
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
case GIMP_MODIFIER_ACTION_NONE:
gimp_display_triggers_context_menu (event, shell, gimp, &image_coords, FALSE);
break;
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
return_val = TRUE;
}
break;
case GDK_2BUTTON_PRESS:
{
GdkEventButton *bevent = (GdkEventButton *) event;
GimpTool *active_tool;
if (gimp->busy)
return TRUE;
active_tool = tool_manager_get_active (gimp);
if (bevent->button == 1 &&
active_tool &&
gimp_tool_control_is_active (active_tool->control) &&
gimp_tool_control_get_wants_double_click (active_tool->control))
{
tool_manager_button_press_active (gimp,
&image_coords,
time, state,
GIMP_BUTTON_PRESS_DOUBLE,
display);
}
app: return TRUE after handling double and triple click tool events so we don't redundantly update the cursor again.
2011-03-31 16:21:55 +08:00
/* don't update the cursor again on double click */
return TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
break;
case GDK_3BUTTON_PRESS:
{
GdkEventButton *bevent = (GdkEventButton *) event;
GimpTool *active_tool;
if (gimp->busy)
return TRUE;
active_tool = tool_manager_get_active (gimp);
if (bevent->button == 1 &&
active_tool &&
gimp_tool_control_is_active (active_tool->control) &&
gimp_tool_control_get_wants_triple_click (active_tool->control))
{
tool_manager_button_press_active (gimp,
&image_coords,
time, state,
GIMP_BUTTON_PRESS_TRIPLE,
display);
}
app: return TRUE after handling double and triple click tool events so we don't redundantly update the cursor again.
2011-03-31 16:21:55 +08:00
/* don't update the cursor again on triple click */
return TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
break;
case GDK_BUTTON_RELEASE:
{
GdkEventButton *bevent = (GdkEventButton *) event;
GimpTool *active_tool;
gimp_display_shell_autoscroll_stop (shell);
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
if (bevent->button == 1 && shell->button1_release_pending)
{
gimp_display_shell_released (shell, event, NULL);
return TRUE;
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
if (gimp->busy)
return TRUE;
active_tool = tool_manager_get_active (gimp);
Bug 732160 - menu activation with alt-somekey makes tools stay... ...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.
2016-04-15 07:17:00 +08:00
state &= ~gimp_display_shell_button_to_state (bevent->button);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: use gdk_event_triggers_context_menu() for the image menu and clean up button event handling a bit.
2011-10-06 02:04:42 +08:00
if (bevent->button == 1)
{
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
/* If we don't have a grab, this is a release paired with
* a button press we intentionally ignored because we had
* a grab on another device at the time of the press
*/
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
if (! shell->grab_pointer || shell->mod_action != GIMP_MODIFIER_ACTION_NONE)
app: ignore button releases while another button's action is going on - ignore button 1 release if we are button-2-scrolling - ignore button 2 release if we are not button-2-scrolling
2011-04-07 04:30:44 +08:00
return TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
if (active_tool &&
(! gimp_image_is_empty (image) ||
gimp_tool_control_get_handle_empty_image (active_tool->control)))
{
app: GimpMotionBuffer API cleanup and refactoring - start_stroke()/finih_stroke() -> begin_stroke()/end_stroke() - process_event_queue() -> process_stroke() - GimpMotionBuffer::motion() -> GimpMotionBuffer::stroke() - add GimpMotionBuffer::hover() and process_hover() - remove push_event_history() and pop_event_queue() from API The thing works like this: - Motion events are continuously fed into the buffer using motion_event() - begin_stroke()/end_stroke() correspond to BUTTON_PRESS/BUTTON_RELEASE, the period between them is a "stroke" - If motion_event() returns TRUE, we request "stroke" signals by calling process_stroke() and "hover" signals by calling process_hover()
2011-04-18 17:08:24 +08:00
gimp_motion_buffer_end_stroke (shell->motion_buffer);
app: add start_stroke() and finish_stroke() API to GimpMotionBuffer where finish_stroke() is the former flush_event_queue() and start_stroke() is used in BUTTON_PRESS instead of poking into the motion buffer's internals. Also, call finish_stroke() also when the tool is not active, so the event buffer is flushed (the "motion" callback will ignore the events if the tool is not active).
2011-04-18 06:29:32 +08:00
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
gdk_window_set_event_compression (
gtk_widget_get_window (canvas), TRUE);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
if (gimp_tool_control_is_active (active_tool->control))
{
tool_manager_button_release_active (gimp,
&image_coords,
time, state,
display);
}
}
/* update the tool's modifier state because it didn't get
* key events while BUTTON1 was down
*/
app: completely ignore focus change events while we have a grab in order to be safe against whatever windowing system / event manager depending event order. Also properly update the tool's state after a button reelease, and after a space release.
2011-04-07 03:35:29 +08:00
if (gtk_widget_has_focus (canvas))
gimp_display_shell_update_focus (shell, TRUE,
&image_coords, state);
else
gimp_display_shell_update_focus (shell, FALSE,
&image_coords, 0);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
gimp_display_shell_pointer_ungrab (shell, event);
app: use gdk_event_triggers_context_menu() for the image menu and clean up button event handling a bit.
2011-10-06 02:04:42 +08:00
}
else
{
app: properly release shell scrolling on button release. If we released first the modifiers, then the pointer button during scrolling, we could end up blocked on scrolling. This makes sure the button release is the finale scroll unlock, allowing modifiers to be only used for starting the scroll. It also fixes activating custom actions, by storing the action description from the initial modifiers at press time, not release time.
2022-08-21 23:38:04 +08:00
GimpImageWindow *window;
GimpUIManager *manager;
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
window = gimp_display_shell_get_window (shell);
manager = gimp_image_window_get_ui_manager (window);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
app: properly release shell scrolling on button release. If we released first the modifiers, then the pointer button during scrolling, we could end up blocked on scrolling. This makes sure the button release is the finale scroll unlock, allowing modifiers to be only used for starting the scroll. It also fixes activating custom actions, by storing the action description from the initial modifiers at press time, not release time.
2022-08-21 23:38:04 +08:00
switch (shell->mod_action)
app: minor formatting cleanup in gimpdisplayshell-tool-events.c
2015-04-18 14:40:31 +08:00
{
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
case GIMP_MODIFIER_ACTION_MENU:
break;
case GIMP_MODIFIER_ACTION_PANNING:
case GIMP_MODIFIER_ACTION_ZOOMING:
case GIMP_MODIFIER_ACTION_ROTATING:
case GIMP_MODIFIER_ACTION_STEP_ROTATING:
case GIMP_MODIFIER_ACTION_LAYER_PICKING:
if (shell->mod_action != GIMP_MODIFIER_ACTION_NONE &&
! shell->button1_release_pending &&
(! shell->space_release_pending ||
shell->display->config->space_bar_action != GIMP_SPACE_BAR_ACTION_PAN))
gimp_display_shell_stop_scrolling (shell, event);
break;
case GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE:
app: new modifier action to set brush size diameter. Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the brush size on-canvas, starting from center to border. The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size from one border to another.
2022-08-12 06:18:22 +08:00
case GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE:
app: add a modifier action for opacity change. Opacity and brush size are among the 2 most common tool options which people might want to often change, though we should likely later add all other common types of tool settings angle, aspect ratio, spacing, etc. I am also unsure using the enum action is the right call because what it does is just taking into account the distance from initial click to compute an opacity. Instead it might be more interesting to increase or decrease slowly or rapidly by going right or left from the initial click. We'll see. But it's a first step.
2022-08-17 22:46:26 +08:00
case GIMP_MODIFIER_ACTION_TOOL_OPACITY:
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
gimp_display_shell_stop_scrolling (shell, event);
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
break;
case GIMP_MODIFIER_ACTION_ACTION:
app: properly release shell scrolling on button release. If we released first the modifiers, then the pointer button during scrolling, we could end up blocked on scrolling. This makes sure the button release is the finale scroll unlock, allowing modifiers to be only used for starting the scroll. It also fixes activating custom actions, by storing the action description from the initial modifiers at press time, not release time.
2022-08-21 23:38:04 +08:00
gimp_display_shell_activate_action (manager, shell->mod_action_desc, NULL);
g_clear_pointer (&shell->mod_action_desc, g_free);
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
break;
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
case GIMP_MODIFIER_ACTION_NONE:
break;
app: minor formatting cleanup in gimpdisplayshell-tool-events.c
2015-04-18 14:40:31 +08:00
}
app: properly release shell scrolling on button release. If we released first the modifiers, then the pointer button during scrolling, we could end up blocked on scrolling. This makes sure the button release is the finale scroll unlock, allowing modifiers to be only used for starting the scroll. It also fixes activating custom actions, by storing the action description from the initial modifiers at press time, not release time.
2022-08-21 23:38:04 +08:00
shell->mod_action = GIMP_MODIFIER_ACTION_NONE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
return_val = TRUE;
}
break;
case GDK_SCROLL:
{
app: minor formatting cleanup in gimpdisplayshell-tool-events.c
2015-04-18 14:40:31 +08:00
GdkEventScroll *sevent = (GdkEventScroll *) event;
GimpController *wheel = gimp_controllers_get_wheel (gimp);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: update the tool's state after the wheel controller has handled the event
2011-04-07 04:50:20 +08:00
if (! wheel ||
! gimp_controller_wheel_scroll (GIMP_CONTROLLER_WHEEL (wheel),
sevent))
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: use toggle_behavior_mask not CONTROL to trigger zoom-on-scroll
2011-10-07 05:59:49 +08:00
if (state & gimp_get_toggle_behavior_mask ())
app: update the tool's state after the wheel controller has handled the event
2011-04-07 04:50:20 +08:00
{
Enable and fix smooth scrolling and zooming - Fix gimp_scroll_adjustment_values() for smooth scroll events - Set GDK_SMOOTH_SCROLL_MASK on all widgets where we set GDK_SCROLL_MASK - Add GIMP_ZOOM_SMOOTH to enum GimpZoomType - Add "gdouble delta" to gimp_zoom_model_step() - Change the meaning of the "scale" parameter to "scale or delta" in all functions that take GimpZoomType and a scale factor.
2018-05-11 08:08:51 +08:00
gdouble delta;
app: use gimp_scroll_adjustment_values() for scrolling the canvas
2018-05-11 05:33:35 +08:00
switch (sevent->direction)
app: update the tool's state after the wheel controller has handled the event
2011-04-07 04:50:20 +08:00
{
case GDK_SCROLL_UP:
gimp_display_shell_scale (shell,
GIMP_ZOOM_IN,
0.0,
Bug 796252 - Mouse wheel zooming should center on cursor... ... _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).
2018-05-19 20:31:01 +08:00
GIMP_ZOOM_FOCUS_POINTER);
app: update the tool's state after the wheel controller has handled the event
2011-04-07 04:50:20 +08:00
break;
case GDK_SCROLL_DOWN:
gimp_display_shell_scale (shell,
GIMP_ZOOM_OUT,
0.0,
Bug 796252 - Mouse wheel zooming should center on cursor... ... _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).
2018-05-19 20:31:01 +08:00
GIMP_ZOOM_FOCUS_POINTER);
Enable and fix smooth scrolling and zooming - Fix gimp_scroll_adjustment_values() for smooth scroll events - Set GDK_SMOOTH_SCROLL_MASK on all widgets where we set GDK_SCROLL_MASK - Add GIMP_ZOOM_SMOOTH to enum GimpZoomType - Add "gdouble delta" to gimp_zoom_model_step() - Change the meaning of the "scale" parameter to "scale or delta" in all functions that take GimpZoomType and a scale factor.
2018-05-11 08:08:51 +08:00
break;
case GDK_SCROLL_SMOOTH:
gdk_event_get_scroll_deltas (event, NULL, &delta);
gimp_display_shell_scale (shell,
GIMP_ZOOM_SMOOTH,
delta,
GIMP_ZOOM_FOCUS_POINTER);
app: update the tool's state after the wheel controller has handled the event
2011-04-07 04:50:20 +08:00
break;
default:
break;
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
app: update the tool's state after the wheel controller has handled the event
2011-04-07 04:50:20 +08:00
else
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: use gimp_scroll_adjustment_values() for scrolling the canvas
2018-05-11 05:33:35 +08:00
gdouble value_x;
gdouble value_y;
app: update the tool's state after the wheel controller has handled the event
2011-04-07 04:50:20 +08:00
app: use gimp_scroll_adjustment_values() for scrolling the canvas
2018-05-11 05:33:35 +08:00
gimp_scroll_adjustment_values (sevent,
shell->hsbdata,
shell->vsbdata,
&value_x, &value_y);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: use gimp_scroll_adjustment_values() for scrolling the canvas
2018-05-11 05:33:35 +08:00
gtk_adjustment_set_value (shell->hsbdata, value_x);
gtk_adjustment_set_value (shell->vsbdata, value_y);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
}
gimp_display_shell_untransform_event_coords (shell,
&display_coords,
&image_coords,
&update_sw_cursor);
tool_manager_oper_update_active (gimp,
&image_coords, state,
shell->proximity,
display);
return_val = TRUE;
}
break;
case GDK_MOTION_NOTIFY:
{
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
GdkEventMotion *mevent = (GdkEventMotion *) event;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
if (gimp->busy)
return TRUE;
app: add utility functions proximity_in() and proximity_out() and use them instead of manually setting proximity. Also add comments about why we call the proximity functions where we call them (instead of calling them where it seems more logical).
2011-02-27 19:08:09 +08:00
/* call proximity_in() here because the pointer might already
* be in proximity when the canvas starts to receive events,
* like when a new image has been created into an empty
* display
*/
app: redo the last commit and call proximity_in() at all logical places Keep the comment at the place where calling it isn't immediately obvious, and add checks to proximity_in() and out() so they bail out when the proximity state is already set correctly.
2011-02-27 19:16:51 +08:00
gimp_display_shell_proximity_in (shell);
update_sw_cursor = TRUE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: fix space actions on canvas. Space: panning Ctrl-space: zooming Shift-space: rotating Ctrl-shift-space: constrained rotating Note that these are still hardcoded, unlike the actions through modifiers + pointer buttons.
2022-08-12 03:07:43 +08:00
if (shell->mod_action != GIMP_MODIFIER_ACTION_NONE ||
shell->space_release_pending)
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
gimp_display_shell_handle_scrolling (shell,
state, mevent->x, mevent->y);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
else if (state & GDK_BUTTON1_MASK)
{
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
GimpTool *active_tool;
GimpMotionMode motion_mode;
active_tool = tool_manager_get_active (gimp);
motion_mode = gimp_tool_control_get_motion_mode (
active_tool->control);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
if (active_tool &&
gimp_tool_control_is_active (active_tool->control) &&
(! gimp_image_is_empty (image) ||
gimp_tool_control_get_handle_empty_image (active_tool->control)))
{
GdkTimeCoord **history_events;
gint n_history_events;
app: add gimp_motion_buffer_get_last_motion_time() and use it The last poking into the buffer is gone now.
2011-04-18 19:13:51 +08:00
guint32 last_motion_time;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
/* if the first mouse button is down, check for automatic
* scrolling...
*/
if ((mevent->x < 0 ||
mevent->y < 0 ||
mevent->x > shell->disp_width ||
mevent->y > shell->disp_height) &&
! gimp_tool_control_get_scroll_lock (active_tool->control))
{
gimp_display_shell_autoscroll_start (shell, state, mevent);
}
app: add gimp_motion_buffer_get_last_motion_time() and use it The last poking into the buffer is gone now.
2011-04-18 19:13:51 +08:00
/* gdk_device_get_history() has several quirks. First
* is that events with borderline timestamps at both
* ends are included. Because of that we need to add 1
* to lower border. The second is due to poor X event
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
* resolution. We need to do -1 to ensure that the
* amount of events between timestamps is final or
Bug 692641 - Various spelling fixes
2013-01-27 23:52:38 +08:00
* risk losing some.
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
*/
app: add gimp_motion_buffer_get_last_motion_time() and use it The last poking into the buffer is gone now.
2011-04-18 19:13:51 +08:00
last_motion_time =
gimp_motion_buffer_get_last_motion_time (shell->motion_buffer);
app: s/gdouble inertia_factor/gboolean event_fill/ in eval_event() Also remove "gdouble max_coord_smooth" from GimpTool and simply use the existing motion mode for deciding whether or not to fill in events.
2011-04-18 01:59:31 +08:00
if (motion_mode == GIMP_MOTION_MODE_EXACT &&
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
shell->display->config->use_event_history &&
gdk_device_get_history (mevent->device, mevent->window,
app: add gimp_motion_buffer_get_last_motion_time() and use it The last poking into the buffer is gone now.
2011-04-18 19:13:51 +08:00
last_motion_time + 1,
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
mevent->time - 1,
&history_events,
&n_history_events))
{
GimpDeviceInfo *device;
gint i;
device = gimp_device_info_get_by_device (mevent->device);
for (i = 0; i < n_history_events; i++)
{
gimp_device_info_get_time_coords (device,
history_events[i],
&display_coords);
gimp_display_shell_untransform_event_coords (shell,
&display_coords,
&image_coords,
NULL);
/* Early removal of useless events saves CPU time.
*/
app: rename gimp_motion_buffer_eval_event() to motion_event() because it's feeding it motion events.
2011-04-18 07:09:57 +08:00
if (gimp_motion_buffer_motion_event (shell->motion_buffer,
&image_coords,
history_events[i]->time,
TRUE))
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: rename process_stroke() and process_hover() to request_foo() Because that's what we are doing by calling the functions: requesting the emission of "stroke" and "hover" signals.
2011-04-18 17:31:38 +08:00
gimp_motion_buffer_request_stroke (shell->motion_buffer,
app: GimpMotionBuffer API cleanup and refactoring - start_stroke()/finih_stroke() -> begin_stroke()/end_stroke() - process_event_queue() -> process_stroke() - GimpMotionBuffer::motion() -> GimpMotionBuffer::stroke() - add GimpMotionBuffer::hover() and process_hover() - remove push_event_history() and pop_event_queue() from API The thing works like this: - Motion events are continuously fed into the buffer using motion_event() - begin_stroke()/end_stroke() correspond to BUTTON_PRESS/BUTTON_RELEASE, the period between them is a "stroke" - If motion_event() returns TRUE, we request "stroke" signals by calling process_stroke() and "hover" signals by calling process_hover()
2011-04-18 17:08:24 +08:00
state,
history_events[i]->time);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
}
gdk_device_free_history (history_events, n_history_events);
}
else
{
app: s/gdouble inertia_factor/gboolean event_fill/ in eval_event() Also remove "gdouble max_coord_smooth" from GimpTool and simply use the existing motion mode for deciding whether or not to fill in events.
2011-04-18 01:59:31 +08:00
gboolean event_fill = (motion_mode == GIMP_MOTION_MODE_EXACT);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
/* Early removal of useless events saves CPU time.
*/
app: rename gimp_motion_buffer_eval_event() to motion_event() because it's feeding it motion events.
2011-04-18 07:09:57 +08:00
if (gimp_motion_buffer_motion_event (shell->motion_buffer,
&image_coords,
time,
event_fill))
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: rename process_stroke() and process_hover() to request_foo() Because that's what we are doing by calling the functions: requesting the emission of "stroke" and "hover" signals.
2011-04-18 17:31:38 +08:00
gimp_motion_buffer_request_stroke (shell->motion_buffer,
app: GimpMotionBuffer API cleanup and refactoring - start_stroke()/finih_stroke() -> begin_stroke()/end_stroke() - process_event_queue() -> process_stroke() - GimpMotionBuffer::motion() -> GimpMotionBuffer::stroke() - add GimpMotionBuffer::hover() and process_hover() - remove push_event_history() and pop_event_queue() from API The thing works like this: - Motion events are continuously fed into the buffer using motion_event() - begin_stroke()/end_stroke() correspond to BUTTON_PRESS/BUTTON_RELEASE, the period between them is a "stroke" - If motion_event() returns TRUE, we request "stroke" signals by calling process_stroke() and "hover" signals by calling process_hover()
2011-04-18 17:08:24 +08:00
state,
time);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
}
}
}
if (! (state &
(GDK_BUTTON1_MASK | GDK_BUTTON2_MASK | GDK_BUTTON3_MASK)))
{
/* Early removal of useless events saves CPU time.
app: s/gdouble inertia_factor/gboolean event_fill/ in eval_event() Also remove "gdouble max_coord_smooth" from GimpTool and simply use the existing motion mode for deciding whether or not to fill in events.
2011-04-18 01:59:31 +08:00
* Pass event_fill = FALSE since we are only hovering.
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
*/
app: rename gimp_motion_buffer_eval_event() to motion_event() because it's feeding it motion events.
2011-04-18 07:09:57 +08:00
if (gimp_motion_buffer_motion_event (shell->motion_buffer,
&image_coords,
time,
FALSE))
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: rename process_stroke() and process_hover() to request_foo() Because that's what we are doing by calling the functions: requesting the emission of "stroke" and "hover" signals.
2011-04-18 17:31:38 +08:00
gimp_motion_buffer_request_hover (shell->motion_buffer,
app: GimpMotionBuffer API cleanup and refactoring - start_stroke()/finih_stroke() -> begin_stroke()/end_stroke() - process_event_queue() -> process_stroke() - GimpMotionBuffer::motion() -> GimpMotionBuffer::stroke() - add GimpMotionBuffer::hover() and process_hover() - remove push_event_history() and pop_event_queue() from API The thing works like this: - Motion events are continuously fed into the buffer using motion_event() - begin_stroke()/end_stroke() correspond to BUTTON_PRESS/BUTTON_RELEASE, the period between them is a "stroke" - If motion_event() returns TRUE, we request "stroke" signals by calling process_stroke() and "hover" signals by calling process_hover()
2011-04-18 17:08:24 +08:00
state,
shell->proximity);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
}
return_val = TRUE;
}
break;
case GDK_KEY_PRESS:
{
GdkEventKey *kevent = (GdkEventKey *) event;
GimpTool *active_tool;
active_tool = tool_manager_get_active (gimp);
if (state & GDK_BUTTON1_MASK)
{
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
if (kevent->keyval == GDK_KEY_Alt_L ||
kevent->keyval == GDK_KEY_Alt_R ||
kevent->keyval == GDK_KEY_Shift_L ||
kevent->keyval == GDK_KEY_Shift_R ||
kevent->keyval == GDK_KEY_Control_L ||
kevent->keyval == GDK_KEY_Control_R ||
kevent->keyval == GDK_KEY_Meta_L ||
kevent->keyval == GDK_KEY_Meta_R)
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
{
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
GdkModifierType key;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
key = gimp_display_shell_key_to_state (kevent->keyval);
state |= key;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
if (active_tool &&
gimp_tool_control_is_active (active_tool->control) &&
! gimp_image_is_empty (image))
{
tool_manager_active_modifier_state_active (gimp, state,
display);
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
}
else
{
Bug 676927 - Shortcuts with backspace not working if image is focused Move local variable out of the switch() block, it was never initialized.
2013-02-15 08:00:13 +08:00
gboolean arrow_key = FALSE;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
tool_manager_focus_display_active (gimp, display);
if (gimp_tool_control_get_wants_all_key_events (active_tool->control))
{
if (tool_manager_key_press_active (gimp, kevent, display))
{
/* FIXME: need to do some of the stuff below, like
* calling oper_update()
*/
return TRUE;
}
}
app: redo commit "make sure overlay widgets are keyboard navigatable" Letting just tab presses bubble up when an overlay canvas child didn't handle a key event isn't enough. Instead, let all key presses and releases bubble up if the canvas itself doesn't have the focus. Read: don't make assumptions.
2013-06-08 23:27:05 +08:00
if (! gtk_widget_has_focus (shell->canvas))
{
/* The event was in an overlay widget and not handled
* there, make sure the overlay widgets are keyboard
* navigatable by letting the generic widget handlers
* deal with the event.
*/
return FALSE;
}
app: make layer picking a generic modifier of the shell. 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).
2018-12-23 02:09:34 +08:00
if (gimp_display_shell_key_to_state (kevent->keyval) == GDK_MOD1_MASK)
app: push a temporary status when picking layer with alt-midclick. 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.
2019-01-09 07:11:37 +08:00
/* Make sure the picked layer is reset. */
app: make layer picking a generic modifier of the shell. 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).
2018-12-23 02:09:34 +08:00
shell->picked_layer = NULL;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
switch (kevent->keyval)
{
Bug 677262 - move the layer with the arrow keys, broken after... commit 9ce8d4fae2f63576828f80dc156e2fb05f34d510. Fix the return_val logic added in that commit, and make sure we always swallow arroy key events, because we don't want focus keynav away from the canvas.
2012-06-08 06:21:07 +08:00
case GDK_KEY_Left:
case GDK_KEY_Right:
case GDK_KEY_Up:
case GDK_KEY_Down:
arrow_key = TRUE;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_KEY_Return:
case GDK_KEY_KP_Enter:
case GDK_KEY_ISO_Enter:
case GDK_KEY_BackSpace:
case GDK_KEY_Escape:
Bug 677262 - move the layer with the arrow keys, broken after... commit 9ce8d4fae2f63576828f80dc156e2fb05f34d510. Fix the return_val logic added in that commit, and make sure we always swallow arroy key events, because we don't want focus keynav away from the canvas.
2012-06-08 06:21:07 +08:00
if (! gimp_image_is_empty (image))
return_val = tool_manager_key_press_active (gimp,
kevent,
display);
if (! return_val)
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
{
GimpController *keyboard = gimp_controllers_get_keyboard (gimp);
if (keyboard)
Bug 676872 - Image Properties keyboard shortcut Alt+Return Broken Don't swallow key events which were not handled by the keyboard controller.
2012-05-28 01:55:42 +08:00
return_val =
gimp_controller_keyboard_key_press (GIMP_CONTROLLER_KEYBOARD (keyboard),
kevent);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
Bug 677262 - move the layer with the arrow keys, broken after... commit 9ce8d4fae2f63576828f80dc156e2fb05f34d510. Fix the return_val logic added in that commit, and make sure we always swallow arroy key events, because we don't want focus keynav away from the canvas.
2012-06-08 06:21:07 +08:00
/* always swallow arrow keys, we don't want focus keynav */
if (! return_val)
return_val = arrow_key;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
break;
case GDK_KEY_space:
case GDK_KEY_KP_Space:
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
if (shell->button1_release_pending)
shell->space_release_pending = TRUE;
else
gimp_display_shell_space_pressed (shell, event);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
return_val = TRUE;
break;
case GDK_KEY_Tab:
app: make sure overlay widgets are keyboard navigatable Tab key events are not handled by the widget itself, they are supposed to bubble up until they hit the generic keyboard navigation code that knows about the focus chain, therefore: gimp_display_shell_canvas_tool_events(): if an overlay widget is focussed, don't handle Tab events and toggle dock visibility. Instead, simply bail out with FALSE so the event reaches te keyboard navigation code. Also treat GDK_KEY_KP_Tab like GDK_KEY_Tab all over the place.
2013-06-08 21:27:14 +08:00
case GDK_KEY_KP_Tab:
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_KEY_ISO_Left_Tab:
app: redo commit "make sure overlay widgets are keyboard navigatable" Letting just tab presses bubble up when an overlay canvas child didn't handle a key event isn't enough. Instead, let all key presses and releases bubble up if the canvas itself doesn't have the focus. Read: don't make assumptions.
2013-06-08 23:27:05 +08:00
gimp_display_shell_tab_pressed (shell, kevent);
return_val = TRUE;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
break;
/* Update the state based on modifiers being pressed */
case GDK_KEY_Alt_L: case GDK_KEY_Alt_R:
case GDK_KEY_Shift_L: case GDK_KEY_Shift_R:
case GDK_KEY_Control_L: case GDK_KEY_Control_R:
app: treat Meta_L and Meta_R as tool-relevant modifiers for the Mac, they are still unhandled by tools though.
2011-10-06 01:44:24 +08:00
case GDK_KEY_Meta_L: case GDK_KEY_Meta_R:
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
{
GdkModifierType key;
key = gimp_display_shell_key_to_state (kevent->keyval);
state |= key;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
if (! gimp_image_is_empty (image))
tool_manager_modifier_state_active (gimp, state, display);
}
break;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
tool_manager_oper_update_active (gimp,
&image_coords, state,
shell->proximity,
display);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
}
break;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_KEY_RELEASE:
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
GdkEventKey *kevent = (GdkEventKey *) event;
GimpTool *active_tool;
active_tool = tool_manager_get_active (gimp);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
if (shell->mod_action == GIMP_MODIFIER_ACTION_LAYER_PICKING)
app: push a temporary status when picking layer with alt-midclick. 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.
2019-01-09 07:11:37 +08:00
{
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
/* As a special exception, we finalize the layer picking
* action in the key release event. This allows one to
* click multiple times and keep a state of the last picked
* layer.
* */
GimpStatusbar *statusbar;
statusbar = gimp_display_shell_get_statusbar (shell);
gimp_statusbar_pop_temp (statusbar);
shell->picked_layer = NULL;
shell->mod_action = GIMP_MODIFIER_ACTION_NONE;
}
app: fix switching seamlessly from constrained to unconstrained canvas… … rotation and back.
2022-08-12 07:03:56 +08:00
else if (shell->mod_action != GIMP_MODIFIER_ACTION_NONE &&
(state & gimp_get_all_modifiers_mask ()) == 0)
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
{
gimp_display_shell_stop_scrolling (shell, event);
app: push a temporary status when picking layer with alt-midclick. 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.
2019-01-09 07:11:37 +08:00
}
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
if ((state & GDK_BUTTON1_MASK) &&
(! shell->space_release_pending ||
(kevent->keyval != GDK_KEY_space &&
kevent->keyval != GDK_KEY_KP_Space)))
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
if (kevent->keyval == GDK_KEY_Alt_L ||
kevent->keyval == GDK_KEY_Alt_R ||
kevent->keyval == GDK_KEY_Shift_L ||
kevent->keyval == GDK_KEY_Shift_R ||
kevent->keyval == GDK_KEY_Control_L ||
kevent->keyval == GDK_KEY_Control_R ||
kevent->keyval == GDK_KEY_Meta_L ||
kevent->keyval == GDK_KEY_Meta_R)
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
GdkModifierType key;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
key = gimp_display_shell_key_to_state (kevent->keyval);
state &= ~key;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
Bug 724692 - Canvas rotation stuck with specific order of actions. 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.
2018-03-16 09:31:43 +08:00
if (active_tool &&
gimp_tool_control_is_active (active_tool->control) &&
! gimp_image_is_empty (image))
{
tool_manager_active_modifier_state_active (gimp, state,
display);
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
}
else
{
tool_manager_focus_display_active (gimp, display);
if (gimp_tool_control_get_wants_all_key_events (active_tool->control))
{
if (tool_manager_key_release_active (gimp, kevent, display))
{
/* FIXME: need to do some of the stuff below, like
* calling oper_update()
*/
return TRUE;
}
}
app: redo commit "make sure overlay widgets are keyboard navigatable" Letting just tab presses bubble up when an overlay canvas child didn't handle a key event isn't enough. Instead, let all key presses and releases bubble up if the canvas itself doesn't have the focus. Read: don't make assumptions.
2013-06-08 23:27:05 +08:00
if (! gtk_widget_has_focus (shell->canvas))
{
/* The event was in an overlay widget and not handled
* there, make sure the overlay widgets are keyboard
* navigatable by letting the generic widget handlers
* deal with the event.
*/
return FALSE;
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
switch (kevent->keyval)
{
case GDK_KEY_space:
case GDK_KEY_KP_Space:
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
if ((state & GDK_BUTTON1_MASK))
{
shell->button1_release_pending = TRUE;
shell->space_release_pending = FALSE;
/* We need to ungrab the pointer in order to catch
* button release events.
*/
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
if (shell->grab_pointer)
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
gimp_display_shell_pointer_ungrab (shell, event);
}
else
{
gimp_display_shell_released (shell, event, NULL);
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
return_val = TRUE;
break;
/* Update the state based on modifiers being pressed */
case GDK_KEY_Alt_L: case GDK_KEY_Alt_R:
case GDK_KEY_Shift_L: case GDK_KEY_Shift_R:
case GDK_KEY_Control_L: case GDK_KEY_Control_R:
app: treat Meta_L and Meta_R as tool-relevant modifiers for the Mac, they are still unhandled by tools though.
2011-10-06 01:44:24 +08:00
case GDK_KEY_Meta_L: case GDK_KEY_Meta_R:
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
{
GdkModifierType key;
key = gimp_display_shell_key_to_state (kevent->keyval);
state &= ~key;
/* For all modifier keys: call the tools
* modifier_state *and* oper_update method so tools
* can choose if they are interested in the press
* itself or only in the resulting state
*/
if (! gimp_image_is_empty (image))
tool_manager_modifier_state_active (gimp, state, display);
}
break;
}
tool_manager_oper_update_active (gimp,
&image_coords, state,
shell->proximity,
display);
}
}
break;
default:
break;
}
/* if we reached this point in gimp_busy mode, return now */
if (gimp->busy)
return return_val;
/* cursor update */
gimp_display_shell_update_cursor (shell, &display_coords, &image_coords,
state, update_sw_cursor);
return return_val;
}
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
void
gimp_display_shell_canvas_grab_notify (GtkWidget *canvas,
gboolean was_grabbed,
GimpDisplayShell *shell)
{
GimpDisplay *display;
GimpImage *image;
Gimp *gimp;
/* are we in destruction? */
if (! shell->display || ! gimp_display_get_shell (shell->display))
return;
display = shell->display;
gimp = gimp_display_get_gimp (display);
image = gimp_display_get_image (display);
if (! image)
return;
GIMP_LOG (TOOL_EVENTS, "grab_notify (display %p): was_grabbed = %s",
display, was_grabbed ? "TRUE" : "FALSE");
if (! was_grabbed)
{
if (! gimp_image_is_empty (image))
{
GimpTool *active_tool = tool_manager_get_active (gimp);
if (active_tool && active_tool->focus_display == display)
{
tool_manager_modifier_state_active (gimp, 0, display);
}
}
}
}
app: Implement exclusiveness of zoom and rotate gestures Performing zoom and rotation at the same time is inconvenient because most of the time the user will want either zoom or rotation. This can be solved by recognizing a "significant enough" zoom or rotation change initiated by the gesture recognizer and then ignoring the other gesture.
2022-03-17 20:55:04 +08:00
/* The ratio of the following defines what finger movement we interpret as
* a rotation versus zoom gesture. If finger movement is partially a zoom
* and partially a rotation, the detected gesture will be whichever gesture
* we detect first
*
* Let's define "finger movement angle" as the angle between the direction of
* finger movement and the line between fingers. If this angle is zero then
* the gesture is completely a zoom gesture. If this angle is 90 degrees
* then the gesture is completely a rotation gesture.
*
* The boundary finger movement angle (below which the gesture is zoom gesture
* and above which the gesture is rotate gesture) will be defined as follows:
*
* boundary = arctan(deg2rad(ROTATE_GESTURE_ACTIVATION_DEG_DIFF) /
* (ZOOM_GESTURE_ACTIVATION_SCALE_DIFF / 2))
*
* Note that ZOOM_GESTURE_ACTIVATION_SCALE_DIFF needs to be divided by 2
* because both fingers are moving so the distance between them is increasing
* twice as fast.
*
* We probably want boundary angle to be around 60 degrees to prevent
* accidentally starting rotations.
*
* With ZOOM_GESTURE_ACTIVATION_SCALE_DIFF==0.02 and
* ROTATE_GESTURE_ACTIVATION_DEG_DIFF==1 boundary is 60.2 degrees.
*/
#define ZOOM_GESTURE_ACTIVATION_SCALE_DIFF 0.02
#define ROTATE_GESTURE_ACTIVATION_DEG_DIFF 1
app: Implement canvas support for touchpad gesture zoom by pinch
2021-01-27 04:14:45 +08:00
void
gimp_display_shell_zoom_gesture_begin (GtkGestureZoom *gesture,
GdkEventSequence *sequence,
GimpDisplayShell *shell)
{
shell->last_zoom_scale = gtk_gesture_zoom_get_scale_delta (gesture);
}
void
gimp_display_shell_zoom_gesture_update (GtkGestureZoom *gesture,
GdkEventSequence *sequence,
GimpDisplayShell *shell)
{
app: Implement exclusiveness of zoom and rotate gestures Performing zoom and rotation at the same time is inconvenient because most of the time the user will want either zoom or rotation. This can be solved by recognizing a "significant enough" zoom or rotation change initiated by the gesture recognizer and then ignoring the other gesture.
2022-03-17 20:55:04 +08:00
gdouble current_scale;
gdouble delta;
if (shell->rotate_gesture_active)
return;
/* we only activate zoom gesture handling if rotate gesture was inactive and
* the zoom difference is significant enough */
current_scale = gtk_gesture_zoom_get_scale_delta (gesture);
if (!shell->zoom_gesture_active &&
current_scale > (1 - ZOOM_GESTURE_ACTIVATION_SCALE_DIFF) &&
current_scale < (1 + ZOOM_GESTURE_ACTIVATION_SCALE_DIFF))
return;
shell->zoom_gesture_active = TRUE;
delta = (current_scale - shell->last_zoom_scale) / shell->last_zoom_scale;
app: Implement canvas support for touchpad gesture zoom by pinch
2021-01-27 04:14:45 +08:00
shell->last_zoom_scale = current_scale;
gimp_display_shell_scale (shell,
GIMP_ZOOM_PINCH,
delta,
GIMP_ZOOM_FOCUS_POINTER);
}
app: Implement exclusiveness of zoom and rotate gestures Performing zoom and rotation at the same time is inconvenient because most of the time the user will want either zoom or rotation. This can be solved by recognizing a "significant enough" zoom or rotation change initiated by the gesture recognizer and then ignoring the other gesture.
2022-03-17 20:55:04 +08:00
void
gimp_display_shell_zoom_gesture_end (GtkGestureZoom *gesture,
GdkEventSequence *sequence,
GimpDisplayShell *shell)
{
shell->zoom_gesture_active = FALSE;
}
app: Implement canvas support for touchpad gesture rotation by pinch
2022-03-17 05:59:20 +08:00
void
gimp_display_shell_rotate_gesture_begin (GtkGestureRotate *gesture,
GdkEventSequence *sequence,
GimpDisplayShell *shell)
{
shell->initial_gesture_rotate_angle = shell->rotate_angle;
shell->last_gesture_rotate_state = 0;
gimp_display_shell_rotate_gesture_maybe_get_state (gesture, sequence,
&shell->last_gesture_rotate_state);
}
void
gimp_display_shell_rotate_gesture_update (GtkGestureRotate *gesture,
GdkEventSequence *sequence,
GimpDisplayShell *shell)
{
app: Implement exclusiveness of zoom and rotate gestures Performing zoom and rotation at the same time is inconvenient because most of the time the user will want either zoom or rotation. This can be solved by recognizing a "significant enough" zoom or rotation change initiated by the gesture recognizer and then ignoring the other gesture.
2022-03-17 20:55:04 +08:00
gdouble angle;
gdouble angle_delta_deg;
gboolean constrain;
/* we only activate rotate gesture handling if zoom gesture was inactive and
* the rotation is significant enough */
if (shell->zoom_gesture_active)
return;
angle_delta_deg = 180.0 * gtk_gesture_rotate_get_angle_delta (gesture) / G_PI;
if (!shell->rotate_gesture_active &&
angle_delta_deg > -ROTATE_GESTURE_ACTIVATION_DEG_DIFF &&
angle_delta_deg < ROTATE_GESTURE_ACTIVATION_DEG_DIFF)
return;
shell->rotate_gesture_active = TRUE;
angle = shell->initial_gesture_rotate_angle + angle_delta_deg;
app: Implement canvas support for touchpad gesture rotation by pinch
2022-03-17 05:59:20 +08:00
gimp_display_shell_rotate_gesture_maybe_get_state (gesture, sequence,
&shell->last_gesture_rotate_state);
constrain = (shell->last_gesture_rotate_state & GDK_CONTROL_MASK) ? TRUE : FALSE;
app: Implement exclusiveness of zoom and rotate gestures Performing zoom and rotation at the same time is inconvenient because most of the time the user will want either zoom or rotation. This can be solved by recognizing a "significant enough" zoom or rotation change initiated by the gesture recognizer and then ignoring the other gesture.
2022-03-17 20:55:04 +08:00
gimp_display_shell_rotate_to (shell, constrain ? RINT (angle / 15.0) * 15.0 : angle);
}
void
gimp_display_shell_rotate_gesture_end (GtkGestureRotate *gesture,
GdkEventSequence *sequence,
GimpDisplayShell *shell)
{
shell->rotate_gesture_active = FALSE;
app: Implement canvas support for touchpad gesture rotation by pinch
2022-03-17 05:59:20 +08:00
}
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
void
gimp_display_shell_buffer_stroke (GimpMotionBuffer *buffer,
const GimpCoords *coords,
guint32 time,
GdkModifierType state,
GimpDisplayShell *shell)
{
GimpDisplay *display = shell->display;
Gimp *gimp = gimp_display_get_gimp (display);
GimpTool *active_tool;
active_tool = tool_manager_get_active (gimp);
if (active_tool &&
gimp_tool_control_is_active (active_tool->control))
{
tool_manager_motion_active (gimp,
coords, time, state,
display);
}
}
void
gimp_display_shell_buffer_hover (GimpMotionBuffer *buffer,
const GimpCoords *coords,
GdkModifierType state,
gboolean proximity,
GimpDisplayShell *shell)
{
GimpDisplay *display = shell->display;
Gimp *gimp = gimp_display_get_gimp (display);
GimpTool *active_tool;
active_tool = tool_manager_get_active (gimp);
if (active_tool &&
! gimp_tool_control_is_active (active_tool->control))
{
tool_manager_oper_update_active (gimp,
coords, state, proximity,
display);
}
}
static gboolean
gimp_display_shell_ruler_button_press (GtkWidget *widget,
GdkEventButton *event,
GimpDisplayShell *shell,
GimpOrientationType orientation)
{
GimpDisplay *display = shell->display;
if (display->gimp->busy)
return TRUE;
if (! gimp_display_get_image (display))
return TRUE;
if (event->type == GDK_BUTTON_PRESS && event->button == 1)
{
GimpTool *active_tool = tool_manager_get_active (display->gimp);
if (active_tool)
{
gimp_display_shell_update_focus (shell, TRUE,
NULL, event->state);
if (gimp_display_shell_pointer_grab (shell, (GdkEvent *) event,
GDK_POINTER_MOTION_MASK |
GDK_BUTTON_RELEASE_MASK))
{
app/display: Remove keyboard grab Remove `gimp_display_shell_keyboard_grab()` and ...ungrab(), as there doesn't seem to be any good reason to grab the keyboard away from the compositor. More annoyingly, in some systems it will pop up a dialog on each first click whether the user is okay with inhibiting shortcuts.
2021-12-15 05:36:43 +08:00
if (event->state & gimp_get_toggle_behavior_mask ())
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
{
app/display: Remove keyboard grab Remove `gimp_display_shell_keyboard_grab()` and ...ungrab(), as there doesn't seem to be any good reason to grab the keyboard away from the compositor. More annoyingly, in some systems it will pop up a dialog on each first click whether the user is okay with inhibiting shortcuts.
2021-12-15 05:36:43 +08:00
gimp_sample_point_tool_start_new (active_tool, display);
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
}
else
{
app/display: Remove keyboard grab Remove `gimp_display_shell_keyboard_grab()` and ...ungrab(), as there doesn't seem to be any good reason to grab the keyboard away from the compositor. More annoyingly, in some systems it will pop up a dialog on each first click whether the user is okay with inhibiting shortcuts.
2021-12-15 05:36:43 +08:00
gimp_guide_tool_start_new (active_tool, display,
orientation);
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
}
app/display: Remove keyboard grab Remove `gimp_display_shell_keyboard_grab()` and ...ungrab(), as there doesn't seem to be any good reason to grab the keyboard away from the compositor. More annoyingly, in some systems it will pop up a dialog on each first click whether the user is okay with inhibiting shortcuts.
2021-12-15 05:36:43 +08:00
return TRUE;
app: fix canvas motion compression In gimp_display_shell_canvas_tool_events(), use gdk_window_set_event_compression(), instead of implementing our own motion compression, which used to introduce all sorts of weird effects when combined with extended input devices, that we had to hackishly work around. For tools that use GIMP_MOTION_MODE_EXACT, we call gdk_window_set_event_compression() to disable motion compression for the canvas window upon initializing the tool in response to a GDK_BUTTON_PRESS event, and again to re-eanble compression upon the corresponding GDK_BUTTON_RELEASE event. This commit also merges gimp_display_shell_canvas_tool_events_internal() back into gimp_display_shell_canvas_tool_events(). The split was a detail of our custom motion compression implementation.
2018-05-04 22:19:42 +08:00
}
}
}
return FALSE;
}
gboolean
gimp_display_shell_hruler_button_press (GtkWidget *widget,
GdkEventButton *event,
GimpDisplayShell *shell)
{
return gimp_display_shell_ruler_button_press (widget, event, shell,
GIMP_ORIENTATION_HORIZONTAL);
}
gboolean
gimp_display_shell_vruler_button_press (GtkWidget *widget,
GdkEventButton *event,
GimpDisplayShell *shell)
{
return gimp_display_shell_ruler_button_press (widget, event, shell,
GIMP_ORIENTATION_VERTICAL);
}
/* private functions */
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
static GdkModifierType
gimp_display_shell_key_to_state (gint key)
{
app: treat Meta_L and Meta_R as tool-relevant modifiers for the Mac, they are still unhandled by tools though.
2011-10-06 01:44:24 +08:00
/* FIXME: need some proper GDK API to figure this */
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
switch (key)
{
case GDK_KEY_Alt_L:
case GDK_KEY_Alt_R:
return GDK_MOD1_MASK;
Bug 732160 - menu activation with alt-somekey makes tools stay... ...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.
2016-04-15 07:17:00 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_KEY_Shift_L:
case GDK_KEY_Shift_R:
return GDK_SHIFT_MASK;
Bug 732160 - menu activation with alt-somekey makes tools stay... ...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.
2016-04-15 07:17:00 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GDK_KEY_Control_L:
case GDK_KEY_Control_R:
return GDK_CONTROL_MASK;
Bug 732160 - menu activation with alt-somekey makes tools stay... ...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.
2016-04-15 07:17:00 +08:00
app: treat Meta_L and Meta_R as tool-relevant modifiers for the Mac, they are still unhandled by tools though.
2011-10-06 01:44:24 +08:00
#ifdef GDK_WINDOWING_QUARTZ
case GDK_KEY_Meta_L:
case GDK_KEY_Meta_R:
return GDK_MOD2_MASK;
#endif
Bug 732160 - menu activation with alt-somekey makes tools stay... ...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.
2016-04-15 07:17:00 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
default:
return 0;
}
}
app: use gdk_event_triggers_context_menu() for the image menu and clean up button event handling a bit.
2011-10-06 02:04:42 +08:00
static GdkModifierType
gimp_display_shell_button_to_state (gint button)
{
if (button == 1)
return GDK_BUTTON1_MASK;
else if (button == 2)
return GDK_BUTTON2_MASK;
else if (button == 3)
return GDK_BUTTON3_MASK;
return 0;
}
app: add utility functions proximity_in() and proximity_out() and use them instead of manually setting proximity. Also add comments about why we call the proximity functions where we call them (instead of calling them where it seems more logical).
2011-02-27 19:08:09 +08:00
static void
gimp_display_shell_proximity_in (GimpDisplayShell *shell)
{
app: redo the last commit and call proximity_in() at all logical places Keep the comment at the place where calling it isn't immediately obvious, and add checks to proximity_in() and out() so they bail out when the proximity state is already set correctly.
2011-02-27 19:16:51 +08:00
if (! shell->proximity)
{
shell->proximity = TRUE;
app: add utility functions proximity_in() and proximity_out() and use them instead of manually setting proximity. Also add comments about why we call the proximity functions where we call them (instead of calling them where it seems more logical).
2011-02-27 19:08:09 +08:00
app: redo the last commit and call proximity_in() at all logical places Keep the comment at the place where calling it isn't immediately obvious, and add checks to proximity_in() and out() so they bail out when the proximity state is already set correctly.
2011-02-27 19:16:51 +08:00
gimp_display_shell_check_device_cursor (shell);
}
app: add utility functions proximity_in() and proximity_out() and use them instead of manually setting proximity. Also add comments about why we call the proximity functions where we call them (instead of calling them where it seems more logical).
2011-02-27 19:08:09 +08:00
}
static void
gimp_display_shell_proximity_out (GimpDisplayShell *shell)
{
app: redo the last commit and call proximity_in() at all logical places Keep the comment at the place where calling it isn't immediately obvious, and add checks to proximity_in() and out() so they bail out when the proximity state is already set correctly.
2011-02-27 19:16:51 +08:00
if (shell->proximity)
{
shell->proximity = FALSE;
app: add utility functions proximity_in() and proximity_out() and use them instead of manually setting proximity. Also add comments about why we call the proximity functions where we call them (instead of calling them where it seems more logical).
2011-02-27 19:08:09 +08:00
app: redo the last commit and call proximity_in() at all logical places Keep the comment at the place where calling it isn't immediately obvious, and add checks to proximity_in() and out() so they bail out when the proximity state is already set correctly.
2011-02-27 19:16:51 +08:00
gimp_display_shell_clear_software_cursor (shell);
}
app: add utility functions proximity_in() and proximity_out() and use them instead of manually setting proximity. Also add comments about why we call the proximity functions where we call them (instead of calling them where it seems more logical).
2011-02-27 19:08:09 +08:00
}
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
static gboolean
gimp_display_shell_check_device (GimpDisplayShell *shell,
GdkEvent *event,
gboolean *device_changed)
{
Gimp *gimp = gimp_display_get_gimp (shell->display);
GdkDevice *device;
GdkDevice *grab_device;
/* Find out what device the event occurred upon */
device = gimp_devices_get_from_event (gimp, event, &grab_device);
if (device)
{
/* While we have a grab, ignore all events from all other devices
* of the same type
*/
app/display: Remove keyboard grab Remove `gimp_display_shell_keyboard_grab()` and ...ungrab(), as there doesn't seem to be any good reason to grab the keyboard away from the compositor. More annoyingly, in some systems it will pop up a dialog on each first click whether the user is okay with inhibiting shortcuts.
2021-12-15 05:36:43 +08:00
if (event->type != GDK_KEY_PRESS &&
event->type != GDK_KEY_RELEASE &&
event->type != GDK_FOCUS_CHANGE)
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
{
if ((shell->grab_pointer && (shell->grab_pointer != grab_device)) ||
(shell->grab_pointer_source && (shell->grab_pointer_source != device)))
{
GIMP_LOG (TOOL_EVENTS,
"ignoring pointer event from '%s' while waiting for event from '%s'\n",
gdk_device_get_name (device),
gdk_device_get_name (shell->grab_pointer_source));
return TRUE;
}
}
if (! gimp->busy && gimp_devices_check_change (gimp, device))
{
gimp_display_shell_check_device_cursor (shell);
*device_changed = TRUE;
}
}
return FALSE;
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
static void
gimp_display_shell_check_device_cursor (GimpDisplayShell *shell)
{
app: GimpDeviceManager refactoring part two - change gimp_devices_get_list() to gimp_devices_get_manager() - remove gimp_devices_get_current() - let GimpDeviceStatus connect to the manager's "notify::current-device" directly and remove device status updating code from gui.c - cleanup in gimpdevices.c
2011-02-28 21:37:00 +08:00
GimpDeviceManager *manager;
GimpDeviceInfo *current_device;
manager = gimp_devices_get_manager (shell->display->gimp);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
app: GimpDeviceManager refactoring part two - change gimp_devices_get_list() to gimp_devices_get_manager() - remove gimp_devices_get_current() - let GimpDeviceStatus connect to the manager's "notify::current-device" directly and remove device status updating code from gui.c - cleanup in gimpdevices.c
2011-02-28 21:37:00 +08:00
current_device = gimp_device_manager_get_current_device (manager);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
shell->draw_cursor = ! gimp_device_info_has_cursor (current_device);
}
static void
gimp_display_shell_start_scrolling (GimpDisplayShell *shell,
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
const GdkEvent *event,
Bug 55367 - Rotated view of the canvas (view is rotated, not image contents) First version of display rotation, inspired by gimp-painter. The rotation always happens around the image's center. The only "UI" for rotating is currently shift+middle-drag and shift+space-drag. Control constrains the angle to 15 degrees and is currently the only way to go back to "no rotation".
2013-04-19 22:22:19 +08:00
GdkModifierType state,
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
gint x,
gint y)
{
app: fix space actions on canvas. Space: panning Ctrl-space: zooming Shift-space: rotating Ctrl-shift-space: constrained rotating Note that these are still hardcoded, unlike the actions through modifiers + pointer buttons.
2022-08-12 03:07:43 +08:00
GimpModifierAction mod_action = shell->mod_action;
if (mod_action == GIMP_MODIFIER_ACTION_NONE && shell->space_release_pending)
{
/* XXX The space actions are still hard-coded (instead of
* customizable throguh GimpModifiersManager). It might be
* interesting to make them customizable later.
*/
GdkModifierType state = 0;
gdk_event_get_state (event, &state);
state &= gimp_get_all_modifiers_mask ();
if (state == 0)
mod_action = GIMP_MODIFIER_ACTION_PANNING;
else if (state == gimp_get_extend_selection_mask ())
mod_action = GIMP_MODIFIER_ACTION_ROTATING;
else if (state == (gimp_get_extend_selection_mask () | GDK_CONTROL_MASK))
mod_action = GIMP_MODIFIER_ACTION_STEP_ROTATING;
else if (state == gimp_get_toggle_behavior_mask ())
mod_action = GIMP_MODIFIER_ACTION_ZOOMING;
}
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
gimp_display_shell_pointer_grab (shell, event,
GDK_POINTER_MOTION_MASK |
GDK_BUTTON_RELEASE_MASK);
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
Issue #1531 - Zooming with mouse movement should keep track of original point When Control-Button2-Zooming, remember the start point, pass it to gimp_display_shell_scale_drag() and force gimp_display_shell_scale() to zoom around that point by passing GIMP_ZOOM_FOCUS_POINTER and faking the point using gimp_display_shell_push_zoom_focus_pointer_pos().
2018-06-04 17:42:02 +08:00
shell->scroll_start_x = x;
shell->scroll_start_y = y;
Bug 55367 - Rotated view of the canvas (view is rotated, not image contents) First version of display rotation, inspired by gimp-painter. The rotation always happens around the image's center. The only "UI" for rotating is currently shift+middle-drag and shift+space-drag. Control constrains the angle to 15 degrees and is currently the only way to go back to "no rotation".
2013-04-19 22:22:19 +08:00
shell->scroll_last_x = x;
shell->scroll_last_y = y;
shell->rotate_drag_angle = shell->rotate_angle;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: fix space actions on canvas. Space: panning Ctrl-space: zooming Shift-space: rotating Ctrl-shift-space: constrained rotating Note that these are still hardcoded, unlike the actions through modifiers + pointer buttons.
2022-08-12 03:07:43 +08:00
switch (mod_action)
app: make layer picking a generic modifier of the shell. 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).
2018-12-23 02:09:34 +08:00
{
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
case GIMP_MODIFIER_ACTION_ROTATING:
case GIMP_MODIFIER_ACTION_STEP_ROTATING:
app: make layer picking a generic modifier of the shell. 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).
2018-12-23 02:09:34 +08:00
gimp_display_shell_set_override_cursor (shell,
(GimpCursorType) GDK_EXCHANGE);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
break;
case GIMP_MODIFIER_ACTION_ZOOMING:
app: make layer picking a generic modifier of the shell. 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).
2018-12-23 02:09:34 +08:00
gimp_display_shell_set_override_cursor (shell,
(GimpCursorType) GIMP_CURSOR_ZOOM);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
break;
case GIMP_MODIFIER_ACTION_LAYER_PICKING:
app: make layer picking a generic modifier of the shell. 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).
2018-12-23 02:09:34 +08:00
{
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
GimpImage *image = gimp_display_get_image (shell->display);
GimpLayer *layer;
GimpCoords image_coords;
GimpCoords display_coords;
guint32 time;
gimp_display_shell_set_override_cursor (shell,
(GimpCursorType) GIMP_CURSOR_CROSSHAIR);
gimp_display_shell_get_event_coords (shell, event,
&display_coords,
&state, &time);
gimp_display_shell_untransform_event_coords (shell,
&display_coords, &image_coords,
NULL);
layer = gimp_image_pick_layer (image,
(gint) image_coords.x,
(gint) image_coords.y,
shell->picked_layer);
if (layer && ! gimp_image_get_floating_selection (image))
app: push a temporary status when picking layer with alt-midclick. 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.
2019-01-09 07:11:37 +08:00
{
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
GList *layers = gimp_image_get_selected_layers (image);
if (g_list_length (layers) != 1 || layer != layers->data)
{
GimpStatusbar *statusbar;
app: push a temporary status when picking layer with alt-midclick. 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.
2019-01-09 07:11:37 +08:00
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
layers = g_list_prepend (NULL, layer);
gimp_image_set_selected_layers (image, layers);
g_list_free (layers);
app: push a temporary status when picking layer with alt-midclick. 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.
2019-01-09 07:11:37 +08:00
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
statusbar = gimp_display_shell_get_statusbar (shell);
gimp_statusbar_push_temp (statusbar, GIMP_MESSAGE_INFO,
GIMP_ICON_LAYER,
_("Layer picked: '%s'"),
gimp_object_get_name (layer));
}
shell->picked_layer = layer;
app: push a temporary status when picking layer with alt-midclick. 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.
2019-01-09 07:11:37 +08:00
}
app: make layer picking a generic modifier of the shell. 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).
2018-12-23 02:09:34 +08:00
}
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
break;
case GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE:
app: new modifier action to set brush size diameter. Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the brush size on-canvas, starting from center to border. The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size from one border to another.
2022-08-12 06:18:22 +08:00
case GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE:
app: add a modifier action for opacity change. Opacity and brush size are among the 2 most common tool options which people might want to often change, though we should likely later add all other common types of tool settings angle, aspect ratio, spacing, etc. I am also unsure using the enum action is the right call because what it does is just taking into account the distance from initial click to compute an opacity. Instead it might be more interesting to increase or decrease slowly or rapidly by going right or left from the initial click. We'll see. But it's a first step.
2022-08-17 22:46:26 +08:00
case GIMP_MODIFIER_ACTION_TOOL_OPACITY:
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
{
Gimp *gimp = gimp_display_get_gimp (shell->display);
GimpTool *active_tool = tool_manager_get_active (gimp);
app: display the brush outline (or fallback or circle) when resizing. Bypass temporarily the "Show brush outline" settings when resizing on-canvas.
2022-03-15 02:15:43 +08:00
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
if (GIMP_IS_PAINT_TOOL (active_tool))
gimp_paint_tool_force_draw (GIMP_PAINT_TOOL (active_tool), TRUE);
}
case GIMP_MODIFIER_ACTION_MENU:
case GIMP_MODIFIER_ACTION_PANNING:
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
case GIMP_MODIFIER_ACTION_ACTION:
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
case GIMP_MODIFIER_ACTION_NONE:
app: display the brush outline (or fallback or circle) when resizing. Bypass temporarily the "Show brush outline" settings when resizing on-canvas.
2022-03-15 02:15:43 +08:00
gimp_display_shell_set_override_cursor (shell,
(GimpCursorType) GDK_FLEUR);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
break;
app: display the brush outline (or fallback or circle) when resizing. Bypass temporarily the "Show brush outline" settings when resizing on-canvas.
2022-03-15 02:15:43 +08:00
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
static void
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
gimp_display_shell_stop_scrolling (GimpDisplayShell *shell,
const GdkEvent *event)
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
{
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
gimp_display_shell_unset_override_cursor (shell);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
switch (shell->mod_action)
app: display the brush outline (or fallback or circle) when resizing. Bypass temporarily the "Show brush outline" settings when resizing on-canvas.
2022-03-15 02:15:43 +08:00
{
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
case GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE:
app: new modifier action to set brush size diameter. Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the brush size on-canvas, starting from center to border. The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size from one border to another.
2022-08-12 06:18:22 +08:00
case GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE:
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
{
app: remove GIMP_MODIFIER_ACTION_BRUSH_SIZE, change defaults and labels. * The relative brush size change was not implemented anyway. Maybe later. * Also changing the defaults to GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE which I think might be the most understandable size variant. * Finally re-label "Rotate" to "Rotate View" as per Aryeom's feedback because just "Rotate" is indeed confusing as it could mean several different actions in GIMP.
2022-08-12 07:41:07 +08:00
Gimp *gimp = gimp_display_get_gimp (shell->display);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
GimpTool *active_tool = tool_manager_get_active (gimp);
app: display the brush outline (or fallback or circle) when resizing. Bypass temporarily the "Show brush outline" settings when resizing on-canvas.
2022-03-15 02:15:43 +08:00
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
if (GIMP_IS_PAINT_TOOL (active_tool))
gimp_paint_tool_force_draw (GIMP_PAINT_TOOL (active_tool), FALSE);
}
break;
default:
break;
app: display the brush outline (or fallback or circle) when resizing. Bypass temporarily the "Show brush outline" settings when resizing on-canvas.
2022-03-15 02:15:43 +08:00
}
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
shell->mod_action = GIMP_MODIFIER_ACTION_NONE;
Issue #1531 - Zooming with mouse movement should keep track of original point When Control-Button2-Zooming, remember the start point, pass it to gimp_display_shell_scale_drag() and force gimp_display_shell_scale() to zoom around that point by passing GIMP_ZOOM_FOCUS_POINTER and faking the point using gimp_display_shell_push_zoom_focus_pointer_pos().
2018-06-04 17:42:02 +08:00
shell->scroll_start_x = 0;
shell->scroll_start_y = 0;
Bug 55367 - Rotated view of the canvas (view is rotated, not image contents) First version of display rotation, inspired by gimp-painter. The rotation always happens around the image's center. The only "UI" for rotating is currently shift+middle-drag and shift+space-drag. Control constrains the angle to 15 degrees and is currently the only way to go back to "no rotation".
2013-04-19 22:22:19 +08:00
shell->scroll_last_x = 0;
shell->scroll_last_y = 0;
shell->rotate_drag_angle = 0.0;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
/* We may have ungrabbed the pointer when space was released while
* mouse was down, to be able to catch a GDK_BUTTON_RELEASE event.
*/
app: make input devices, grabs and therefore generally tools work again - add new "device from event" apparatus that works on GTK+ 3.x - fix the active device selection mechanism - use the new device grabbing functions - make sure we don't process events while we have a grab on another device - compensate for some really obscure (and likely broken) behavior of XI2, it feels like we are the first real users...
2011-02-27 23:38:51 +08:00
if (shell->grab_pointer)
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
gimp_display_shell_pointer_ungrab (shell, event);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: factor out button-2-motion handling code in GimpDisplayShell less code in the huge gimp_display_shell_canvas_tool_events(). Also fix the rotating cursor in gimp_display_shell_start_scrolling().
2017-05-12 03:31:41 +08:00
static void
gimp_display_shell_handle_scrolling (GimpDisplayShell *shell,
GdkModifierType state,
gint x,
gint y)
{
app: new modifier action to set brush size diameter. Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the brush size on-canvas, starting from center to border. The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size from one border to another.
2022-08-12 06:18:22 +08:00
GimpModifierAction mod_action = shell->mod_action;
gboolean constrain = FALSE;
gboolean size_update_pos = TRUE;
gdouble size_multiplier = 1.0;
app: factor out button-2-motion handling code in GimpDisplayShell less code in the huge gimp_display_shell_canvas_tool_events(). Also fix the rotating cursor in gimp_display_shell_start_scrolling().
2017-05-12 03:31:41 +08:00
app: fix space actions on canvas. Space: panning Ctrl-space: zooming Shift-space: rotating Ctrl-shift-space: constrained rotating Note that these are still hardcoded, unlike the actions through modifiers + pointer buttons.
2022-08-12 03:07:43 +08:00
if (mod_action == GIMP_MODIFIER_ACTION_NONE && shell->space_release_pending)
{
state &= gimp_get_all_modifiers_mask ();
if (state == 0)
mod_action = GIMP_MODIFIER_ACTION_PANNING;
else if (state == gimp_get_extend_selection_mask ())
mod_action = GIMP_MODIFIER_ACTION_ROTATING;
else if (state == (gimp_get_extend_selection_mask () | GDK_CONTROL_MASK))
mod_action = GIMP_MODIFIER_ACTION_STEP_ROTATING;
else if (state == gimp_get_toggle_behavior_mask ())
mod_action = GIMP_MODIFIER_ACTION_ZOOMING;
}
app: fix switching seamlessly from constrained to unconstrained canvas… … rotation and back.
2022-08-12 07:03:56 +08:00
else if (mod_action == GIMP_MODIFIER_ACTION_ROTATING ||
mod_action == GIMP_MODIFIER_ACTION_STEP_ROTATING)
{
state &= gimp_get_all_modifiers_mask ();
/* Allow switching from the constrained to non-constrained
* variant, back and forth, during a single scroll.
*/
if (state == gimp_get_extend_selection_mask ())
mod_action = GIMP_MODIFIER_ACTION_ROTATING;
else if (state == (gimp_get_extend_selection_mask () | GDK_CONTROL_MASK))
mod_action = GIMP_MODIFIER_ACTION_STEP_ROTATING;
}
app: fix space actions on canvas. Space: panning Ctrl-space: zooming Shift-space: rotating Ctrl-shift-space: constrained rotating Note that these are still hardcoded, unlike the actions through modifiers + pointer buttons.
2022-08-12 03:07:43 +08:00
switch (mod_action)
app: factor out button-2-motion handling code in GimpDisplayShell less code in the huge gimp_display_shell_canvas_tool_events(). Also fix the rotating cursor in gimp_display_shell_start_scrolling().
2017-05-12 03:31:41 +08:00
{
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
case GIMP_MODIFIER_ACTION_STEP_ROTATING:
constrain = TRUE;
case GIMP_MODIFIER_ACTION_ROTATING:
app: factor out button-2-motion handling code in GimpDisplayShell less code in the huge gimp_display_shell_canvas_tool_events(). Also fix the rotating cursor in gimp_display_shell_start_scrolling().
2017-05-12 03:31:41 +08:00
gimp_display_shell_rotate_drag (shell,
shell->scroll_last_x,
shell->scroll_last_y,
x,
y,
constrain);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
break;
case GIMP_MODIFIER_ACTION_ZOOMING:
app: factor out button-2-motion handling code in GimpDisplayShell less code in the huge gimp_display_shell_canvas_tool_events(). Also fix the rotating cursor in gimp_display_shell_start_scrolling().
2017-05-12 03:31:41 +08:00
gimp_display_shell_scale_drag (shell,
Issue #1531 - Zooming with mouse movement should keep track of original point When Control-Button2-Zooming, remember the start point, pass it to gimp_display_shell_scale_drag() and force gimp_display_shell_scale() to zoom around that point by passing GIMP_ZOOM_FOCUS_POINTER and faking the point using gimp_display_shell_push_zoom_focus_pointer_pos().
2018-06-04 17:42:02 +08:00
shell->scroll_start_x,
shell->scroll_start_y,
app: factor out button-2-motion handling code in GimpDisplayShell less code in the huge gimp_display_shell_canvas_tool_events(). Also fix the rotating cursor in gimp_display_shell_start_scrolling().
2017-05-12 03:31:41 +08:00
shell->scroll_last_x - x,
shell->scroll_last_y - y);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
break;
app: new modifier action to set brush size diameter. Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the brush size on-canvas, starting from center to border. The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size from one border to another.
2022-08-12 06:18:22 +08:00
case GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE:
size_multiplier = 2.0;
size_update_pos = FALSE;
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
case GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE:
app: new double action "tools-mypaint-brush-pixel-size-set", used as… … new action_pixel_size of GimpMyBrushTool. MyPaint brush tool clearly shows the limits of my trick to have some enum actions work with absolute values whereas others work with per-mille values between the property min and max. Indeed firstly MyBrush's "radius" value is logarithmic and can be negative. Since the enum trick relies on the fact that negative values are the semantic enumerated constants, it's broken in such case. The second issue is that while it was acceptable to use int size for most paint tools (even though they were double), here radius only goes from -2.0 to 6.0; so using int values only would leave us with jumping brush sizes. So now I create a proper double action which simply takes pixel size and use this from the on-canvas brush size changing. No weird trick, no int or sign limitations. I also add a new optional action_pixel_size in GimpToolControl. Note: I'm also updating a bit the logic for the MyPaint brush outline function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit through mypaint-brush.c code in libmypaint, I am not sure at all we need to use the offset_by_random like this. And really this shown outline seems more indicative than anything else when I see the actual size printed by the various brushes. Finally here it was counter-productive as I needed to get easily the logarithmic radius from the pointer interaction on canvas.
2022-04-03 04:29:46 +08:00
{
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
GimpDisplay *display = shell->display;
Gimp *gimp = gimp_display_get_gimp (display);
GimpTool *active_tool = tool_manager_get_active (gimp);
const gchar *action;
gint size;
/* Size in image pixels: distance between start and current
* position.
*/
size = (gint) (sqrt (pow ((x - shell->scroll_start_x) / shell->scale_x, 2) +
app: new modifier action to set brush size diameter. Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the brush size on-canvas, starting from center to border. The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size from one border to another.
2022-08-12 06:18:22 +08:00
pow ((y - shell->scroll_start_y) / shell->scale_y, 2)));
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
/* TODO: different logics with "lock brush to view". */
/* TODO 2: scale aware? */
action = gimp_tool_control_get_action_pixel_size (active_tool->control);
app: new double action "tools-mypaint-brush-pixel-size-set", used as… … new action_pixel_size of GimpMyBrushTool. MyPaint brush tool clearly shows the limits of my trick to have some enum actions work with absolute values whereas others work with per-mille values between the property min and max. Indeed firstly MyBrush's "radius" value is logarithmic and can be negative. Since the enum trick relies on the fact that negative values are the semantic enumerated constants, it's broken in such case. The second issue is that while it was acceptable to use int size for most paint tools (even though they were double), here radius only goes from -2.0 to 6.0; so using int values only would leave us with jumping brush sizes. So now I create a proper double action which simply takes pixel size and use this from the on-canvas brush size changing. No weird trick, no int or sign limitations. I also add a new optional action_pixel_size in GimpToolControl. Note: I'm also updating a bit the logic for the MyPaint brush outline function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit through mypaint-brush.c code in libmypaint, I am not sure at all we need to use the offset_by_random like this. And really this shown outline seems more indicative than anything else when I see the actual size printed by the various brushes. Finally here it was counter-productive as I needed to get easily the logarithmic radius from the pointer interaction on canvas.
2022-04-03 04:29:46 +08:00
if (action)
{
GimpImageWindow *window = gimp_display_shell_get_window (shell);
GimpUIManager *manager = gimp_image_window_get_ui_manager (window);
gimp_display_shell_activate_action (manager, action,
app: new modifier action to set brush size diameter. Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the brush size on-canvas, starting from center to border. The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size from one border to another.
2022-08-12 06:18:22 +08:00
g_variant_new_double ((gdouble) size * size_multiplier));
if (size_update_pos)
{
GimpCoords display_coords;
GimpCoords coords;
display_coords.x = shell->scroll_start_x + (x - shell->scroll_start_x) / 2;
display_coords.y = shell->scroll_start_y + (y - shell->scroll_start_y) / 2;
gimp_display_shell_untransform_event_coords (shell,
&display_coords, &coords,
NULL);
gimp_tool_oper_update (active_tool, &coords, 0, TRUE, display);
}
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
}
else
{
action = gimp_tool_control_get_action_size (active_tool->control);
if (action)
{
GimpImageWindow *window = gimp_display_shell_get_window (shell);
GimpUIManager *manager = gimp_image_window_get_ui_manager (window);
/* Special trick with these enum actions. If using any
* positive value, we get the GIMP_ACTION_SELECT_SET behavior
* which sets to the given value.
*/
gimp_display_shell_activate_action (manager, action,
g_variant_new_int32 (size));
}
app: new double action "tools-mypaint-brush-pixel-size-set", used as… … new action_pixel_size of GimpMyBrushTool. MyPaint brush tool clearly shows the limits of my trick to have some enum actions work with absolute values whereas others work with per-mille values between the property min and max. Indeed firstly MyBrush's "radius" value is logarithmic and can be negative. Since the enum trick relies on the fact that negative values are the semantic enumerated constants, it's broken in such case. The second issue is that while it was acceptable to use int size for most paint tools (even though they were double), here radius only goes from -2.0 to 6.0; so using int values only would leave us with jumping brush sizes. So now I create a proper double action which simply takes pixel size and use this from the on-canvas brush size changing. No weird trick, no int or sign limitations. I also add a new optional action_pixel_size in GimpToolControl. Note: I'm also updating a bit the logic for the MyPaint brush outline function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit through mypaint-brush.c code in libmypaint, I am not sure at all we need to use the offset_by_random like this. And really this shown outline seems more indicative than anything else when I see the actual size printed by the various brushes. Finally here it was counter-productive as I needed to get easily the logarithmic radius from the pointer interaction on canvas.
2022-04-03 04:29:46 +08:00
}
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
}
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
break;
app: add a modifier action for opacity change. Opacity and brush size are among the 2 most common tool options which people might want to often change, though we should likely later add all other common types of tool settings angle, aspect ratio, spacing, etc. I am also unsure using the enum action is the right call because what it does is just taking into account the distance from initial click to compute an opacity. Instead it might be more interesting to increase or decrease slowly or rapidly by going right or left from the initial click. We'll see. But it's a first step.
2022-08-17 22:46:26 +08:00
case GIMP_MODIFIER_ACTION_TOOL_OPACITY:
{
GimpDisplay *display = shell->display;
Gimp *gimp = gimp_display_get_gimp (display);
GimpTool *active_tool = tool_manager_get_active (gimp);
const gchar *action;
gint size;
/* Size in image pixels: distance between start and current
* position.
*/
size = (gint) (sqrt (pow ((x - shell->scroll_start_x) / shell->scale_x, 2) +
pow ((y - shell->scroll_start_y) / shell->scale_y, 2)));
action = gimp_tool_control_get_action_opacity (active_tool->control);
if (action)
{
GimpImageWindow *window = gimp_display_shell_get_window (shell);
GimpUIManager *manager = gimp_image_window_get_ui_manager (window);
/* Special trick with these enum actions. If using any
* positive value, we get the GIMP_ACTION_SELECT_SET behavior
* which sets to the given value.
*/
gimp_display_shell_activate_action (manager, action,
g_variant_new_int32 (size));
}
}
break;
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
case GIMP_MODIFIER_ACTION_PANNING:
app: factor out button-2-motion handling code in GimpDisplayShell less code in the huge gimp_display_shell_canvas_tool_events(). Also fix the rotating cursor in gimp_display_shell_start_scrolling().
2017-05-12 03:31:41 +08:00
gimp_display_shell_scroll (shell,
shell->scroll_last_x - x,
shell->scroll_last_y - y);
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
break;
case GIMP_MODIFIER_ACTION_LAYER_PICKING:
/* Do nothing. We only pick the layer on click. */
case GIMP_MODIFIER_ACTION_MENU:
case GIMP_MODIFIER_ACTION_NONE:
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
case GIMP_MODIFIER_ACTION_ACTION:
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
break;
app: factor out button-2-motion handling code in GimpDisplayShell less code in the huge gimp_display_shell_canvas_tool_events(). Also fix the rotating cursor in gimp_display_shell_start_scrolling().
2017-05-12 03:31:41 +08:00
}
shell->scroll_last_x = x;
shell->scroll_last_y = y;
}
app: Implement canvas support for touchpad gesture rotation by pinch
2022-03-17 05:59:20 +08:00
static void
gimp_display_shell_rotate_gesture_maybe_get_state (GtkGestureRotate *gesture,
GdkEventSequence *sequence,
guint *maybe_out_state)
{
/* The only way to get any access to any data about events handled by the
* GtkGestureRotate is through its last_event. The set of events handled by
* GtkGestureRotate is not fully defined so we can't guarantee that last_event
* will be of event type that has a state field (though touch and gesture
* events do have that).
*
* Usually this would not be a problem, but when handling a gesture we don't
* want to repeatedly switch between a valid state and its default value if
* last_event happens to not have it. Thus we store the last valid state
* and only update it if we get a valid state from last_event.
*/
guint state = 0;
const GdkEvent *last_event;
last_event = gtk_gesture_get_last_event (GTK_GESTURE (gesture), sequence);
if (last_event == NULL)
return;
if (gdk_event_get_state (last_event, &state))
*maybe_out_state = state;
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
static void
gimp_display_shell_space_pressed (GimpDisplayShell *shell,
app: sprinkle const qualifiers in the tool event callback functions
2011-06-01 05:17:29 +08:00
const GdkEvent *event)
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
{
Gimp *gimp = gimp_display_get_gimp (shell->display);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
if (shell->space_release_pending || shell->mod_action != GIMP_MODIFIER_ACTION_NONE)
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
return;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: fix space actions on canvas. Space: panning Ctrl-space: zooming Shift-space: rotating Ctrl-shift-space: constrained rotating Note that these are still hardcoded, unlike the actions through modifiers + pointer buttons.
2022-08-12 03:07:43 +08:00
shell->space_release_pending = TRUE;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
switch (shell->display->config->space_bar_action)
{
case GIMP_SPACE_BAR_ACTION_NONE:
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
break;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GIMP_SPACE_BAR_ACTION_PAN:
{
app: GimpDeviceManager refactoring part two - change gimp_devices_get_list() to gimp_devices_get_manager() - remove gimp_devices_get_current() - let GimpDeviceStatus connect to the manager's "notify::current-device" directly and remove device status updating code from gui.c - cleanup in gimpdevices.c
2011-02-28 21:37:00 +08:00
GimpDeviceManager *manager;
GimpDeviceInfo *current_device;
GimpCoords coords;
Bug 55367 - Rotated view of the canvas (view is rotated, not image contents) First version of display rotation, inspired by gimp-painter. The rotation always happens around the image's center. The only "UI" for rotating is currently shift+middle-drag and shift+space-drag. Control constrains the angle to 15 degrees and is currently the only way to go back to "no rotation".
2013-04-19 22:22:19 +08:00
GdkModifierType state = 0;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
app: GimpDeviceManager refactoring part two - change gimp_devices_get_list() to gimp_devices_get_manager() - remove gimp_devices_get_current() - let GimpDeviceStatus connect to the manager's "notify::current-device" directly and remove device status updating code from gui.c - cleanup in gimpdevices.c
2011-02-28 21:37:00 +08:00
manager = gimp_devices_get_manager (gimp);
current_device = gimp_device_manager_get_current_device (manager);
gimp_device_info_get_device_coords (current_device,
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
gtk_widget_get_window (shell->canvas),
&coords);
Bug 55367 - Rotated view of the canvas (view is rotated, not image contents) First version of display rotation, inspired by gimp-painter. The rotation always happens around the image's center. The only "UI" for rotating is currently shift+middle-drag and shift+space-drag. Control constrains the angle to 15 degrees and is currently the only way to go back to "no rotation".
2013-04-19 22:22:19 +08:00
gdk_event_get_state (event, &state);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
Bug 55367 - Rotated view of the canvas (view is rotated, not image contents) First version of display rotation, inspired by gimp-painter. The rotation always happens around the image's center. The only "UI" for rotating is currently shift+middle-drag and shift+space-drag. Control constrains the angle to 15 degrees and is currently the only way to go back to "no rotation".
2013-04-19 22:22:19 +08:00
gimp_display_shell_start_scrolling (shell, event, state,
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
coords.x, coords.y);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
break;
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GIMP_SPACE_BAR_ACTION_MOVE:
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
GimpTool *active_tool = tool_manager_get_active (gimp);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
if (active_tool || ! GIMP_IS_MOVE_TOOL (active_tool))
{
GdkModifierType state;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
shell->space_shaded_tool =
gimp_object_get_name (active_tool->tool_info);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
gimp_context_set_tool (gimp_get_user_context (gimp),
gimp_get_tool_info (gimp, "gimp-move-tool"));
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
gdk_event_get_state (event, &state);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
gimp_display_shell_update_focus (shell, TRUE,
NULL, state);
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
break;
}
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
static void
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
gimp_display_shell_released (GimpDisplayShell *shell,
const GdkEvent *event,
const GimpCoords *image_coords)
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
{
Gimp *gimp = gimp_display_get_gimp (shell->display);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
if (! shell->space_release_pending &&
! shell->button1_release_pending)
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
return;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
switch (shell->display->config->space_bar_action)
{
case GIMP_SPACE_BAR_ACTION_NONE:
break;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GIMP_SPACE_BAR_ACTION_PAN:
app: get rid of server grabs for almost all canvas interaction Because it's generally the right thing to do, and server grabs broke badly with input devices / client side windows. gimpdisplayshell-grab.c: change logic to only server-grab if an event is passed to the pointer grab/ungrab functions, but always use gtk_grab_add/remove() which is sufficient in most cases. gimpdisplayshell-tool-events.c: have the grab functions grab the server only for space-bar scrolling and do all tool interaction, including ruler clicks, with gtk_grab_add/remove(). Refactor things a bit to also use the grab API for button-2 scrolling. gimpdeviceinfo-coords.c: transform the event's coords to the canvas' coordinate system, they might come from a ruler now. This fixes the following bugs: Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed... Bug 644351 - Gimp misses some strokes especially when drawing fast Bug 645747 - Gimp is now unusable on xfce4
2011-12-10 03:20:02 +08:00
gimp_display_shell_stop_scrolling (shell, event);
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
break;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
case GIMP_SPACE_BAR_ACTION_MOVE:
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
if (shell->space_shaded_tool)
{
gimp_context_set_tool (gimp_get_user_context (gimp),
gimp_get_tool_info (gimp,
shell->space_shaded_tool));
shell->space_shaded_tool = NULL;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
if (gtk_widget_has_focus (shell->canvas))
{
GdkModifierType state;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
gdk_event_get_state (event, &state);
app: completely ignore focus change events while we have a grab in order to be safe against whatever windowing system / event manager depending event order. Also properly update the tool's state after a button reelease, and after a space release.
2011-04-07 03:35:29 +08:00
Bug 699100 - Move tool: space-bar inhibits function of Move tool Don't try to switch to the move tool if the move tool is already active. Also never bail out early from gimp_display_shell_space_pressed() so we don't end up in an inconsistent state.
2013-04-28 21:28:18 +08:00
gimp_display_shell_update_focus (shell, TRUE,
image_coords, state);
}
else
{
gimp_display_shell_update_focus (shell, FALSE,
image_coords, 0);
}
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
break;
}
Bug 724692 - Canvas rotation stuck with specific order of actions. Commit b279c2d217 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.
2018-04-14 21:36:08 +08:00
shell->space_release_pending = FALSE;
shell->button1_release_pending = FALSE;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
app: gimpdisplayshell-tool-events.c: move Tab handling to a utility function instead of having separate utility functions for the different functions triggered by various Tab combinations.
2011-05-31 15:24:14 +08:00
static gboolean
app: sprinkle const qualifiers in the tool event callback functions
2011-06-01 05:17:29 +08:00
gimp_display_shell_tab_pressed (GimpDisplayShell *shell,
const GdkEventKey *kevent)
app: gimpdisplayshell-tool-events.c: move Tab handling to a utility function instead of having separate utility functions for the different functions triggered by various Tab combinations.
2011-05-31 15:24:14 +08:00
{
GimpImageWindow *window = gimp_display_shell_get_window (shell);
GimpUIManager *manager = gimp_image_window_get_ui_manager (window);
GimpImage *image = gimp_display_get_image (shell->display);
if (kevent->state & GDK_CONTROL_MASK)
{
if (image && ! gimp_image_is_empty (image))
{
app: make sure overlay widgets are keyboard navigatable Tab key events are not handled by the widget itself, they are supposed to bubble up until they hit the generic keyboard navigation code that knows about the focus chain, therefore: gimp_display_shell_canvas_tool_events(): if an overlay widget is focussed, don't handle Tab events and toggle dock visibility. Instead, simply bail out with FALSE so the event reaches te keyboard navigation code. Also treat GDK_KEY_KP_Tab like GDK_KEY_Tab all over the place.
2013-06-08 21:27:14 +08:00
if (kevent->keyval == GDK_KEY_Tab ||
kevent->keyval == GDK_KEY_KP_Tab)
app: undeprecate gimpdisplayshell-layer-select
2018-07-03 21:51:45 +08:00
gimp_display_shell_layer_select_init (shell, (GdkEvent *) kevent,
1);
app: gimpdisplayshell-tool-events.c: move Tab handling to a utility function instead of having separate utility functions for the different functions triggered by various Tab combinations.
2011-05-31 15:24:14 +08:00
else
app: undeprecate gimpdisplayshell-layer-select
2018-07-03 21:51:45 +08:00
gimp_display_shell_layer_select_init (shell, (GdkEvent *) kevent,
-1);
app: gimpdisplayshell-tool-events.c: move Tab handling to a utility function instead of having separate utility functions for the different functions triggered by various Tab combinations.
2011-05-31 15:24:14 +08:00
return TRUE;
}
}
else if (kevent->state & GDK_MOD1_MASK)
{
if (image)
{
app: make sure overlay widgets are keyboard navigatable Tab key events are not handled by the widget itself, they are supposed to bubble up until they hit the generic keyboard navigation code that knows about the focus chain, therefore: gimp_display_shell_canvas_tool_events(): if an overlay widget is focussed, don't handle Tab events and toggle dock visibility. Instead, simply bail out with FALSE so the event reaches te keyboard navigation code. Also treat GDK_KEY_KP_Tab like GDK_KEY_Tab all over the place.
2013-06-08 21:27:14 +08:00
if (kevent->keyval == GDK_KEY_Tab ||
kevent->keyval == GDK_KEY_KP_Tab)
app: gimpdisplayshell-tool-events.c: move Tab handling to a utility function instead of having separate utility functions for the different functions triggered by various Tab combinations.
2011-05-31 15:24:14 +08:00
gimp_ui_manager_activate_action (manager, "windows",
"windows-show-display-next");
else
gimp_ui_manager_activate_action (manager, "windows",
"windows-show-display-previous");
return TRUE;
}
}
else
{
gimp_ui_manager_activate_action (manager, "windows",
"windows-hide-docks");
return TRUE;
}
return FALSE;
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
static void
gimp_display_shell_update_focus (GimpDisplayShell *shell,
app: add "gboolean focus_in" to gimp_display_shell_update_focus() and use it to update the tool's state also when the canvas gets a FOCUS_OUT.
2011-04-04 01:01:13 +08:00
gboolean focus_in,
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
const GimpCoords *image_coords,
GdkModifierType state)
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
Gimp *gimp = gimp_display_get_gimp (shell->display);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: add "gboolean focus_in" to gimp_display_shell_update_focus() and use it to update the tool's state also when the canvas gets a FOCUS_OUT.
2011-04-04 01:01:13 +08:00
if (focus_in)
{
tool_manager_focus_display_active (gimp, shell->display);
tool_manager_modifier_state_active (gimp, state, shell->display);
}
else
{
tool_manager_focus_display_active (gimp, NULL);
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
if (image_coords)
tool_manager_oper_update_active (gimp,
image_coords, state,
shell->proximity,
shell->display);
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
static void
gimp_display_shell_update_cursor (GimpDisplayShell *shell,
const GimpCoords *display_coords,
const GimpCoords *image_coords,
GdkModifierType state,
gboolean update_software_cursor)
{
GimpDisplay *display = shell->display;
Gimp *gimp = gimp_display_get_gimp (display);
GimpImage *image = gimp_display_get_image (display);
GimpTool *active_tool;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
if (! shell->display->config->cursor_updating)
return;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
active_tool = tool_manager_get_active (gimp);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
if (active_tool && image)
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
{
if ((! gimp_image_is_empty (image) ||
gimp_tool_control_get_handle_empty_image (active_tool->control)) &&
! (state & (GDK_BUTTON1_MASK |
GDK_BUTTON2_MASK |
GDK_BUTTON3_MASK)))
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
tool_manager_cursor_update_active (gimp,
image_coords, state,
display);
}
else if (gimp_image_is_empty (image) &&
! gimp_tool_control_get_handle_empty_image (active_tool->control))
{
gimp_display_shell_set_cursor (shell,
GIMP_CURSOR_MOUSE,
gimp_tool_control_get_tool_cursor (active_tool->control),
GIMP_CURSOR_MODIFIER_BAD);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
}
else
{
gimp_display_shell_set_cursor (shell,
GIMP_CURSOR_MOUSE,
GIMP_TOOL_CURSOR_NONE,
GIMP_CURSOR_MODIFIER_BAD);
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
if (update_software_cursor)
{
GimpCursorPrecision precision = GIMP_CURSOR_PRECISION_PIXEL_CENTER;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
if (active_tool)
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
precision = gimp_tool_control_get_precision (active_tool->control);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
gimp_display_shell_update_software_cursor (shell,
precision,
(gint) display_coords->x,
(gint) display_coords->y,
image_coords->x,
image_coords->y);
}
}
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: add gimp_display_shell_initialize_tool() in tool-events.c so another big block of logic is gone from "the huge function".
2011-04-04 00:27:03 +08:00
static gboolean
gimp_display_shell_initialize_tool (GimpDisplayShell *shell,
const GimpCoords *image_coords,
GdkModifierType state)
{
GimpDisplay *display = shell->display;
GimpImage *image = gimp_display_get_image (display);
Gimp *gimp = gimp_display_get_gimp (display);
gboolean initialized = FALSE;
GimpTool *active_tool;
active_tool = tool_manager_get_active (gimp);
if (active_tool &&
(! gimp_image_is_empty (image) ||
gimp_tool_control_get_handle_empty_image (active_tool->control)))
{
app: GimpTool multi-drawable aware. Right now I don't change the logics of any of the tools, except that the GimpTool class now stores a list of drawables instead of a single drawable. This can be later used on a case-by-case basis to make various tools actually work on multiple drawables.
2020-05-25 17:30:31 +08:00
/* initialize the current tool if it has no drawables */
if (! active_tool->drawables)
app: add gimp_display_shell_initialize_tool() in tool-events.c so another big block of logic is gone from "the huge function".
2011-04-04 00:27:03 +08:00
{
initialized = tool_manager_initialize_active (gimp, display);
}
app: GimpTool multi-drawable aware. Right now I don't change the logics of any of the tools, except that the GimpTool class now stores a list of drawables instead of a single drawable. This can be later used on a case-by-case basis to make various tools actually work on multiple drawables.
2020-05-25 17:30:31 +08:00
else if (! gimp_image_equal_selected_drawables (image, active_tool->drawables) &&
Bug 683462 - cropping with rectangular select tool leaves misaligned... Reset the tool on image changes again, but not if only the active drawable changes, so keep bug #678890 closed: Introduce new dirty flag GIMP_DIRTY_ACTIVE_DRAWABLE and set it on all tools' dirty_mask except for rect select. Check the new flag when reseting the active tool because of a drawable change.
2012-09-07 05:55:35 +08:00
(! gimp_tool_control_get_preserve (active_tool->control) &&
(gimp_tool_control_get_dirty_mask (active_tool->control) &
GIMP_DIRTY_ACTIVE_DRAWABLE)))
app: add gimp_display_shell_initialize_tool() in tool-events.c so another big block of logic is gone from "the huge function".
2011-04-04 00:27:03 +08:00
{
Bug 776370 - Changing active layer breaks the GEGL operation dialog 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().
2017-01-23 07:00:03 +08:00
GimpProcedure *procedure = g_object_get_data (G_OBJECT (active_tool),
"gimp-gegl-procedure");
app: GimpTool multi-drawable aware. Right now I don't change the logics of any of the tools, except that the GimpTool class now stores a list of drawables instead of a single drawable. This can be later used on a case-by-case basis to make various tools actually work on multiple drawables.
2020-05-25 17:30:31 +08:00
if (image == gimp_item_get_image (GIMP_ITEM (active_tool->drawables->data)))
Bug 776370 - Changing active layer breaks the GEGL operation dialog 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().
2017-01-23 07:00:03 +08:00
{
/* When changing between drawables if the *same* image,
Issue #1180 - Warp tool aborts changes to layer A when ... ... 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.
2018-09-30 00:25:51 +08:00
* stop the tool using its dirty action, so it doesn't
* get committed on tool change, in case its dirty action
* is HALT. This is a pure "probably better this way"
Bug 776370 - Changing active layer breaks the GEGL operation dialog 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().
2017-01-23 07:00:03 +08:00
* decision because the user is likely changing their
Issue #1180 - Warp tool aborts changes to layer A when ... ... 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.
2018-09-30 00:25:51 +08:00
* mind or was simply on the wrong layer. See bug #776370.
*
* See also issues #1180 and #1202 for cases where we
* actually *don't* want to halt the tool here, but rather
* commit it, hence the use of the tool's dirty action.
Bug 776370 - Changing active layer breaks the GEGL operation dialog 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().
2017-01-23 07:00:03 +08:00
*/
Issue #1180 - Warp tool aborts changes to layer A when ... ... 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.
2018-09-30 00:25:51 +08:00
tool_manager_control_active (
gimp,
gimp_tool_control_get_dirty_action (active_tool->control),
active_tool->display);
Bug 776370 - Changing active layer breaks the GEGL operation dialog 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().
2017-01-23 07:00:03 +08:00
}
if (procedure)
{
/* We can't just recreate an operation tool, we must
* make sure the right stuff gets set on it, so
* re-activate the procedure that created it instead of
* just calling gimp_context_tool_changed(). See
* GimpGeglProcedure and bug #776370.
*/
GimpImageWindow *window;
GimpUIManager *manager;
window = gimp_display_shell_get_window (shell);
manager = gimp_image_window_get_ui_manager (window);
gimp_filter_history_add (gimp, procedure);
gimp_ui_manager_activate_action (manager, "filters",
"filters-reshow");
app: avoid double-initialization of operation tools when changing layers 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.
2018-09-30 02:24:28 +08:00
/* the procedure already initialized the tool; don't
* reinitialize it below, since this can lead to errors.
*/
initialized = TRUE;
Bug 776370 - Changing active layer breaks the GEGL operation dialog 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().
2017-01-23 07:00:03 +08:00
}
else
{
/* create a new one, deleting the current */
gimp_context_tool_changed (gimp_get_user_context (gimp));
}
app: add gimp_display_shell_initialize_tool() in tool-events.c so another big block of logic is gone from "the huge function".
2011-04-04 00:27:03 +08:00
/* make sure the newly created tool has the right state */
app: add "gboolean focus_in" to gimp_display_shell_update_focus() and use it to update the tool's state also when the canvas gets a FOCUS_OUT.
2011-04-04 01:01:13 +08:00
gimp_display_shell_update_focus (shell, TRUE, image_coords, state);
app: add gimp_display_shell_initialize_tool() in tool-events.c so another big block of logic is gone from "the huge function".
2011-04-04 00:27:03 +08:00
app: avoid double-initialization of operation tools when changing layers 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.
2018-09-30 02:24:28 +08:00
if (! initialized)
initialized = tool_manager_initialize_active (gimp, display);
}
else
{
initialized = TRUE;
app: add gimp_display_shell_initialize_tool() in tool-events.c so another big block of logic is gone from "the huge function".
2011-04-04 00:27:03 +08:00
}
}
return initialized;
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
static void
gimp_display_shell_get_event_coords (GimpDisplayShell *shell,
app: sprinkle const qualifiers in the tool event callback functions
2011-06-01 05:17:29 +08:00
const GdkEvent *event,
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
GimpCoords *display_coords,
GdkModifierType *state,
guint32 *time)
{
app: GimpDeviceManager refactoring part two - change gimp_devices_get_list() to gimp_devices_get_manager() - remove gimp_devices_get_current() - let GimpDeviceStatus connect to the manager's "notify::current-device" directly and remove device status updating code from gui.c - cleanup in gimpdevices.c
2011-02-28 21:37:00 +08:00
Gimp *gimp = gimp_display_get_gimp (shell->display);
GimpDeviceManager *manager;
GimpDeviceInfo *current_device;
manager = gimp_devices_get_manager (gimp);
current_device = gimp_device_manager_get_current_device (manager);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: GimpDeviceManager refactoring part two - change gimp_devices_get_list() to gimp_devices_get_manager() - remove gimp_devices_get_current() - let GimpDeviceStatus connect to the manager's "notify::current-device" directly and remove device status updating code from gui.c - cleanup in gimpdevices.c
2011-02-28 21:37:00 +08:00
gimp_device_info_get_event_coords (current_device,
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
gtk_widget_get_window (shell->canvas),
event,
display_coords);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: GimpDeviceManager refactoring part two - change gimp_devices_get_list() to gimp_devices_get_manager() - remove gimp_devices_get_current() - let GimpDeviceStatus connect to the manager's "notify::current-device" directly and remove device status updating code from gui.c - cleanup in gimpdevices.c
2011-02-28 21:37:00 +08:00
gimp_device_info_get_event_state (current_device,
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
gtk_widget_get_window (shell->canvas),
event,
state);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
*time = gdk_event_get_time (event);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
}
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
static void
gimp_display_shell_untransform_event_coords (GimpDisplayShell *shell,
const GimpCoords *display_coords,
GimpCoords *image_coords,
gboolean *update_software_cursor)
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
{
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
Gimp *gimp = gimp_display_get_gimp (shell->display);
GimpTool *active_tool;
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
/* GimpCoords passed to tools are ALWAYS in image coordinates */
gimp_display_shell_untransform_coords (shell,
display_coords,
image_coords);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
active_tool = tool_manager_get_active (gimp);
app: split tool event handling out into an own file it was simply getting too hairy in the callbacks.c file.
2011-02-23 12:21:06 +08:00
app: clean up static functions in the new tool-events.c file
2011-02-23 13:22:24 +08:00
if (active_tool && gimp_tool_control_get_snap_to (active_tool->control))
{
gint x, y, width, height;
gimp_tool_control_get_snap_offsets (active_tool->control,
&x, &y, &width, &height);
if (gimp_display_shell_snap_coords (shell,
image_coords,
x, y, width, height))
{
if (update_software_cursor)
*update_software_cursor = TRUE;
}
}
}
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
static void
app: new double action "tools-mypaint-brush-pixel-size-set", used as… … new action_pixel_size of GimpMyBrushTool. MyPaint brush tool clearly shows the limits of my trick to have some enum actions work with absolute values whereas others work with per-mille values between the property min and max. Indeed firstly MyBrush's "radius" value is logarithmic and can be negative. Since the enum trick relies on the fact that negative values are the semantic enumerated constants, it's broken in such case. The second issue is that while it was acceptable to use int size for most paint tools (even though they were double), here radius only goes from -2.0 to 6.0; so using int values only would leave us with jumping brush sizes. So now I create a proper double action which simply takes pixel size and use this from the on-canvas brush size changing. No weird trick, no int or sign limitations. I also add a new optional action_pixel_size in GimpToolControl. Note: I'm also updating a bit the logic for the MyPaint brush outline function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit through mypaint-brush.c code in libmypaint, I am not sure at all we need to use the offset_by_random like this. And really this shown outline seems more indicative than anything else when I see the actual size printed by the various brushes. Finally here it was counter-productive as I needed to get easily the logarithmic radius from the pointer interaction on canvas.
2022-04-03 04:29:46 +08:00
gimp_display_shell_activate_action (GimpUIManager *manager,
const gchar *action_desc,
GVariant *value)
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
{
gchar *group_name;
gchar *action_name;
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
g_return_if_fail (action_desc != NULL);
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
group_name = g_strdup (action_desc);
action_name = strchr (group_name, '/');
if (action_name)
{
GimpAction *action;
*action_name++ = '\0';
action = gimp_ui_manager_find_action (manager, group_name, action_name);
if (GIMP_IS_ENUM_ACTION (action) &&
GIMP_ENUM_ACTION (action)->value_variable)
{
app: new double action "tools-mypaint-brush-pixel-size-set", used as… … new action_pixel_size of GimpMyBrushTool. MyPaint brush tool clearly shows the limits of my trick to have some enum actions work with absolute values whereas others work with per-mille values between the property min and max. Indeed firstly MyBrush's "radius" value is logarithmic and can be negative. Since the enum trick relies on the fact that negative values are the semantic enumerated constants, it's broken in such case. The second issue is that while it was acceptable to use int size for most paint tools (even though they were double), here radius only goes from -2.0 to 6.0; so using int values only would leave us with jumping brush sizes. So now I create a proper double action which simply takes pixel size and use this from the on-canvas brush size changing. No weird trick, no int or sign limitations. I also add a new optional action_pixel_size in GimpToolControl. Note: I'm also updating a bit the logic for the MyPaint brush outline function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit through mypaint-brush.c code in libmypaint, I am not sure at all we need to use the offset_by_random like this. And really this shown outline seems more indicative than anything else when I see the actual size printed by the various brushes. Finally here it was counter-productive as I needed to get easily the logarithmic radius from the pointer interaction on canvas.
2022-04-03 04:29:46 +08:00
gimp_action_emit_activate (action, value);
}
else if (GIMP_IS_DOUBLE_ACTION (action))
{
gimp_action_emit_activate (action, value);
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
}
app: now support custom actions as input device button + modifiers. Custom actions are basically any action (currently GtkAction) which can be assigned a shortcut. Now they can also be assigned to an input device button (with modifier or not).
2022-08-16 21:20:58 +08:00
else
{
gimp_action_activate (action);
}
app: allow to change the brush size on alt-right click. I started from mitch's patch (though code changed so it was not working, yet I ended up with quite a different direction). Modified from original proposition in #498: * Do not mix opacity and brush size in a same action, one on horizontal movement, the other on vertical. The problem is that it's hard to stay perfectly horizontal or vertical, so you nearly necessarily change one while changing the other and this would be frustrating. * Do not just use modifiers, but modifiers + right click. The logics is that left (or whatever is the first button) click is for the tool actions. The middle click for navigation (panning, rotation, and even layer navigation now). Right click for now is only for menu. With this change, let's use right click for various settings-related changes too. Also we already have people complaining with things like canvas rotation happening unexpectedly even though it requires button clicks. Imagine an action just made of modifiers! Many people would hit these by mistake all the time! * Focus on brush size only for now. Instead of just calling the action repetitively with the "SElECT_NEXT" action as proposed in the original patch by mitch, let's compute the actual size between the press and release. This would allow to have a real visual hint and also would make it a lot more useful and meaningful to be an on-canvas change. Say you want to reproduce a stroke size on canvas. You can click the center and expand to retrieve approximately the size without computing it in pixels. Limitations and future work: * This is a first draft and I still want to test if it works well with the "lock brush to view" and with scale factor > 1. * I want to associate this with work done for #7034 so that visual hint still appear even when we have no visual hint set. * I am not so fond of with the way we use enum actions which doesn't really make satisfying logics (I hacked a bit over it, but it's getting ugly). I'm considering creating int/double actions to really set some values with exact numbers through actions. * Right now we need to stop the right click first. I want to be able to stop the brush sizing with releasing Alt too. * It would be nice to make this all more customizable, which is why I called internal variable "mod1_setting". The goal will be to have other types of actions possibly. Also it could be deactivatable for people really not liking these or hitting these by mistake (while not needing these). Same for the navigation shorcuts. * Similarly the right-click menu could be deactivatable or switched to other actions conditionally (through Preferences). It is doubtful how useful it is (compared to using the same menus on top of the GUI) though I don't want to just delete the option because some people would clearly be used to it. * I think we should start breaking down the whole tool events code a bit more, in particular the function gimp_display_shell_canvas_tool_events(). * For more settings, a small on-canvas GUI could be of interest where you could customize various values through sliders and buttons, and also where you could put your favorite brushes or dynamics or whatnot. It's not replacing the more complete dockable but could be a nice quick version for fast editing.
2022-02-15 07:10:34 +08:00
}
g_free (group_name);
}
app: use modifiers set in GimpModifiersManager rather than hardcoded. For now GimpModifiersManager returns the same modifiers as what was previously hardcoded and we have no GUI yet to change the settings. But the core of the new feature is in place.
2022-07-27 01:52:47 +08:00
/* Replace gdk_event_triggers_context_menu() as we don't want to trigger
* anymore on right click, as we have our own system.
* But we trigger with %GDK_MODIFIER_INTENT_CONTEXT_MENU mask.
*/
static gboolean
gimp_display_triggers_context_menu (const GdkEvent *event,
GimpDisplayShell *shell,
Gimp *gimp,
const GimpCoords *image_coords,
gboolean force)
{
if (event->type == GDK_BUTTON_PRESS)
{
const GdkEventButton *bevent = (const GdkEventButton *) event;
gboolean triggers = force;
g_return_val_if_fail (GDK_IS_WINDOW (bevent->window), FALSE);
if (! force)
{
GdkDisplay *display;
GdkModifierType modifier;
display = gdk_window_get_display (bevent->window);
modifier = gdk_keymap_get_modifier_mask (gdk_keymap_get_for_display (display),
GDK_MODIFIER_INTENT_CONTEXT_MENU);
triggers = (modifier != 0 &&
bevent->button == GDK_BUTTON_PRIMARY &&
! (bevent->state & (GDK_BUTTON2_MASK | GDK_BUTTON3_MASK)) &&
(bevent->state & modifier));
}
if (triggers)
{
GimpUIManager *ui_manager;
const gchar *ui_path;
ui_manager = tool_manager_get_popup_active (gimp,
image_coords,
bevent->state,
shell->display,
&ui_path);
if (! ui_manager)
{
ui_manager = shell->popup_manager;
ui_path = "/dummy-menubar/image-popup";
}
gimp_ui_manager_ui_popup_at_pointer (ui_manager, ui_path, event,
NULL, NULL);
return TRUE;
}
}
return FALSE;
}