Jump to content
You must now use your email address to sign in [click for more info] ×

David B.

Members
  • Posts

    4
  • Joined

  • Last visited

  1. Hello @NathanC, thanks for your detailed reply! Ok, I accept that apparently, this behaviour is intentional. However, I would strongly argue that it is not a good idea for three reasons: 1. The shortcut [alt] + [left/right arrow] already provides the exact same thing. Why have two different shortcuts with identical behaviours? 2. This behaviour goes against Apple's app development guidelines and the generally accepted best practice that apps should always respect system-wide standard shortcuts. In iPadOS itself and all other apps that I have ever used, these basic keyboard shortcuts always work the same way – this is predictable and dependable. One specific app going against this is weird, to say the least. In everyday use, it is not only weird, but very frustrating. 3. In the past, these shortcuts have worked in Affinity products on the iPad in the standard way! The behaviour was changed at some point – I always presumed that it must obviously be a bug or an oversight. Thank you for logging everything you said you did! However, I would ask you to please re-evaluate leaving the behaviour mentioned above as it is, as it's very frustrating to use in this state and in my opinion, it's a really strange choice to have two keyboard shortcuts for the same action, while having no shortcut for "jump to beginning/end of line", while at the same time this goes against app design guidelines as well. Thanks and best regards! David
  2. This issue in the Affinity Suite's iPad version has been bugging me for ages! When having multiline text in a text frame or artistic text, the system-wide standard keyboard cursor navigation shortcuts like [cmd]+[arrow] and [alt]+[arrow] including their versions with [shift] as a selection modifier do not work on Bluetooth keyboards. Also, the standard Apple keyboard shortcut [ctrl]+[d] for [del] doesn't work as well. In more detail: • [cmd]+[right arrow] should move the cursor to the end of the current line. Instead, it does nothing or moves the cursor to the beginning of the next word (and then does nothing on subsequent uses). • [cmd]+[left arrow] should move the cursor to the start of the current line. Instead, it moves the cursor to the beginning of the previous word (identical behaviour to [alt]+[left arrow], which works as intended). • [cmd]+[shift]+[right arrow] should select text from the cursor's current position up until the end of the current line, while moving the cursor there as well. Instead, it only selects text and moves the cursor to the beginning of the next word (and then does nothing on subsequent uses). • [cmd]+[shift]+[left arrow] should select text from the cursor's current position up until the start of the current line, while moving the cursor there as well. Instead, it only selects text and moves the cursor to the beginning of the previous word (identical behaviour to [alt]+[shift]+[left arrow], which works as intended). • [alt]+[up arrow] should move the cursor to the start of the current line, if the cursor is not already at the start of the line. If it is, it should move the cursor to the start of the previous line. Instead, it moves the cursor to the very beginning of the whole frame text / artistic text (identical behaviour to [cmd]+[up arrow], which works as intended). • [alt]+[down arrow] should move the cursor to the end of the current line, if the cursor is not already at the end of the line. If it is, it should move the cursor to the end of the next line. Instead, it moves the cursor to the very end of the whole frame text / artistic text (identical behaviour to [cmd]+[down arrow], which works as intended). • [alt]+[shift]+[up arrow] and [alt]+[shift]+[down arrow] have the same problem (with selection, respectively). • [ctrl]+[d] should act like the [del] key (removing the character immediately to the right of the cursor). Instead, it does nothing. This makes editing and navigating texts (especially multiline frame texts in Affinity Designer / Affinity Publisher) extremely frustrating, which is especially disappointing in the case of Affinity Publisher, which after all is made for dealing with text.
  3. Any update on this issue? It's extremely frustrating using Affinity Photo and Affinity Designer with this bug. It's been half a year...
  4. Hello, I hadn't used text fields in Affinity Designer/Photo on iPad for a while. Now I need to use them again, and unfortunately, in the current (non-beta) version, editing Frame Text fields is extremely frustrating, because only the left and right arrow keys work. The up and down arrow keys do not work, as well as combinations like alt+left, alt+right, cmd+left, cmd+right and the respective combinations with the shift key for selections. The only ones which do something are alt+right (but it behaves like cmd+down) and cmd+down. I am absolutely sure that quite some time ago, text fields worked with all the keys and key combinations as intended. Please fix this bug, as it makes working with text very cumbersome and frustrating! My specs are: iPad Pro 12.9" (2020), iOS 15.4.1, Affinity Designer version 1.10.5, build 1.10.21 Best regards, David
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.