[Bug / Feature Request] Maliit keyboard breaks vertical height

[rrastgoufard]

Karousel version: 0.9.4-1 Plasma version: 6.0.5 X11 / Wayland: Wayland!

Description: On wayland with a touchscreen, the on screen keyboard Maliit vertically resizes windows in order to get them out of the way of the keyboard. This conflicts badly with karousel most of the time as karousel tries to maintain windows at a fixed height. See attached video.

Screencast_20240805_161726.webm

Note, when a window is already out of the way, such as when in the top half of a column stack, no such issues occur.

By the way, I'm love love loving karousel! Thanks a ton! <3

[peterfajdiga]

Thanks for the report!

I can't find a way to get Maliit to open without a touchscreen. Or to emulate a touchscreen using Virtualbox. :/

[rrastgoufard]

It was a struggle, but I found a way! Use evemu-record and evemu-play.

Attached is a recording of me tapping the touch screen once.

touchscreen_events.2024-08-09-12:56:56.txt

I can confirm that on a different device calling evemu-play on the recording successfully recreates the touch event even though that other device did not have the same physical touch screen. In this file, the touch event is located a little bit up and to the right of the center of the screen.

[peterfajdiga]

Thanks for this, I was able to get the Maliit keyboard to show up with this!

I was hoping that reacting to Maliit and reducing the height of tiled windows to the available space would stop Maliit from trying to continuously resize windows. But it doesn't, so I'm a bit stuck here.

I'd have to know in frameGeometryChanged that the resize was triggered by Maliit and avoid resizing the window in that case. But unfortunately you don't get this information in that signal.

[rrastgoufard]

Aww, that's a bummer... I don't know enough about the scripting api or wayland to help with a proper fix.

Based on the behavior on my computer with the on-screen keyboard, I'm seeing resize loops that I would love to avoid, especially when they happen so quickly that everything locks up, requiring me to hard power-off the system. How do you feel about a hacky solution?

Maybe it would be okay to keep track of a recent history of geometry change requests, and if you notice repetition, then allow the window to "detach" from karousel's control.

And then to "re-attach", theoretically maliit should restore the window to its original location when the keyboard closes, so maybe you could watch for a geometry change that puts it close to karousel's internal model of where it was and then re-tile it with its previous layout if so?

The more I think about this "detach and re-attach" proposal, the more weird edge cases arise, especially regarding re-attach logic. But in the worst case, if we can successfully detect a resize loop, it wouldn't be too bad to simply float the window. (It's easier for me to deal with manually un-floating and re-organizing the column layout than to have my computer crash.)

What do you think?

[rrastgoufard]

I was hoping that reacting to Maliit and reducing the height of tiled windows to the available space would stop Maliit from trying to continuously resize windows. But it doesn't, so I'm a bit stuck here.

This is a surprise! On my computer, if I have two windows tiled together in a column, and if the bottom window is taller than the keyboard, then focusing the upper window allows the keyboard to open and close exactly as expected.

(Note that in this scenario, tapping the bottom window causes a resize loop so tight that my computer hard locks.)

[rrastgoufard]

That was fast! Thanks for solving this :) I just tried it out on my tablet, and it works really well so far!

There seems to be a little jank sometimes when changing from the focused-window-with-keyboard to another window, but I can't seem to replicate it consistently. Even still, this is significantly better for me, so no complaints here.

Thanks again! <3

---

Edit: in case it gives you any hints, here's a small recording of the issue.

https://github.com/user-attachments/assets/39f54d49-d171-412f-a1ab-33d817bae246

(I can't emphasize enough how much more usable my tablet is with the new fix! Thanks again again.)

[peterfajdiga]

Thanks for testing! So this jank happens when the Maliit keyboard gets hidden and another window gets focus, right? Is it just a visual problem that quickly resolves itself or do you need to perform some action to get everything back to normal?

[rrastgoufard]

It stays stuck until some action is taken. The following karousel actions seem to get it unstuck: 1) resize window 2) float (and unfloat) 3) change focus to a different window 4) move window

(Probably more, but these are the things I have easy access to without a keyboard)

Opening a new window also seems to fix things.

For 3), going back to the original window gets us back to the original state, and going again to the original second window causes the same jank.

---

Edit: here's a better video. The following actions occur in the video. 1) The recording starts on OBS 2) Then, a focus left shifts to the column with dolphin and konsole 3) That column's width is increased twice 4) Konsole is tapped/touched so that the keyboard pops up (and it konsole itself elegantly slides up) 5) Then focus left to system settings 6) Focus right back to konsole 7) Repeat 5 and 6 a couple times 8) Focus right again to OBS to end the recording

https://github.com/user-attachments/assets/5dd5f41d-04c3-4c76-98aa-35d3b2af5cef