Juan, Jonas and Christopher,
I appreciate your feedback! Small additions to shells are indeed not a
problem. It was not a right example to make my point. As it is now, Weston
can be considered barebone since the code base is small. The question is
how long it will stay that way, given some interest from Canonical to
integrate it into Ubuntu QQ or RR (hopefully QQ) and potentially other
Please, let me give you another example of what I'm trying to do (without
going into application specifics that you are unlikely to be interested in).
Suppose that you want to develop your own Wayland compliant server
(W-server) that can render in 3D. Due to renderer's complexity you
anticipate that the compositor will grow quite a bit and that will pose
significant problems for future testing.
So, before you start out, you want to set up another very simple compositor
whose job is _not_ to composite but to _test_ functionality and speed of
the graphics driver stack, X as a client, some other hardware, client's
compliance to Wayland protocol, and so on. The purpose of such a W-server
is to have a regression system that checks dependent
_libraries_and_drivers_ rather than your 3D compositor. If something goes
wrong with client's rendering (e.g. too slow, visual artifacts) you can use
that "regression compositor" to quickly identify if the problem stems from
some upgraded or buggy drivers. This will save you a lot of debugging
effort and time.
The barebone version of Weston is the perfect candidate for the "regression
compositor". It doesn't need several full featured clients or shells to
minimize risk of injecting bugs. It only needs to include the minimal
architecture plus a set of driver/library test codes. It does need to be
relatively stable and up-to-date with the latest Wayland protocol changes
and some critical bug fixes though.
I hope the above example illustrates one of several potential applications
for the barebone compositor. The point here is not to get rid of useful
features from Weston. They are surely needed when I use Weston as a _user_.
The above example uses the compositor as a _tester_ with predefined
composite screen objects.
Does it make sense or am I making things more complicated than they should
On Wed, Jul 11, 2012 at 3:59 AM, Christopher James Halse Rogers <
Post by Christopher James Halse Rogers Post by Mikalai Kisialiou
There is an article on http://www.phoronix.com that there is a new
feature of sliding desktop support in Weston. I am wondering if it
would make sense to split Weston implemention into 2 distinct ones: a
barebone implementation with minimal features (architecture + driver
compatibility) and a full-featured version?
I am not saying that the sliding desktop is somehow a bad idea (it is
a great idea). I do love this feature and will definitely like to see
Some people may look at potential opportunities to implement their own
version of a Wayland-compliant server. These people will likely be
from different areas and seek some kind of a "Hello world" version of
a Wayland compliant server. The applications may range from low-power
portable devices with limited performance to powerful CAD
workstations stacking dual graphics card firepower. Because
the requirements and expectations for the graphics interface on
such systems are vastly different, I am afraid that a W-server that
aims to be one-size-fits-all may end up being one-size-fits-none. As
optional features start propagating into Weston it will grow
into something similar to another X-server, and we are going to be
back to square 1.
I understand that there will be some overhead involved for developers
to maintain 2 branches. However, most features will probably not fall
into the barebone version, so the commits for new cool features would
still be limited to 1 branch only. Bug fixes will indeed be harder to
commit. Can the 2nd full-featured branch be a library on top of the
barebone architectural version?
Also, is there some sort of a policy or a decision making process as
to what gets committed into Weston? What do the main developers think
about 2 branches? I just thought I'd raise these concerns before a
whole list of optional features gets committed into Weston.
As long as it's restricted to the shells and anything under clients/ I
don't think it matters how much functionality is folded into weston.
Indeed, it's probably valuable, as it helps ensure the core weston &
wayland code can support such use.
Eventually it might become sufficiently big to do a source split, but
that seems a way off.
I agree that there needs to be a higher bar than ?chuck it in? for
commits touching the core weston compositor, but I don't think I've seen
any commits overstepping reasonable bounds there.
-------------- next part --------------
An HTML attachment was scrubbed...