If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Why Wayland & Weston Were Forked

Phoronix: Why Wayland & Weston Were Forked

Last week, Wayland/Weston was forked by a long-time contributor, Scott Moreau. The fork of the Wayland/Weston display server ended up becoming known as Northfield/Norwood, following disagreements within the Wayland development camp. Scott Moreau was ultimately banned from the Wayland mailing list and IRC channel, so he's written an exclusive, independent article for Phoronix to explain his actions and why he felt a fork of the Wayland display server protocol and the reference Weston compositor were necessary.

So far as all the drama nonsense that has happened because of this, I think it has caused certain people to show their true colors. I also think that the people doing the 'mud slinging' have not shown their brightest colors.

One comment that I hope this post answers is one by Darxus, an influential personality that has been a consistent problem against me. Taken from the GH-Next phoronix article comments:

“Also, lets not forget that soreau was not banned due to his lack of social grace alone. The final straw was his refusal to use an existing mechanism to retain protocol compatibility when making his needed protocol changes, insisting on doing it in a way that would break things, without providing a reason”

First of all, for the record, Darxus is not a core wayland developer. If you would like to be the judge, please refer to his wayland/weston commits. Second of all, this is a completely false statement. It also has a very tyrannical tone to it. The implication is that I am not compliant with certain fabricated 'rules'.

On the contrary, I have been fully compliant with Kristian and the other core wayland developers. However, when ultimate goals diverge to the point where two parties can no longer work together, it is not a particularly good investment of time to continue trying to solve problems from either side.

Darxus and Daniel's mud-slinging works throughout this ordeal are frivolous, unwarranted, unnecessary, childish, completely ridiculous and an outright waste of everyone's time – with specific intent to damage my public image. Let's not allow these such incidents to overshadow the countless amount of good people who have put in the time, work and dedication to bring us to the point where we are today.

I enjoy working on this code and it's not too terribly difficult once you have the basics down. On the other hand, the effort required for me to convey my reasonings to others immense. I think one of the reasons I have failed to communicate effectively is because it takes more time. Time is costly and I don't have a lot to go around. Also, explaining myself repeatedly gives me a headache. I don't plan on doing much more of it in this context.

A quick comment about Mir. I do not necessarily see their decision as wrong because it is right for them. However, I do think that Mark Shuttleworth should probably have explained a lot more in detail his reasonings. He owes it to all the people that believed him when he vowed to use wayland as their next display platform target.

So while Ubuntu works on a unified display server for devices....*sigh*

It is a one-distro-only solution at this time which means it is not a unified display server for devices. personally, I am interested to know what steam and other proprietary applications such as google-chrome will choose to support.

I quickly skimmed through the mailing list of wayland (March only). The biggest problem seems to be the implementation of handling windows (surfaces) with respect to minimize/maximize/resize. You wanted this in the Wayland protocol, but the current upstream developers want it 'to flesh out'?

It seems that this is coming from a chicken-and-egg problem, listed here:

<krh> weston isn't going to be a full DE, starting a new DE is
specifically a non-goal of wayland
<krh> and I've always said that fleshing out wl_shell will have to
wait until we have at least one real DE to driver the work
<krh> otherwise it's all just going to be guesswork

They want to do this in a Wayland shell, but don't know how. While on the other side, you want to move forward and implement it in Wayland itself.

I get the frustration. But I still don't understand why they got angry when you wanted to fork Wayland as well (aside from Weston) as listed here.

Minimzing is wrong.

The thing is, minimizing is not really what you think it is. What most people had engraved in their heads is this idea of the desktop as this physical under-layer that lurks beneath their windows. The metaphor has become so powerful that users refuse to have icons on their desktop because it's "messy". Part of this metaphor is putting windows in drawers, the so called "minimizing".

What you need to deconstruct is that all of this desktop and windows business should be seen without the metaphor: Imagine a persistent surface that takes full screen and has no minimize \ maximize \ close buttons on itself. It might have a "task bar" that allows clicking "buttons" on associated boxes to bring other windows before or behind this "desktop". It might be simply a wait-for-right-click surface \ button that launches a small menu (openbox). It could be something like plan9's rio that only allows a term to be launched and actions to be preformed on surfaces. It could be a big tiling surface filled with icons representing actions like windows 8 or ios. It could also have one button that launches a partial or full screen menu like window 7 or android...

