After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 106920 - allow different actions to be assigned to the mouse wheel
allow different actions to be assigned to the mouse wheel
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: User Interface
git master
Other All
: Normal enhancement
: 2.2
Assigned To: Michael Natterer
Michael Natterer
Depends on:
Blocks:
 
 
Reported: 2003-02-24 12:37 UTC by Jakub Steiner
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jakub Steiner 2003-02-24 12:37:13 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).
Comment 1 Raphaël Quinet 2003-02-24 19:32:03 UTC
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.
Comment 2 Jakub Steiner 2003-02-24 22:44:20 UTC
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 ;)
Comment 3 Tuomas Kuosmanen 2003-02-24 22:54:41 UTC
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
Comment 4 Raphaël Quinet 2003-02-25 17:41:02 UTC
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.
Comment 5 Alan Horkan 2003-07-23 18:39:41 UTC
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.  
Comment 6 Tino Schwarze 2003-07-24 13:15:22 UTC
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.).
Comment 7 Michael Natterer 2004-06-16 01:02:47 UTC
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.
Comment 8 Sven Neumann 2004-09-16 18:40:55 UTC
IMO we can declare this as FIXED or do you see any obvious improvements that are
missing?
Comment 9 Michael Natterer 2004-09-16 19:00:45 UTC
The controller mapping editor is missing.
Comment 10 Michael Natterer 2004-10-26 12:27:14 UTC
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.
Comment 11 Michael Natterer 2004-10-26 15:10:13 UTC
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.