Clarifying scope and goals for weston

[Kristian Høgsberg]

Hello list,

A few weeks ago, Thiago Maciera sent out a good email about patch
review and how everybody can help with the review effort:

  http://lists.freedesktop.org/archives/wayland-devel/2013-March/008174.html

I see more reviews on the list now and I really appreciate that;
thanks to Thiago for writing the email and to everybody who has jumped
in and reviewed patches.  However, Pekka brought up a good point:

   "Anyone can review coding style, but what if we massage coding
    style and other minor details back and forth a lot, and then
    someone does a proper subjective review NAK'ing the whole idea, or
    at least forcing a complete rewrite. Is that review and
    improvement work wasted for nothing, or is it useful?"

Fortunately a lot of patches are easy to review and accept - bug fixes
or fleshing out FIXMEs or a self-contained new backend for example.
Patches that add features or change established behavior are typically
less obvious and in those cases it's of course good to first try to
determine whether the overall idea is right.  To that end, I'd like to
see if we can all agree on the scope of weston.

Part of the confusion around this is that weston started out as just a
way to verify the protocol as well as gbm, KMS, evdev etc integration,
which implies that it's throw-away code or at best a source for copy
and paste.  On the other end of the scale, what weston is today is
obviously a lot more than just sample code, we even have a toy desktop
that makes it look like it's a real desktop environment.

In my mind, the main output of weston is the core compositor and the
plug-in API.  We have a very efficient GLES2 renderer, very good KMS
integration and overlay usage, and a good input stack.  We have good
infrastructure for writing custom backends and a flexible way to
plug-in a higher-level shell component to handle window-manager-like
responsiblities.  This is the part of weston I consider product
quality and we have to maintain high standards when working in that
area - strict error checking, handle all corner cases etc.  The core
compositors goal is to be a base for other projects, similar to how
the X server isn't a full desktop environment or mobile/embedded UI,
but a core technology to build one upon.  It is also still the
reference implementation and must implement and exercise all core
protocol.

The desktop shell in weston serves three goals: to validate wl_shell
protocol, to make weston do something useful when you start it up, and
to provide a reference for how to implement a shell module.  The
desktop shell is not supposed to be a generally useful desktop
environment.  When we're implementing something for the weston desktop
shell, we go for simplicity and protocol coverage rather than full
configurability or external dependencies.

As for xwayland, I'd like this module to be better quality and provide
easy integration of X applications for UIs that build on weston.  As
it is, it's rather spotty in its support for ICCCM and EWMH though,
and mainly serves as a validation effort for X integration.

Tell me what you think,
Kristian