GNOME Bugzilla – Bug 106920
allow different actions to be assigned to the mouse wheel
Last modified: 2004-12-22 21:47:04 UTC
Everyone who uses the GIMP for painting spends a lot of time moving the cursor to the brush setting window/dock to set the opacity level of a brush and back to the image canvas. I have no specific statistic, but I would guess it's kilometers of mouse movement a day for me ;) It would help me save a lot of time if you could bind the opacity slider to the mousewheel. Considering the wheel itself is already bound to scrolling around the canvas, some modifier key would suffice. Currently available modifier is Alt (shift for zooming, ctrl for horiontal scrolling).
Hmmm... Maybe it's because I do not change the brush opacity so often, but I do not like the idea of using the mouse wheel with a modifier key. This would be a bit strange (not intuitive/confusing?) compared to the other actions bound to the mouse wheel: no modifier: change the current view by scrolling up/down Ctrl: change the current view by scrolling left/right Shift: change the current view by zooming in/out Alt: change the opacity of the current brush??? The opacity slider is in a different window, so some users might not even notice that they have changed something if they press Alt instead of Shift or Ctrl while attempting to change the current view. I understand your problem and I think that some kind of shortcut would be useful, but I am not convinced about the mouse wheel. Of course, another option would be to have a very flexible system for binding various actions to the mouse wheel. The default settings would be identical to the current ones (nothing assigned to Alt) and each user would be able to assign some actions to the wheel + modifier combinations. Some actions that come to my mind right now are: - scroll up/down, left/right, zoom in/out as in the current version - brush opacity - select next/previous brush - brush size (assuming that we can do that and have a live preview) - feather radius for selections - threshold for fuzzy select - select next/previous layer in the stack - go back/forward in the undo history Hmmm... Maybe this should go into a different bug report? Or maybe we should change the title of this bug report if you think that it would be a good way to solve your problem? Of course, this may take more time to implement than a one-time hack using only the Alt+wheel combination.
It wasn't me looking for something to bind to a free Alt modifier. Initially I actually wanted the scrolling and zooming to go. Selfishly I screamed for a feature I would heart removing something I don't care about because GIMP gives me many other way to achieve that fast. Keyboard shortcuts for zooming and the navigator/3rd mousebutton for example. Removing existing functionality to get something new is however a very stupid thing to ask for. But please don't bind anything stupid to it that people would start to get accustomed to ;)(Even though it may 'fit' into the scroll/navigation paradigm). I don't care if I would need a device like this [http://www.griffintechnology.com/products/powermate/] to control opacity. I don't care if I had to plug my midi keyboard to use one of its sliders, but trust me, a hardware slider would save me a HUGE amount of time. Mouse with a wheel is the cheapest HW device that could be used for this. It was developed for fast scrolling because people used to be quite annoyed to scroll by a tiny little arrows or slider. Moving large amounts of screen space. See the pattern? ;) Unfortunately there's only a handful of artists using GIMP as a painting tool. But I may wan't to URL them ;)
Yeah, I couldnt agree more. If Gtk widgets would be physical ones, I am sure I would have had my Gimp serviced many many times and the opacity slider would not be the original one :-) It would have worn out completely multiple times. It is perhaps the most used control I use on the UI - used with ALL tools ALL the time. I *very rarely* paint with 100% opacity when doing real work. So having *something* to adjust the opacity quickly would be awesome. The mouse wheel is a very clever item for that - it is already where your hand is if you paint with the mouse. The Wacom "airbrush" tool works the same way anyway - it has an "opacity wheel" that works exactly like the mouse wheel. So I dont know, I dont use the mouse wheel scrolling much either, but I would find this opacity->mouse wheel binding very very useful. It could also be extended (opacity -> fuzzy brush size would be very useful for photo retouching for example) But I really would be happy if this kind of a feature was added. It could well be behind modifier, I dont care, just as long I can use it without moving the mouse away from the actual work piece. -Tig
Well, we don't seem to disagree... The best way to solve this problem seems to be what I proposed above: have a set of preferences that allows each user to bind the mouse wheel (with or without modifiers) to one of the things that are currently associated with a slider. See the list above (you can also add the opacity of the current layer to that list). So you could easily assign alt+wheel to change the opacity of the current brush, or you could rebind the wheel without modifier if you are not interested in scrolling with the mouse wheel. If you agree with this proposal, please change the title of this bug report to something like "allow different actions to be assigned to the mouse wheel". If you disagree, then let's keep on discussing this issue... ;-) Hmmm... After checking the previous bug reports, this could also solve the problem mentioned in bug #88271.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
This would be a good thing. In Mozilla, for example, you can customize Wheel, SHIFT-Wheel, CTRL-Whell, ALT-Wheel to do different things. We currently have ALT-Wheel left. But the best thing would be a preference to choose among all options (some need scrolling, some don't, some need zooming etc.).
Started to implement this: 2004-06-16 Michael Natterer <mitch@gimp.org> * libgimpwidgets/gimpcontroller.[ch]: added a "name" property. Dispatch events only if the controller is enabled. * app/widgets/gimpcontrollerwheel.c: added controller events for all possible modifier combinations. * etc/Makefile.am * etc/controllerrc: default controllerrc which maps all unused wheel+modifier combinations to more-or-less usefull stuff. 2004-06-16 Michael Natterer <mitch@gimp.org> Started to fix bug #106920 in a more genreral way: * libgimpwidgets/Makefile.am * libgimpwidgets/gimpwidgetstypes.h * libgimpwidgets/gimpwidgetsmarshal.list * libgimpwidgets/gimpcontroller.[ch]: new abstract base class which provides an API for pluggable input controller modules (mouse wheel, usb/midi stuff etc.). * app/widgets/Makefile.am * app/widgets/widgets-types.h * app/widgets/gimpcontrollerwheel.[ch]: subclass of the above which maps wheel mouse scroll events to controller events. * app/widgets/gimpcontrollers.[ch]: manager for controllers. reads $(gimpdir)/controllerrc and keeps a mapping of controller events to GtkActions. * app/gui/gui.c: initialize and shut down the controller stuff. * app/display/gimpdisplayshell-callbacks.c (gimp_display_shell_canvas_tool_events): if a wheel controller exists, dispatch GdkEventScroll to it first and return if it was handled.
IMO we can declare this as FIXED or do you see any obvious improvements that are missing?
The controller mapping editor is missing.
One step closer... 2004-10-26 Michael Natterer <mitch@gimp.org> * app/widgets/Makefile.am * app/widgets/widgets-types.h * app/widgets/gimpcontrollereditor.[ch]: new widget built from preliminary code from the prefs dialog. Prerequisite for finally fixing bug #106920. * app/dialogs/preferences-dialog.c: use the new widget.
Fixed in CVS: 2004-10-26 Michael Natterer <mitch@gimp.org> * app/widgets/gimpactionview.[ch] (gimp_action_view_new): added parameter "const gchar *select_action" and preselect the passed action if non-NULL. Made the column enum public to users of this widget can get data from its tree store. * app/dialogs/preferences-dialog.c (prefs_keyboard_shortcuts_dialog): pass NULL because we don't want a preselected action here. * app/widgets/gimpcontrollereditor.[ch]: added "Edit" and "Delete" buttons to change the event -> action mapping. Implement a action chooser dialog using GimpActionView. Fixes bug #106920.