GNOME Bugzilla – Bug 681199
Keep the caret visible by pushing the view up
Last modified: 2021-07-05 14:15:11 UTC
Currently, the onscreen keyboard always overlaps the view (windows + background). This means that it can obscure where text is being entered. The view should be pushed up in circumstances where the caret would otherwise be obscured. The following mockup gives an idea of how this could work: http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/notifications-chat-tray-touch.png
*** Bug 707284 has been marked as a duplicate of this bug. ***
Proposal on how to solve this: Change this line: https://github.com/GNOME/gnome-shell/blob/master/js/ui/layout.js#L247 to: https://github.com/schuhumi/gnome-shell-extension-caribou-resize-workspace/blob/master/src/extension.js#L11 Result: https://raw.githubusercontent.com/schuhumi/gnome-shell-extension-caribou-resize-workspace/master/caribou_resize_workspace.png (note how the gedit window ends where caribou starts although it's maximized)
I'm not sure about this approach. It is certainly easier(*) than the proposed design, but there are a number of drawbacks: - resizing windows can trigger relayouts that are moderately expensive both in terms of performance and visual noise - non-maximized windows that are resized are not restored to their user-set size when the OSK pops down The second issue could be addressed to make sure that windows are vertically maximized while the OSK is open (and unmaximized if necessary when hiding the keyboard). Maybe that would be a good compromise until we (maybe some day) get to implement the original design? (*) a *lot* easier actually if the shifted windows should still respond to mouse input, as this would require input translation (a first for us on wayland and a no-go on X11)
It might be that the behaviour of this extension is not the best (at least android does the same) and the initial design is better. But at least this is a simple and small solution for a generic problem. I'd prefer to help the user of gnome shell with this addition that will work in most of the cases than having no solution at all. Another (and maybe better) solution can be discussed and developed later.
I'm fine with that as long as you fix the second issue I mentioned in comment #3.
I've tried several gnome application which are non-maximized (terminal, contacts, maps, epiphany, ...). All of them gets restored to their previous user defined position/size (tested on wayland). Do you have an example of an application that does not work as expected?
Are you sure the windows were actually resized rather than just moved? I can reproduce the issue with any apps, including the ones you mention. For example: 1. Open nautilus 2. Move/resize the window to take up most of the screen height 3. Toggle search button (OSK should pop up) 4. Toggle search button again (OSD should pop down) The window keeps the size from step 3 rather than growing back to the size from step 2.
Yes, Florian you are right. I've missed this use case... seems to be a bug within shell. I'd suggest adding this extension and opening a new gnome shell bug for this issue.
Uhm, no. That's simply how mutter's work area code works (and has worked in metacity since about 2001). If that code needs to be updated to deal with frequent and big work area changes, then that needs to happen before merging the patch. "This patch is super simple as long as you ignore the hard part" doesn't fly, sorry.
Florian, i did some further testing with this issue and i can only reproduce it on wayland. Using X there is no issue for this use case. Can you guide me into the difference between X and wayland code within mutter? So the code did change since 2001.
*** Bug 791118 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.