The fact that now the horizontal scrollbar and the bottom bar take up half of the space that used to be the script doesn't seem like an improvement? 2,5 visible lines is IMO barely workable – just imagine trying to show an autocomplete window there; you can only see the top entry. So maybe I don't understand what issue this PR addresses?

Ideally, while the keyboard comes up, a lot more elements hide or move out of the way so that you can see more of the script you're typing in. But this would require a proposal that would need to be fleshed out a bit more, I think?

Looks great!

On a tablet (12-inch display). The code editor just needs to automatically scroll to the input line.

The fact that now the horizontal scrollbar and the bottom bar take up half of the space that used to be the script doesn't seem like an improvement? 2,5 visible lines is IMO barely workable – just imagine trying to show an autocomplete window there; you can only see the top entry. So maybe I don't understand what issue this PR addresses?

Ideally, while the keyboard comes up, a lot more elements hide or move out of the way so that you can see more of the script you're typing in. But this would require a proposal that would need to be fleshed out a bit more, I think?

I understand that space is still limited, but I'd consider this still an improvement over the previous behavior. Earlier, users had to manually scroll every time to see the line they were editing. After this PR, the script editor would auto scroll and keep the edited line visible.

As shown in Alex's screen recording, the experience is usable on tablets as more lines are visible even after opening keyboard, on mobile I've been considering hiding the bottom bar as well, although there's not much we can do about the scrollbar though.
For the autocomplete dialog, the plan is to make it open upwards above the edited line when the keyboard is visible.

I agree that hiding or moving some of the top elements would free up a lot more space, but that's outside the scope of this PR.

BTW, this PR is still in draft :-)

It would be good to get few testing on different mobiles and tablets.

Can you reproduce that?

When I open Output it's okay again.

Samsung Tab S7 (Android 13). I couldn't reproduce it on a Chromebook. The Output panel is always open there.

Yeah, but it's unrelated to this PR.
Fix for this issue (#112549) is merged now, so it should be solved after a rebase.

Test on Pixel 4a

adjust_viewport_to_caret doesn't seem to work if the keyboard height is too large (it's the default size). Do you see any other solution for this?

That method is working, the issue is due to that left panel which reaches its minimum size and now script editor cannot be resized further. Hide that panel and this issue would be solved.

If I reduce the keyboard height, then everything is fine. To be able to work with it reasonably well, the keyboard should be made smaller anyway.

Screen_recording_20251118_200001.mp4

Oops, now that you mentioned it, the keyboard height was reduced on my mobile for some times now that I totally forgot about this 😬.
Now when I keep it at default size then it covers almost the whole editor.

Now, Should we do this change only for large screen devices (tablets)? Or, should we add a one time popup to ask users to reduce the keyboard size?

I'll ask Fredia tommorow and see what he thinks about this.

Now, Should we do this change only for large screen devices (tablets)? Or, should we add a one time popup to ask users to reduce the keyboard size?

I would leave it as is; the virtual keyboard is a "standalone" app, and older versions/smartphones may not have this function.
https://play.google.com/store/apps/details?id=com.google.android.inputmethod.latin

I was able to set up the Google Gboard app on my Samsung tablet. I believe the Samsung Keyboard app is only available in the Samsung Store, and since I didn't want to create a Samsung account, this app is outdated for me.

I wonder if it's possible to hint the OS so that the virtual keyboard is configured differently for Godot? E.g. removing the top bar with word predictions (rarely useful for code as they're meant for natural language - unless we can hook up autocompletion in them :P), there also seems to be a mostly empty bottom bar that could maybe be removed/tweaked.

Of course default virtual keyboards aren't super well suited for code in the first place, but that's still what most users will have configured by default so the more we can do to accommodate them, the better.

And while I agree this is out of scope for this PR, I think we should indeed think a bit more holistically about what UI would be workable for using a virtual keyboard for typing code on a phone. It may make sense e.g. to make the script editor automatically full-screen, hiding side docks and the top bar. For the record we already have this distraction free mode:

But it only helps with horizontal space, not vertical.

Another potential option, might be a bit weird, would be for code editing to switch to portrait mode (so you'd have to turn the phone when coding) so that there's more vertical space available to write code in a fullscreen mode.

I wonder if it's possible to hint the OS so that the virtual keyboard is configured differently for Godot? E.g. removing the top bar with word predictions (rarely useful for code as they're meant for natural language - unless we can hook up autocompletion in them :P), there also seems to be a mostly empty bottom bar that could maybe be removed/tweaked.

I had looked into these few months ago, specially hiding the word suggestion bar but hadn't found anything. I'll look into it again.

And while I agree this is out of scope for this PR, I think we should indeed think a bit more holistically about what UI would be workable for using a virtual keyboard for typing code on a phone. It may make sense e.g. to make the script editor automatically full-screen, hiding side docks and the top bar. For the record we already have this distraction free mode:

I had initially planned to create a follow-up PR for this but now I am doing those changes in this PR itself as a sepertae commit. Check the changes in my latest push, I am now hiding the scene tabs bar and script editor menu bar when keyboard is visible, it looks really good to me.

This is the latest changes with keyboard at default size on my mobile.

Another potential option, might be a bit weird, would be for code editing to switch to portrait mode (so you'd have to turn the phone when coding) so that there's more vertical space available to write code in a fullscreen mode.

Adding support for portrait mode (for script editor for now) is already in progress. I am waiting for #109396 to be merged before sending the PR for that.

@akien-mga AFAIK there is no such API to hide the suggestion bar. Even if a certain keyboard has something, another one is not guaranteed to have such a feature so we can't rely on it.

@akien-mga AFAIK there is no such API to hide the suggestion bar. Even if a certain keyboard has something, another one is not guaranteed to have such a feature so we can't rely on it.

There are several suggestions here for hints that may or may not be respected by individual IMEs: https://stackoverflow.com/questions/3789905/how-can-i-turn-off-suggestions-in-edittext
Might be worth a try.

Regarding the big scrollbars, that part is also out of scope for this PR, but I wonder if we can find a better design that doesn't eat up so much of the screen real estate. Could be keeping the scrollbars thin, but increasing their hitbox so they are easy to use.

Or making use of drag gestures for scrolling in ScrollContainers - this doesn't work for the 3D viewport where drag is used for other things, but for the 2D viewport and script editors it should be fine to pan with dragging? Then scrollbars could possibly be hidden or reduced in size, we just need to visually hint that there is content outside the current bounds. E.g. something like this that shows the position in a range (doesn't have to take full vertical/horizontal space, it could be smaller bars centered on the bottom/right):

may or may not be respected by individual IMEs

My point exactly

I've updated the PR description video to show the latest changes.
This PR is now ready from my side.

Thanks!

For the autocomplete dialog, the plan is to make it open upwards above the edited line when the keyboard is visible.

PR to improve completion popup: #112991

may or may not be respected by individual IMEs

My point exactly

Well did you test it on various IMEs to see how it's respected? If it works for some, notably the main ones (GBoard, Samsung) then it's definitely worth having, even if some custom thirdparty options like Hacker Keyboard may ignore it.

I haven't tested the API personally but I've used a wide variety of custom IMEs. Some have a suggestions bar, some do not, some have their own options to enable/disable it. Some of my favorites are of the "extremely funky" kind, though :)