Window management

[Pekka Paalanen]

On Sun, 26 May 2013 01:09:34 +0200
Thorben <thorbenj+freedesktop at eryri.ch> wrote:

> 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.

Wayland core must be kept agnostic of the UI paradigm, but the
shell interfaces not.

> 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).

You seem to have a very convoluted view of how things work, and to
me it appears you are confusing implementation details with the
protocol specification.

One thing is that there are no "stacking numbers", and there cannot
even be global stacking numbers, as those would expose information
about the whole scenegraph, not just the client's own surfaces, to
the clients, and it might even require deriving state from them.
That is impossible to synchronize in a clear and performant way.

"Minimized" is a window state, and is irrelevant to stacking order.
A window either is or is not part of the visible scenegraph, and
even that is orthogonal to being minimized. Minimized also has no
effect on the surface size from a client's perspective. The surface
still exists in its normal size, but it just is not shown in a
normal way. Clients must be aware of the window state, but they do
not know how their surfaces are actually shown.

Thinking anything about compositor's painting of the scenegraph is
an implementation detail, and should not concern the protocol in
any way. For instance, there are no "expose" events at all. Clients
simply provide a whole new frame for their surfaces whenever they
want to. The compositor makes sure it can *always* paint the whole
scenegraph without any client cooperation. IOW, the compositor
preserves the current frame for all surfaces. That is what
compositing does. Clients also have no idea, what parts of their
surfaces are actually visible or not. Such information is simply not
needed.

The compositor's compositing methods are completely implementation
details. For instance, on output repaint Weston's GL-renderer
starts with some old previously rendered framebuffer, accumulates
what damage has happened since it was painted, and paints only the
changed areas. If a surface happens to be obscured, obscured areas
are not painted. Opaque areas are not blended. Etc. All that is
computed from the scenegraph as needed. Clients will only tell what
areas they changed in their surfaces, and what areas are supposed
to be opaque. Everything else is automatic and does not concern the
clients.

You do not want to bring anything from a particular implementation
into the protocol, because then the protocol would mandate the use
of the same algorithm. Usually that becomes a huge burden as time
passes, because no better algorithms can be implemented without
changing the protocol.

I understand it may be hard to see the difference between
implementation and protocol. I just don't see your proposal
working, sorry. It might be due to mutual misunderstanding.


Thanks,
pq