Clarifying scope and goals for weston

[Tiago Vignatti]

On 04/17/2013 05:34 PM, Kristian Høgsberg wrote:
> 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.

but this doesn't mean either that we're not encouraging people building 
product-quality desktop shells using weston, right? It can be done 
externally using the plugin API as I posted some weeks ago.

and about the plugin API, any words about keeping it stable or say, when 
developers can break it?


this is a good email Kristian. Thank you,

Tiago