GNOME Bugzilla – Bug 120973
conflicting use of modifiers (Shift, Ctrl, Alt) for some tools
Last modified: 2007-03-07 18:25:24 UTC
I mentioned this in bug #51108 on 2003-08-25, but this probably deserves a separate bug report and a higher severity: some tools use the modifiers (especially Ctrl) for more than one purpose, resulting in some unusable features. Blur/Sharpen and Dodge/Burn: Ctrl is used to toggle between the two modes for these tools. Unfortunately, Ctrl is also used in the Shift+Ctrl combination for drawing straight lines at constrained angles. This conflicting usage makes it impossible to use Shift+Ctrl as intended. A less serious conflict appears with all paint tools (brush, pencil, airbrush, eraser) because Ctrl switches to the color picker temporarily. As a result, Shift-Ctrl-Click for drawing a straight line works, while Ctrl-Shift-Click does not work. We should have a consistent set of modifiers, without conflicts. One solution may be to use Alt instead of Ctrl for switching modes (switching to the color picker or toggling between Blur and Sharpen). This would avoid the conflict with Ctrl used in the Shift+Ctrl combination.
I remember jimmac suggesting we switch to using Shift as modifier for changing tool mode as this would be more intuitive for new gimp users who are used to other *ahem* graphic manipulation programs - or am completely wrong here?
I didn't know that. If this is how some other well-known program does it, then yes, let's try to use Shift. Not because we want to copy what the others are doing, but because we have to re-organize the modifiers anyway, so it would be a good opportunity to change them in a way that can help some users. But if we use Shift for toggling modes, then we have to use a different modifier for drawing straight lines. We could use Alt for that, and keep Ctrl for applying constraints (Ctrl+Alt for drawing lines with constrained angles). We should try to solve that soon, because this implies some changes to the user interface, documentation, tutorials, etc.
Here's the appropriate part of my mail to gnome-dev: However this is a little inconsistent. I would suggest we go back to how 1.2 was in this particular tool and try to use Shift where Ctrl is being used in 1.3 (I have absolutely no idea how much work this is): Selection tools: --------------- no change (both Shift and Ctrl toggle the mode) Zoom tool: ---------- use Shift to toggle in/out. Move tool: ---------- use Shift to toggle pick/move current use Ctrl for movement constraint Crop tool: ---------- use Shift to toggle crop/resize perhaps use Ctrl for keeping either 1:1 aspect ratio or the aspec ratio of the whole image (new feature) Transform tools: ---------------- no change Flip tool: ---------- use Shift instead of Ctrl Text tool: ---------- This is a little complicated. Currently if a text layer exists and is selected, one can click on a pixel that has text on it. Now the tool options change the text attributes. Clicking on it again brings up the edit window. Now let's see if this is better: Selecting a text layer with the text tool active will automatically make any changes to the tool optins apply to the text layer. Clicking anywhere on the layer will bring up the edit dialog with the text loaded. A Shift modifier will toggle edit_current/new_text_layer behaviour. Setting default text tool parameters can be done on a non-text layer. I apologise Sven for thinking about this too late :/ Fill tool: ---------- There's currently no modifier to fill with patterns. Now that we have RGBA patterns and the feature is actually useful ;) it would be nice to have a similar toggle as the select tools. Shift to toggle BG fill and Ctrl to toggle pattern fill. The option dialog could have nice little buttons with a FG rectangle, BG rectangle and active pattern rectangle, just like the selection tools have. Gradient tool: -------------- Shift could toggle the reverse gradient. Ctrl remains. Clone, Pen, Pencil, Airbrush, Dodgeburn, Blursharpen, Smudge and Eraser: ------------------------------------------------------------------------ Although Ctrl is used to toggle to picker tool, I'd leave it as it is, since Ctrl is used for constraints after shift is pressed. Ink tool: ------------------- no change
An alternative would be using the Alt key toggle major paradigm of a tool: We got rid of Alt+ shortcuts, because alt is reserved for access keys (mnemonics). However in potatoshop for example Alt is used as a toggle key (zoom in/out, clone tool's pick area/draw...). That could be an option too, so that the paint tools make more sense (Alt to toggle paint/pick color, Shift for lines,Ctrl for constraints).
I thought there was consensus that Alt cannot be used for essential operations because it is bound to WM actions for most desktop setups. Well, you could argue that these functions can be accessed by widgets in the tool-options...
The problem is Alt+keyboard (especially Alt+arrows or Alt+tab). I am not aware of any problems with Alt+mouse. Is there any WM that binds some actions to Alt+MB1, 2 or 3 in its default configuration?
Yes. Almost all WMs have Alt-MB1 bound to window moves by default. That's why people end up moving their image window when they try to move a selection.
Please define "almost all". Currently, I was able to find only one WM that steals Alt+MB1 from the application: metacity. But kdm (KDE), sawfish and the venerable fvwm and twm do not seem to use it.
Perhaps things have changed but we used to get a lot of complaints from users telling us that they cannot use the Alt modifier. This fact should be taken into consideration when choosing new modifiers.
KDE used to move the window by default with Alt-Drag. That has changed in KDE 3. Given that, what action is required to close this bug? It would be nice to convert this bug into a tracker for a number of bugs, one for each binding which should be changed or is inconsistent. Policy could be defined here, and implemented one keymapping at a time in the tracked bugs. Cheers, Dave.
I am not sure that we need dependent bugs yet. The tricky part is to define the policy; that's why this bug report was opened. Once the policy is defined, updating the code should be relatively easy because replacing the modifiers used in the various tests should not take too long. Once the policy is defined, we may have to open a separate bug for the documentation and maybe for some tools that cannot be updated immediately, but let's see first how long it would take to reach a consensus that eliminates the conflicts between modifiers and improves the usability of the tools.
I beleive that all WMs based on GTK are using by default ALT+MB1 to move windows. This is how it works with GNOME Desktop, XFCE 4 or IceWM.
Bumping to 2.2 in line with my comment on bug #51108. Dave.
Moving back to 1.3.x, because this is an important issue.
Raphael, Important or not, it doesn't seem that anyone is actively working on fixing it right now, and I don't see it as a blocker for a 2.0 release. If it's that important it will be done soon. Re-changing milestone to 2.2. If someone wants to re-add this to the 1.3 milestone, they should also add a note saying that they will do it (also specifying what "it" is). Dave.
I don't follow this discussion any more? What needs to be done to finally close this bug? Any volunteer to check all tools?
The user interface for 2.2 should be considered frozen to give the help authors a chance to update the manual. This bug should thus not be on the 2.2 milestone.
*** Bug 166904 has been marked as a duplicate of this bug. ***
I'm going to resolve this as WONTFIX because that's simply the reality, given how long it has sat untouched. If anything is going to be done along these lines, it will require rethinking the issues from scratch, and it will be best to open a new bug report for it. If this is done, it should be less ambitious than this one, and focused on a single specific change. This is not to say that things can't or shouldn't be improved, just that this bug report is too broad to go anywhere. Feel free to add comments (or reopen) if you disagree.
Re-opening this bug because the reporter in bug #166904 proposed to come up with a suggested list of modifiers. In addition, a bug report about the usage of modifiers must necessarily be as broad as this one because the only good way to solve this problem is to solve it in a consistent way (i.e., taking all tools into account). So focusing on a single tool but introducing inconsistencies with other tools would not help.
Again resolving as WONTFIX because it has been over a year and nothing has happened.
Please... The fact that nothing has happened does not mean that the bug does not exist. There are inconsistencies in the way the modifiers are used. This is a fact. I do not know what is the best way to solve this, but I do not think that closing this bug report helps solving this problem faster. Swiping bugs under the carpet is not the right way to improve the GIMP. So I am re-opening this bug report again.
Can we finally close this? What are the remaining inconsistencies? We can do a lot more things with modifiers now and many things have changed already.
The inconsistencies described in the original report are still there: using Shift-Ctrl-Click gives a different result than Ctrl-Shift-Click for most paint tools. However, the problem is much less severe now than in GIMP 1.3: since 2.0 and 2.2, the changes in the cursor have helped the user to guess that something different is going to happen. And since 2.3 (soon 2.4), the status bar messages describe exactly what is going to happen and what the various modifiers like Shift or Ctrl will do (straight line, constrained angles, etc.). So I think that we can finally close this as WONTFIX because all these changes made this problem much less confusing than it was before.