D18818: virtualkeyboard: resize the focused window to make room for the keyboard

mart added a comment.


  In D18818#409260 <https://phabricator.kde.org/D18818#409260>, @graesslin wrote:
  
  > Please don't take it negative that I once again request changes here. I once run into this issue myself when I added quick tiling - oh that was a mess, because I didn't track in Client the state changes. Back then Thomas fixed all of it :-) It's just a lesson learned and this geometry handling is really complex.
  
  
  none taken :) the more i look at this problem, the more complex and full of corner cases it looks like.
  
  It's too many states and we need to ensure here that we don't jump out of maximized or fullscreen due to keyboard open. Now to make it even more complex one could think about the display getting rotated which would again change the geometries and all the windows changes.
  
  > I'll outline an idea how this could work: When virtual keyboard opens the focused window gets maximized and the virtual keyboard acts like a panel with strut - but just for the active window. Then we could use existing KWin functionality without having to track the geometry again.
  
  I like that idea (with the caveat roman said, to perhaps maximize only vertically, but i don't have super strong opinions on this)
  
  Implementation wise:
  
  - would all be done here still saving the old maximized state saved and restored from virtualkeyboard.cpp,
  - or having abstractclient itself knowing when there is a keyboard open and maximize itself when it has focus?
  
  (or something else entirely?)

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D18818

To: mart, #plasma, #kwin, bshah, graesslin, romangg
Cc: nicolasfella, mart, kwin, davidedmundson, graesslin, jraleigh, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, bwowk, ZrenBot, ngraham, alexeymin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol