Inconsistent hotkey behaviour for rectangle/lasso/ellipse/magic wand select

Bug #1558767 reported by wqfjsth
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

On Pinta 1.6-1, Linux version

Expected behaviour:
Select any non-select tool > press S once > get rectangle select.
(press S twice for lasso, thrice for ellipse, quarce for magic wand)

Actual behaviour:
Select Move tool by pressing M > press S once > get ellipse select.
Select Zoom by pressing Z > press S once > get magic wand.
Select any other tool > press S once (for Select tool) > get rectangle select. (as normal)
Press S twice with "any other tool" > get ellipse select. (should've been lasso)

To me it appears that whatever code reads the hotkey inputs searches for hotkey resolution reads them according to icon order on the toolbar, from left to right. The arrangement of the respective select tool icons then means it "skips" the rectangle tool if anything between it and the magic wand is selected before pressing the hotkey.

Also the lasso tool seems impossible to select by any hotkey at all. Why?

wqfjsth (lj910424)
description: updated
Revision history for this message
grofaty (grofaty) wrote :

I have tested this shortcut behavior in Pinta development on Windows 7 from

Shortcuts act exactly the same in my Pinta. In my humble opinion there are two problems:
1. Lasso does not have keyboard shortcut at all. If mouse is moved to the icon and wait like a second yellow help tip appears without any info of shortcut. But if mouse is moved to any other icon yellow help tip appears with shortcut. So adding a shortcut to Lasso will be a fix for this.
2. Inconsistent icon selection when different tools are selected. I think the suggested behavior if some other tool is selected:
- pressing S once should always get to Rectangle Select
- pressing S one more time it should move to Lasso Select
- pressing S one more time it should move to Ellipse Select
- pressing S one more time it should move to Magic Wand Select
- pressing S one more time it should start from beginning so Rectangle Select

Now when different tools are selected like:
- pressing M and then S then Ellipse Select is selected
- but when pressing Z ant then S then Magic Wand Select is selected

I don't user keyboard shortcuts in Pinta, but I really understand the frustration for users they do, never knowing which tools is going to be selected.

Additional tests I made for icons using the same keyboard shortcuts:
a) M for move
- using M once selects Move Selected Pixels
- using M one more time it correctly selects Move Selection

b) O for rounded objects
- using O selects Line/Curve
- using O one more time Rectangle
- using O one more time Rounded Rectangles
- using O one more time Ellipse
- using O one more time Freeform Shape
Note: both a) and b) are working fine selecting this tools and switching to some other tool (like T for text or Z for zoom) and then ALWAYS starts from beginning.

I am marking this bug report as Confirmed, but most probably the bug can be with lower severity.

P.S. Just wondering, having 21 tools and having 26 English alphabet maybe we should consider having single keyboard shortcut for each of the tool. Just suggestion, don't know how memorable would that be.

Changed in pinta:
status: New → Confirmed
Changed in pinta:
importance: Undecided → Low
tags: added: easy-to-fix user-interface
Revision history for this message
Nick (thekolian1996) wrote :

I want to work on this one. I have found that the "S" hotkey doesn't work for the Lasso Select Tool because of the strange architectural approach. All selection tools inherit behavior from parent class SelectTool, but LassoSelectTool does not. That's why hotkey doesn't work. And all selection tools have its low-level code in DocumentSelection class, except of Lasso. It is weird.
In short, should I refactor it, or maybe leave it like that (except of hotkey inheritance)?

By the way, I found one more problem with hotkeys. Hotkeys can work only with EN keyboard layout. I have also Ukrainian and Russian keyboard layouts and hotkeys don't work with them. I suppose it is because of Cyrillic letters. I think this should be fixed too.

Revision history for this message
Cameron White (cameronwhite91) wrote :

The missing hotkey probably came from - I don't think the Lasso tool should necessarily derive from the same parent class as the Ellipse and Rectangle select tools, though, since those tools share common logic of having handles to resize the shape. But the SelectShapeTool -> SelectTool chain is probably unnecessary now as a result of that change.

Are there issues with the shortcuts for normal menu items when using the Cyrillic key layout, or is it specific to the custom key handling for tools?

Revision history for this message
Nick (thekolian1996) wrote :

Thank you for the link about Lasso tool - it describes why it is done like that very well.

Commands like Ctrl+Shift+N (Ctrl+Shift+Т in Russian keyboard layout) work well.

I have used Tuple in my code, so one more question about it: is it fine to install NuGet-package System.ValueTuple? I want to use code like (a, b) instead of Tuple<T1,T2>. I like new approach more, but I can do the old way, too.

Revision history for this message
Cameron White (cameronwhite91) wrote :

Currently the master branch doesn't depend on any Nuget packages, so I'd probably avoid that for simplicity to avoid changing the build / packaging requirements.

However, you could make a pull request against the branch instead, which is the in-progress port to GTK3 and .NET Core.

Revision history for this message
Nick (thekolian1996) wrote :

Ok, changed it to Tuple<T1, T2> approach.

I think I am not qualified enough to take a part in port to another toolkit/framework.

Revision history for this message
Cameron White (cameronwhite91) wrote :
Changed in pinta:
milestone: none → 1.8
status: Confirmed → Fix Committed
Changed in pinta:
milestone: 1.8 → 1.7.1
Changed in pinta:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.