Once you realize this, you can understand that:
"Minimizing" another surface simply means it's moved behind the desktop surface.
"Maximize" means drawing to full screen and taking focus above all the other surfaces.

As for the previews, those are just a simple case of drawing on mouse-over the associated window with scaled down raster. It doesn't take a special API or anything.

The functionality achieved this way surpasses the desktop metaphor and yet can mimic it perfectly without added APIs. Their's no need for "minimize" or "maximize" beyond taking focus. It is the client's responsibility to manager the particularities of the windows behavior, not the display server's.

There is no spoon.

Do not try to minimize to desktop — that's impossible. Instead, only try to realize the truth: there is no desktop.

The thing is, minimizing is not really what you think it is. What most people had engraved in their heads is this idea of the desktop as this physical under-layer that lurks beneath their windows. The metaphor has become so powerful that users refuse to have icons on their desktop because it's "messy". Part of this metaphor is putting windows in drawers, the so called "minimizing".

What you need to deconstruct is that all of this desktop and windows business should be seen without the metaphor: Imagine a persistent surface that takes full screen and has no minimize \ maximize \ close buttons on itself. It might have a "task bar" that allows clicking "buttons" on associated boxes to bring other windows before or behind this "desktop". It might be simply a wait-for-right-click surface \ button that launches a small menu (openbox). It could be something like plan9's rio that only allows a term to be launched and actions to be preformed on surfaces. It could be a big tiling surface filled with icons representing actions like windows 8 or ios. It could also have one button that launches a partial or full screen menu like window 7 or android...

Once you realize this, you can understand that:
"Minimizing" another surface simply means it's moved behind the desktop surface.
"Maximize" means drawing to full screen and taking focus above all the other surfaces.

As for the previews, those are just a simple case of drawing on mouse-over the associated window with scaled down raster. It doesn't take a special API or anything.

The functionality achieved this way surpasses the desktop metaphor and yet can mimic it perfectly without added APIs. Their's no need for "minimize" or "maximize" beyond taking focus. It is the client's responsibility to manager the particularities of the windows behavior, not the display server's.

I quickly skimmed through the mailing list of wayland (March only). The biggest problem seems to be the implementation of handling windows (surfaces) with respect to minimize/maximize/resize. You wanted this in the Wayland protocol, but the current upstream developers want it 'to flesh out'?

I am still not clear why minimize was not added with maximize from the beginning. I only discovered this over time, and did not notice anyone else planning to add it.

Originally Posted by Rexilion

It seems that this is coming from a chicken-and-egg problem, listed here:

Yes, I think chicken-and-egg describes the problem quite well.

Originally Posted by Rexilion

They want to do this in a Wayland shell, but don't know how. While on the other side, you want to move forward and implement it in Wayland itself.

Yes, and I have minimize fully working with xwayland in my current northfield/norwood branches on my personal github page.

Originally Posted by Rexilion

I get the frustration. But I still don't understand why they got angry when you wanted to fork Wayland as well (aside from Weston) as listed here.

I am just as confused as everyone else on this. I think things went too far after I expressed my frustrations verbally.

Once you realize this, you can understand that:
"Minimizing" another surface simply means it's moved behind the desktop surface.
"Maximize" means drawing to full screen and taking focus above all the other surfaces.

This is false.

Originally Posted by c117152

As for the previews, those are just a simple case of drawing on mouse-over the associated window with scaled down raster. It doesn't take a special API or anything.

This is partially true but it's not only mouse-over, you can use these prviews in application switchers and many other applications.

Originally Posted by c117152

The functionality achieved this way surpasses the desktop metaphor and yet can mimic it perfectly without added APIs. Their's no need for "minimize" or "maximize" beyond taking focus.

This is false.

Originally Posted by c117152

It is the client's responsibility to manager the particularities of the windows behavior, not the display server's.