GH-Next Feature Update

[Scott Moreau]

Hi all,

I announced about a week ago that I was starting a series of branches
on github labeled next, as a staging area for new features and patch
sets. The response is continually surprising and we've got a lot done
in just one week. I wanted to share an update with everyone and
explain a little more about the purposes behind my efforts.

So we all know wayland is awesome because it allows ways to use the
new Linux graphics driver stack to its full potential. This is
exciting for several reasons. It means 1) an alternative to X 2) a
potentially faster and smoother desktop experience 3) a possibility
for more interesting effects. It is interesting for technical
audiences and users alike. Until now, we haven't known any capable
display server on Linux except X. Accelerated compositing has become
the expected norm since Compiz. With that, I'd like to introduce some
history.

We all know X has been around and it's X. It has served as the de
facto standard Linux display server for many years. It has also served
as a fertile bed for exciting projects, one of most important being
Compiz.

Before compiz, there was just X and some window managers. Around 2004,
Novell contracted David Reveman to begin work on what we know today as
compiz. In order to do what was required for compiz as an X window
manager, a new extension was introduced called
GLX_EXT_texture_from_pixmap. This is the key spec used to make compiz
magic happen. During early developments, the community was bursting
with excitement to see and and play with these newly conceived
features. Unfortunately, Reveman was not easy to communicate with and
soon the project was forked under the name Beryl. This was an exciting
time because not only were there new possibilities never before seen
in X but now there was a rather large flamewar driving Beryl and
Compiz development. Compiz was all about the core initially, while
Beryl exhibited more fun and candy features. In fact, a large majority
of the many compiz plugins we all know and love today were developed
under the Beryl project. After flaming for a long time, finally the
two sides came to terms and the two projects were merged as
compiz-fusion. Today, only a select few remember Beryl but it's legacy
lives on through the code that was ultimately adopted by the compiz
project. After this happened in about '06-'07, the compiz-fusion
developers maintained the project and distributions packaged it. It
has been a great success for many years. Many people have written
their own plugins for compiz, some of them never published.

With compiz, there were some interesting doors opened. This revealed
certain possibilities that may have not otherwise been considered.
This also revealed many bugs in X, some still standing, like the input
redirection problem. Now today, we have wayland. The problem is the
same as it was with Compiz. The community wants to play with the toys
and make new ones now, while most of the core developers want to work
mainly on core and not flesh out 'the rest of it'. I have been
studying compiz ever since it first came out. I've helped on the
project but I also listened to many users. I noticed that you can't
possibly satisfy every possible case but you can make good guesses and
put the user in control where appropriate. I think Compiz does a
pretty good job of this, all things considered. These are some things
I noticed through working on compiz:

- People get really excited by eye candy and visuals
- The community is a much more powerful force than given credit for
- X was not built for accelerated compositing managers

Now today, we have a more interesting situation. With compiz and
beryl, it didn't matter what or which, because everything just uses X
'as normal'. However today, we have the same problem of the community
ready to move forward to make some interesting toys. It was fine
because X protocol was already vetted and no changes were required to
existing X clients. However with today's situation, it's different.
The protocol is most certainly not vetted, largely incomplete and
doesn't have basic items you'd expect to use for any reasonably sane,
usable implementation. A random example is minimize effect animation.
How can you program this type of effect, when the protocol to minimize
does not exist yet? Pretty difficult. Wayland is awesome at the core
but the protocol to do everyday desktop stuff is lacking at best. The
community wants to move forward but development is taking too long.
Everyone would like to see everyone else agree with everyone but..
when's the last time that ever happened? So, gh next is going to sort
of 'run ahead' and see what we can do and what problems we uncover in
the process. I've done enough fighting over the past year to get basic
protocol upstream to wayland core and it's time to move forward.
Anyone interested in discussing the wayland protocol and all the
semantic details can continue and try to figure out what is best for
wayland. Meanwhile, gh next wants to see what interesting toys we can
make using slap-stick test protocols and implementations. By 'we' in
this context I mean 'myself and any willing contributers'. I encourage
any interested ones to come along for the ride.

I started gh next as a summer project that hopefully will cause useful
things to happen somehow [TM]. So far, it does not deserve a title
other than the code name 'gh next'. As of this date, gh next is
(re)based on current upstream wayland/weston master HEAD. Currently
it's serving a few different purposes. It:

- Offers a place for new users and programmers to learn about and
contribute to wayland
- Fosters a place for new ideas and developments
- is a place where runtime-critical issues are monitored (such as
runtime-critical weston and mesa problems/fixes)


The intended work-flow:

I am using github to host gh next (obviously). I am trying to avoid
merges unless necessary, and only apply single patches onto gh next.
However, github makes it very convenient to do one-click-merges. (When
I see the green big 'merge now' button, I am tempted to click on it.)
I plan on doing this as a summer project for right now but who knows
what will happen. It might die tomorrow or, it become the modern day
Beryl and drive competitive development.


As I mentioned from the outset, the response has been tremendous and
we have a lot going on. Here is a list of the features working in gh
next that are not in upstream weston:

- More aesthetically pleasing default theme
- Working xwayland titlebar buttons
- Maximize/Minimize/Close
   - xwayland csd buttons (client)
   - xwayland csd buttons (compositor)
   - toytoolkit minimize button
   - taskbar menu state toggling
- Snap-off maximize
- Taskbar (window list)
- Volume widget

I would like to thank all that have contributed so far and I encourage
others to join in. The weston gh next git history is a nice
representation of the multiple members that have helped by submitting
code.

If you would like to help out, you can:

- build and test the code
- submit pull requests and patches
- come hang out in the IRC channel

All of the code used is from upstream, except the relevant repos
listed below. These repos must be built from gh next.

Here's a quick run down of the project details:

Code: https://github.com/soreau?tab=repositories
     Using the 'next' branches of:
   - wayland
   - weston
   - gtk+
   - qtwayland

IRC: #wayland-dev

We have a nicely intuitive bot in the IRC channel now too thanks to
Giulio. Stop by and check it out sometime.

gh next will try to stay rebased on upstream master as long as
feasible. Currently, it's mostly just a collection of patches that are
not currently or might not ever be upstreamed. It's not a fork, but
hopefully it will be able to help drive overall core wayland and DE
development by adjusting users' expectations. I still don't think
we're in a flamewar at this time despite the Mir fallout but I *would*
like to see cooler things happen in a more timely manner than what has
been the pace.


Here is a video to show some of the ideas we are tinkering with:


http://www.youtube.com/watch?v=_dgGRr1xt68&feature=youtu.be