Why Wayland & Weston Were Forked

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

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.