Window management

[Thorben]

Hi all,

Resent because I was not on this list, I normally just skim the archive 
from time to time as this project very much interests me. I can't wait 
for the day when I can try KDE5 on wayland.

A couple of things have been bugging me and I thought I might give my 
thoughts on them. I'll post separate emails as to not mix topics.

Problem 1 window management.

There has been a lot of discussion on window management (minimise, 
maximise, etc) and some attempts at a solutions.

I had some thoughts on the matter, be chose to stay silent because a) 
There are people that know about this stuff then I, b) The discussion 
exploded in April and so I didn't feel I should bring it up again.

The main issue as it seems to me, is keeping Wayland agnostic of any 
particular UI paradigm (Desktop, Mobile, Tablet, Car, Fridge, etc) and 
there is the second issue of not breaking the existing protocol API.

My idea would be to not mix this concept of "minimise" with other 
concepts to do with size (such as maximise).

I would suggest a size state system of:

  - Windowed (and maybe variances like popup)
  - Maximised (Fills all screen space minus whatever the shell uses)
  - (Maybe vertical and horizontal maximise also being possible states?)
  - Fullscreen (Take all screen space)

"Minimised" or hidden would better fit in with another state system 
like window stacking. My idea is that the Homescreen/Desktop/Whatever 
drawn by the shell is at stacking position 0 and that visible windows 
are above it. Thus having a positive stacking number; windows that are 
hidden (minimised) are behind it with a negative stacking number. 
Obviously the windows size state remains as is.

This is at the protocol level. How a user sees or drives this is 
entirely up to the shell. Maybe a taskbar, a window list, a button or a 
combination there of.

There is the other issue of, if having a negative stacking number is 
enough indication to a window that it is hidden. I don't know wayland 
well enough, maybe that sort of information is not available to clients. 
In which case there needs to be a notification.

Whether a hidden (minimised) window chooses to continue updating it's 
surface should be a clients choice. It can be based on existing 
mechanism of what is obscured or visible, or whatever. Does a covered 
window normally repaint covered parts?

The compositor should not waste any further resources on compositing 
such windows/surfaces into the final screen image. With the possible of 
exception of shells that want to 'preview' a hidden window. Like most 
desktops do, and I am guessing some tablets would like to too.

So that's my thought, stop try to fit the concept of 'minimised' into 
the concept of window size. Decouple it entirely from 'maximised'. 
Shuffle it behind whatever fills the screen when no windows are visible 
(Desktop, Homescreen, etc).


Regards,

Thorben