When beginning to edit a long note text from the ‘view’ mode, the text is scrolled wrongly; and the interface doesn't properly remember the editing/viewing mode #961
I have searched for existing issues that may be the same as or related to mine.
This appeared in the redesign for Android 12, app version 1.8.7. I'm using Android 11 on a Pixel 3a.
I previously had the ‘opening mode’ set to ‘last used’ in the settings, however in practice it usually always was ‘edit’ because that's what I did in the app. After the redesign, Orgzly apparently defaults to ‘view’ in this case, but switches to the edit mode if I tap on the text. But: if I have a long text in a note and tap on it, I don't have the cursor positioned in that place and scrolled into the view—instead, the view scrolls to the top of the text, and the cursor is not activated at all. I need to scroll back to where I wanted, and place the cursor anew before entering text.
This can be kinda worked around if I choose ‘edit’ as the default mode—then I can position the cursor right away without extra scrolling. However, if I press ‘back’ to hide the keyboard, Orgzly again switches to the ‘view’ mode, so if I want to scroll around and make further edits, I have to do the tap/scroll/place-the-cursor dance again. To clarify: I usually hide the keyboard because I want to see more of the long text, to more comfortably scroll around in it and find the place for editing, so switching to ‘view’ mode is quite detrimental to this workflow.
IMO to not break the user's expectations (i.e. mine), Orgzly should behave as follows, which is pretty much how it did before the redesign:
Remember the last used view/edit mode, if ‘last used’ is selected in the settings (don't just default to ‘view’).
Don't switch to the ‘view’ mode if the user hides the keyboard in the ‘edit’ mode.
Alternatively, it would be cool if when I tap on text, the cursor was positioned in that place, and it stayed in the view. This would remove the above two requirements, I think, and allow to always use the ‘view’ mode as the base one. But idk if this is difficult to achieve with the particular UI components and the variety of formatting—seeing as the text can contain links, the formatting markers might need to be hidden in the view mode, etc.
By the way, I found an additional bug related to this: if I have the edit mode as the default and open a note, then the ‘back’ system button switches to the ‘view’ mode instead of closing the note.
This appeared in the redesign for Android 12, app version 1.8.7. I'm using Android 11 on a Pixel 3a.
I previously had the ‘opening mode’ set to ‘last used’ in the settings, however in practice it usually always was ‘edit’ because that's what I did in the app. After the redesign, Orgzly apparently defaults to ‘view’ in this case, but switches to the edit mode if I tap on the text. But: if I have a long text in a note and tap on it, I don't have the cursor positioned in that place and scrolled into the view—instead, the view scrolls to the top of the text, and the cursor is not activated at all. I need to scroll back to where I wanted, and place the cursor anew before entering text.
This can be kinda worked around if I choose ‘edit’ as the default mode—then I can position the cursor right away without extra scrolling. However, if I press ‘back’ to hide the keyboard, Orgzly again switches to the ‘view’ mode, so if I want to scroll around and make further edits, I have to do the tap/scroll/place-the-cursor dance again. To clarify: I usually hide the keyboard because I want to see more of the long text, to more comfortably scroll around in it and find the place for editing, so switching to ‘view’ mode is quite detrimental to this workflow.
IMO to not break the user's expectations (i.e. mine), Orgzly should behave as follows, which is pretty much how it did before the redesign:
Alternatively, it would be cool if when I tap on text, the cursor was positioned in that place, and it stayed in the view. This would remove the above two requirements, I think, and allow to always use the ‘view’ mode as the base one. But idk if this is difficult to achieve with the particular UI components and the variety of formatting—seeing as the text can contain links, the formatting markers might need to be hidden in the view mode, etc.