Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

[Scott Moreau]

On Mon, Mar 25, 2013 at 1:11 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
> On Mon, Mar 25, 2013 at 12:59:22PM -0600, Scott Moreau wrote:
>> Hi Casey,
>>
>> On Mon, Mar 25, 2013 at 12:53 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
>> > On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote:
>> >> Yes, there is no reason to fork libwayland. And I don't feel this is a
>> >> true fork, just a temporary rename to avoid the confusion it might
>> >> otherwise cause, remaining under the 'wayland' name. Wayland has been
>> >> in my github repo since I've uploaded it there. The only difference
>> >> now is, the name has been changed and an official fork announcement
>> >> has been made by request.
>> >
>> > ...ok. I'll leave how exactly that's less confusing as an exercise to the
>> > reader.
>> >
>> > Seriously, if you'd just forked Weston and left Wayland alone I'd be on your
>> > side. Even happy. This, however, is just making a political mess.
>> >
>> > --CJD
>>
>> I'm not sure where the confusion is. Northfield == Wayland but with a
>> few changes to wl_shell_surface interface for minimize/maximize/close
>> stuff. These changes are actually being discussed on the mailing list
>> for possible review and inclusion. Once these basic events/requests go
>> upstream, there will not be a need for northfield as a patched version
>> of wayland. In reality, this is just a project name that !wayland. The
>> need for this custom libwayland is only necessary until the new
>> protocol is pushed upstream at which point, this need should be
>> eliminated.
>>
>
> Shell surface was in weston for awhile. Why not just wl_new_shell_surface in
> your forked weston's protocol extensions?
>
> --CJD

There are multiple parts to the shell in the code. You have the core
protocol in wayland, weston's shell plugin and the desktop-shell
client also in weston. The wl_shell_surface is somewhat of a catch-all
interface for any client that wants to display its surface in a
wayland compositor. In order to do basic features such as move,
resize, maximize, minimize, etc you need certain event/requests, often
times in pairs. Currently, maximize is in core wayland
wl_shell_surface interface protocol and it only makes sense, to put
minimize in the same place as maximize, in the code. You could do it
as a local weston protocol and have clients connect to this, yes.
However, this is a core desktop functionality and belongs in the core.
Also, more work would be required to move the code from weston to
wayland. The amount of work is negligible but it still has to be done.
This could possibly be error prone. Also, the discussion about this
protocol should be done in the light and realization by all, that this
is in fact a core functionality and an expected part of todays desktop
functionality per specs. However, I think you're not seeing the bigger
picture here, so please allow me to explain a bit.

There are certain implications that we've had with X that make it very
difficult to do certain things in a compositing manager for X. For
example, Sam Spilsbury was one of the very first people to try and get
input redirection (IR) work in X, under compiz. He worked very
diligently with IRL colleague Joel Bosveld to try and convince X to
fake certain input events so that you could use a transformed surface.
See http://www.youtube.com/watch?v=YHEisy-ORvY and take note of the
date. This is extremely problematic in X, yet I think people don't
realize that we've never been able to do IR properly in X. There are
other things that wayland makes far simpler than the X+compiz model.
Yet, we still have the same capabilities.

It is noteworthy here, that not only did Sam Spilsbury work on IR, but
we also worked on a ton of other cool things for compiz, including a
Head Tracking plugin when wiimotes first came out
http://www.youtube.com/watch?v=5M7ejHp2NM8 again, notice the date. Sam
Spilbury pushed compiz forward immensely and drove compiz development
with massive contribution including but not limited to:

- Awesome Compiz Videos
These videos were not particularly easy to shoot. It was not as easy
as it is today with weston's built-in wcap recorder. You'd have to 1)
Acquire the right hardware. 2) Install your drivers. This could be
absolute nightmare depending on whether or not you needed XGL and what
hardware you had. 3) Install compiz/beryl. Even with the code
installed, documentation was scarce and developers had to figure
things out for themselves. 3) Shoot the video. There was a special
vidcap recorder plugin introduced in Beryl that allowed shooting a
video (even with optional watermark image). He would do all editing to
make the video stellar as an advertisement
https://www.youtube.com/user/smSpillaz/videos?query=compiz
- Driving Development
He single handedly drove development by keeping the channels alive,
upbeat and active, asking all of the pertinent thought provoking
questions and submitting countless patches and ideas.
- Countless Plugins
Sam also wrote tons of plugins, some of which can be seen here
http://cgit.compiz.org/~smspillaz working nonstop whenever he has not
busy with scholastic studies
- Support
He helped everyone he could install and use compiz through IRC, his
beloved blog, on the compiz forums, compiz wiki, compiz planet, compiz
everything. I would go as far to say, that Sam Spilsbury aka
'smspilaz' is just as much of an icon of compiz, as the desktop cube
we all know and love. Sam also personally helped walk me around the
compiz source code initially, before I even had a clue about
compositing window managers or the code involved.

This has turned out to also double as an apology to Sam Spilsbury.
Sorry Sam, I did not intend to portray your work in a bad light. I
would like to see you offer your experience to this project.

Casey: The point is, this isn't just a frivolous fork. This isn't
about wayland. It's about focusing the energy of a collective group of
people who want to see and do cool things on the Linux Desktop.

- Scott