[Enhanced] Editor: improve layer transform convenience

Want to submit a new feature, an enhancement ? Do it here !
Post Reply
es
Posts: 114
Joined: Sun Dec 04, 2022 6:24 pm

[Enhanced] Editor: improve layer transform convenience

Post by es »

Let's say I want to move a duplicate layer left by 50% of its width
I click on the "Transform layer" button and then I'm lost: if I use a mouse to move fast, it's easy to move a picture vertically as well (accidentally).
Also, to stop precisely at 50% I have to magnify the screen, calculate what pixel 50% is at and then carefully move pixel-by-pixel
Likewise, the magnify/rotate should allow

So a few suggestions on how to make these operations more convenient:
  • Make holding ⇧ constraint the direction (so you can only move ←→ or ↑↓)
  • Allow moving by a specific value in pixels and % in a user defined direction
  • Allow magnifying by a specific value in addition to dragging the circle on a line
  • Allow rotating by a specific ° value in addition to dragging the circle on a line
  • Add the common rotation values (0° ↷90° ↶90° ⤸180°) as extra buttons adjacent to the rotation line
User avatar
forum_adm
Site Admin
Posts: 1817
Joined: Fri Dec 23, 2016 9:41 am
Location: Germany
Country: Germany
Contact:

Re: Editor: improve layer transform convenience

Post by forum_adm »

I improved the top bar in build 5710:
Screenshot 2023-01-01 at 17.31.47.jpg
Screenshot 2023-01-01 at 17.31.47.jpg (86.8 KiB) Viewed 1304 times
es
Posts: 114
Joined: Sun Dec 04, 2022 6:24 pm

Re: [Enhanced] Editor: improve layer transform convenience

Post by es »

Thank you! Is there a way to make arrow keys within pixel numbers increment/decrement by pixel so you can easily visually experiment by moving the picture (same would be great for the zoom% and rotation°)?
For example, usually, after moving a pic to roughly the correct position I could use keyboard cursor for more precision, but you don't have it in GC, another alternative is to click the x/y input fields and user cursor to achieve the same goal
User avatar
forum_adm
Site Admin
Posts: 1817
Joined: Fri Dec 23, 2016 9:41 am
Location: Germany
Country: Germany
Contact:

Re: [Enhanced] Editor: improve layer transform convenience

Post by forum_adm »

That is currently not supported in that function.

But that is supported for moving a selection in the editor.
User avatar
forum_adm
Site Admin
Posts: 1817
Joined: Fri Dec 23, 2016 9:41 am
Location: Germany
Country: Germany
Contact:

Re: [Enhanced] Editor: improve layer transform convenience

Post by forum_adm »

Please recheck with build 5711.

Cursor keys move layer.
Shift cursor keys scale layer.
Option cursor keys rotate layer.
es
Posts: 114
Joined: Sun Dec 04, 2022 6:24 pm

Re: [Enhanced] Editor: improve layer transform convenience

Post by es »

This is great, thanks!

Just a couple of more notes on this:
  • after clicking on a toolbar element you can't click back on the layer to return input focus: so if you enter a number at the field Y you can't use the arrow keys to adjust the position, the only way to get input focus back to the layer is to ⭾ multiple times, which is rather inconvenient
  • also, related to ↑, I'd maybe use ⏎⎋ keys to confirm/discard input in a specific field rather than confirm/discard ALL the edits in the current layer editing session as a blinking cursor in a Y input field "invites" you to hit ⏎ to confirm the number of pixels, but you return to the main editor view instead, accepting all the edits. Is there a way to hide Accept/Reset buttons behind a modifier? Couldn't find any command/shortcut in the menu for that
  • And would just reiterate another common great design feature: when moving with a mouse it's very helpful to be able to constraint movements to either only horizontal or vertical axis (usually in other apps you press and hold ⇧ for that)
  • Minor point: I'd expect ⌥▶ to rotate clockwise
User avatar
forum_adm
Site Admin
Posts: 1817
Joined: Fri Dec 23, 2016 9:41 am
Location: Germany
Country: Germany
Contact:

Re: [Enhanced] Editor: improve layer transform convenience

Post by forum_adm »

The focus is managed by the macOS. So, I can't change that.

Cancel is normally bind the the escape key and the default button to return. I will not change this default Apple behavior because every user expects this.
User avatar
forum_adm
Site Admin
Posts: 1817
Joined: Fri Dec 23, 2016 9:41 am
Location: Germany
Country: Germany
Contact:

Re: [Enhanced] Editor: improve layer transform convenience

Post by forum_adm »

Shift key support for the move only horizontal/vertical will be added to build 5712.

I inverted the keys for the rotation in build 5712.
es
Posts: 114
Joined: Sun Dec 04, 2022 6:24 pm

Re: [Enhanced] Editor: improve layer transform convenience

Post by es »

forum_adm wrote: Mon Jan 02, 2023 4:29 pm The focus is managed by the macOS. So, I can't change that.
Why not, I am clicking with a mouse on another UI element (the image layer itself), in other apps clicking shifts focus to the element you've clicked on
forum_adm wrote: Mon Jan 02, 2023 4:29 pm Cancel is normally bind the the escape key and the default button to return. I will not change this default Apple behavior because every user expects this.
Yes, but normally it's applicable to the focused input field. For example, check this screenshot from the TextEdit app: if you invoke the Find Text command, and then edit the Font Size input field number, hitting ⎋ will do nothing, and hitting ⏎ will return input focus to the text field.
focus.png
focus.png (30.21 KiB) Viewed 1283 times
That's where the current confusion is: the user expects that hitting ⏎ in an input field would confirm that input field choice, not the overall toolbar (I've hit this issue several times, and when you apply many edits that's rather annoying to lose all of them)

So if you don't want to allow extra rebinds, maybe the ⎋⏎ keys should only invoke the Cancel/Apply buttons when the main layer is focused, not when you focus a sub-UI element, just like in the TextEdit example (though I understand it's a bit more complicated since unlike in the TextEdit example the sub-UI elements belong to the same toolbar, but maybe you could split them???)
Post Reply