The other case is Live Minimized Window Previews. This is a pretty big deal
to users and that means it's a pretty big deal to me. I want to make absolutely
sure that there are no problems using this feature in a wayland compositor. This
is one of the key features that others may not realize I am very passionate about.
The confusion in this particular instance was that:
1) I was trying to express my point that we need to consider this specific
feature when discussing the minimize protocol.
2) Pekka had the answer all along but the solution he gave must be implemented.
There is an apparent technical problem with implementing eglSwapInterval() as
well. Kristian and at least one other mesa developer have expressed that the current
patch expected to work, deadlocks.
3) I was trying to spend time addressing each individuals' concerns but I think
some lost site of the fact that the solution is already known but must be implemented
in the mesa EGL implementation.
Ultimately, I am trying to solve the problems that I noticed the compiz developers
had when trying to implement certain features that would have made compiz even
that much better. The timing is critical here, since we have the chance now in
this new built-from-scratch implementation. In a way, I learned about X protocol
limitations indirectly, by watching other developers struggle to solve certain
problems in compiz using (or rather, fighting with) the X protocol.
A side note here is that compiz is a compositing window manager for X. It uses
a special GLX extension to use X pixmaps as GL textures which opens the door for
features found throughout compiz. The shell plugin is analogous to a window manager,
but the shell plugin API interfaces alone do not permit the rendering control
that makes certain compiz graphical features possible.
The Live Minimized Window Preview problem is one of many that I might not have
otherwise noticed if it weren't for Sam Spilsbury, furiously hacking to solve
such problems. He went so far as to try and hack the X server itself to support
some features in compiz, that were inherently impossible with the current X protocol.
Your works have not gone unnoticed Sam, thanks for driving compiz all the way.
The important thing here is that minimize is not alongside maximize where it
ought to be in the core wayland protocol. Not only do I want to see it in place
but there is additional maximize protocol to allow the compositor to suggest (un)maximize
and create a more unified interface for both of these basic window management
features while at the same time, preserving the possibility for future graphical
In addition, the current maximize shell plugin implementation is defined as
type, not state. Maximized is not a type of surface, it is a state that a surface
can be in. When you do actually add minimize into the mix, you will quickly see
that maximize and minimize state must be handled separately. If you have maximize
and minimize both as type, this means it can be minimized or maximized, but never
both at the same time. This problem stems from the fact that maximize is defined
as type and not state, in the shell plugin. This is not a show-stopper, because
it can be fixed in a shell plugin. The point here is, that I noticed this problem
through my minimize work and would like to see it fixed upstream weston before
minimize is implemented and it becomes an issue.