This makes it possible for application to shift the textboxes when using
virtualkeyboard.
Details
Details
Diff Detail
Diff Detail
- Repository
- R108 KWin
- Branch
- mart/resizeforkeyboard
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Buildable 7987 Build 8005: arc lint + arc unit
Comment Actions
tested with test QML code
What QML code exactly?
I would expect you would need to map the virtual keyboard to global space, then map that to the local co-ordinates of the relevant buffer.
Comment Actions
I also realized that I am passing this wrong information, I am passing it just keyboard position, which is not what client is interested in if I understand it correctly.
Comment Actions
Yeah, as the comment says it's about the overlap. Which is not totally trivial, otherwise I would have added it instead of a todo :-P Basically we need to calculate the overlap of the client in screen geometry with the input window in screen geometry and transfer this overlap (if there is any) to client coordinates. To make it worse this needs to also handle window decoration which is something the client doesn't know about. Oh and of course the scaling of the surface needs to be considered.
I know we don't have tests yet for the virtual keyboard, but this is a functionality I wouldn't dare to add without having some good test cases at hand. Especially for such situations as virtual keyboard on one screen, application on other screen, overlap, no overlap, deco, scaling, etc.
Comment Actions
course the scaling of the surface needs to be considered.
It doesn't, API states surface-local.
Comment Actions
Surface-local means the same logical-coordinate size that we use in kwin's screen geometry. If you ignore scale, everything should just work.
Only protocol that uses buffer-local needs mapping.
Comment Actions
to get the actual geometry of the client would be basing on Workspace::self()->activeClient() ok?
(not other way to get the position i think?)
Comment Actions
this tries to send just the intersection of the geometries and to track keyboard resize + target window geometry changes
| virtualkeyboard.h | ||
|---|---|---|
| 66 | I don't see trackedClient being used at all. | |
| virtualkeyboard.cpp | ||
|---|---|---|
| 117 | is it possible to get the window which is actually getting them? | |
| virtualkeyboard.cpp | ||
|---|---|---|
| 117 | SeatInterface::focusedTextInputSurface gives you the surface currently having the text input focus. | |
| virtualkeyboard.cpp | ||
|---|---|---|
| 191 | ? | |
| 243 | Sorry, but this still doesn't work. You are thinking in windows, but these are surfaces. The surface you have could be a sub-surface. You need to map from global space to surface space. IIRC we have a matrix to transform this. See for example: https://api.kde.org/frameworks/kwayland/html/classKWayland_1_1Server_1_1SeatInterface.html#a56910bce41378def01ee27a6e8b8c6fe But this is for text input surface, not pointer. The pointer surface might be a different to the text input. It might mean we have to add new API to KWayland. | |
| virtualkeyboard.cpp | ||
|---|---|---|
| 243 | tough if i cannot base on a window for it, is there a singal anywhere in surfaceinterface on how i can take the geometry and most important listen to geometry changes? | |
| virtualkeyboard.cpp | ||
|---|---|---|
| 243 | Yeah, overall it looks like we cannot really support this easily. I would tend to say we can ignore sub surfaces here, but it's quite likely that those change when overlapped by virtual keyboard. We have a few bits:
So either connect to the relevant signals in KWin or extend KWayland to do the calculation for the overlap from global to surface local coordinate system. | |
| virtualkeyboard.cpp | ||
|---|---|---|
| 243 | would be the SubSurfaceInterface::pos member? would this reasoning be correct? so, if a surface is a subsurface
*final position is toplevel position + "pos" of the subsurface | |
This comment was removed by mart.
Comment Actions
or should be
QRegion SurfaceInterface::input() const;
always translated to the toplevel surface coordinates if is a subsurface?
Comment Actions
had a discussion about it with @romangg and Dorota from Purism at the plasma mobile sprint and came to the conf=clusion that at first instead we want to resize the toplevel window where the focused surface belongs to a temporary size while the keyboard is open.
the 3rd version of the input protocol removed completely the overlapping area, so if this behavior is needed to be used again, a protocol extension will have to be written