Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overlap? #6

Open
TMavica opened this issue Apr 25, 2018 · 6 comments
Open

Overlap? #6

TMavica opened this issue Apr 25, 2018 · 6 comments

Comments

@TMavica
Copy link

TMavica commented Apr 25, 2018

screenshot_20180426_001
screenshot_20180426_002

@TMavica
Copy link
Author

TMavica commented Apr 30, 2018

any news about?

@R-033
Copy link
Owner

R-033 commented Apr 30, 2018

No progress so far, but I'm working on it

@Olf0
Copy link

Olf0 commented May 11, 2018

Well, I do not fully comprehend the issue description "Overlap?", as this is IMO the correct behaviour (of ToeTerm / ThumbTerm / FingerTerm) with Settings --> Keyboard behaviour set to its default: Fade

But in fact, setting this slider to Move in ToeTerm does not alter its virtual keyboard's behaviour, which supposedly is the bug this issue addresses.

Fixing Settings --> Keyboard behaviour --> Move (by making it working as it does in FingerTerm) would be much appreciated.

Tested with ToeTerm versions up to (and including) 1.5 under SailfishOS 2.1.4.14 on a Jolla 1 phone.

@R-033
Copy link
Owner

R-033 commented May 12, 2018

Move is actually working as expected. It only moves content when cursor is behind keyboard
The problem is that when you change orientation current active line with cursor moves in center of the screen, which is not covered by keyboard, and content is not being moved
FingerTerm have same problem, and I'm trying to fix it

@Olf0
Copy link

Olf0 commented May 12, 2018

@R-033, sorry, I should have checked FingerTerm's current behaviour more thoroughly. For some reason I believed to have seen the virtual keyboard moving, which is not the case (and fine).

By comparing ToeTerm's and FingerTerm's Move behaviour in detail, I realised that you enhanced it nicely:

  • Not showing the terminal window content dimmed in its original position (excellent, as it irritatingly duplicated the window content: dimmed in its original position and at full brightness in the Move'd position).
  • Using the highlighted keys (the four arrow keys, Page up & down keys and Return key) do not trigger a Move-action. I originally did not understand this and it takes a while to get used to it, but I ultimately perceive this as an improvement.
    You may consider adding the Backspace key to the highlighted keys and thus to this behavior (as it is like the Left-arrow key, just additionally deleting the character under the cursor).

And thanks for the explanation, which made me comprehend what is wrong in @TMavica screenshots. I did not see the unusual cursor position in the middle of the screen and wouldn't have understood how to achieve that without an explanation.
But as a CRTL-L ("Clear screen") resolves the resulting "Overlap" easily and it takes changing the orientation twice (from portrait to landscape and back to portrait) to trigger this issue in ToeTerm and FingerTerm (at least in my experiments), IMO this is a rather minor issue. Although I see, that this may happen accidentally, when using ToeTerm in portrait orientation, so a fix would be nice.

@TMavica
Copy link
Author

TMavica commented May 17, 2018

thx
Ctrl +l is best solution

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants