Where should project Weston go?

[Giulio Camuffo]

2014-12-08 14:01 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:
> Dear Wayland community,
>
> I would like to start a discussion on what Weston really is, and where
> it should go, if only to confirm that our concensus still holds.
>
> I feel the need for it, because I personally find it sometimes hard to
> judge whether a big new feature is a good idea or out of scope.
> If I am lacking a clear vision, I can only imagine it is even harder
> for others to decide, and I believe lack of vision can also hinder our
> patch review. It is too easy to postpone reviewing a patch series
> if one is not completely sure it belongs in Weston.
>
> Our website defines Weston as follows:
>
> "Part of the Wayland project is also the Weston reference
> implementation of a Wayland compositor. ... The Weston compositor is a
> minimal and fast compositor and is suitable for many embedded and
> mobile use cases."
>
> To reiterate the main points:
> - the reference implementation
> - minimal
> - fast (performant?)
> - suitable for embedded and mobile (and now automotive?)

I'm not sure it can be said it's minimal anymore. After all it has
many backends, three different renderers and two different shells,
with many additional protocols that a really minimal compositor may
not want to support.

>
> Weston is also a test bed for new protocols and features. We tend to
> land experimental protocols in Weston, try them out there (while in
> this stage, third party projects need to copy the XML files from
> Weston), and when they stabilize, we move protocols into the Wayland
> project and install the XML files from there for everyone to use.
>
> Perhaps the most striking omission in the above is that the desktop for
> PC is not mentioned. The desktop is in scope only through "the
> reference implementation". What does it mean?
>
> I believe it means, that Weston needs to implement all the important
> desktop-related protocol extensions, obviously starting from xdg_shell.
> This is the reference implementation. However, other desktop-oriented
> protocol extensions might not be that obvious. How would we judge them?
> I guess it has to be case by case, which makes it hard for any one
> person to do.
>
> On the other hand, it also means that Weston does not need to, and
> maybe even should not, implement many desktop features that do not
> include a protocol extension to be standardized across Wayland servers.
>
> Where to draw the line? How to keep Weston "minimal" and "fast", while
> we would likely want to make Weston more usable as a desktop server too?

In my opinion Weston is not anymore a simple reference compositor
implementation, and i see it as a good thing. Implementing a
compositor with the same feature set weston has is not an easy feat
and takes a lot of time. Additionally, thanks to the very few
dependencies it can be used in many different applications and
environments.
I don't think the compositor needs to be really simple to read, i
don't think many people want to write a compositor from scratch.
However, i see very often people asking how to make a wayland wm. This
i think is where weston could shine, thanks to the plugin API or a
libweston, and act as a base for many wayland "wm"s. For this reason,
i think, the desktop shell in weston should be a simple reference
implementation. We don't have documentation, so shell.c is the only
thing someone can look at to understand how to write a shell plugin.
In my opinion it's already far too complex (shell.c is more than 6000
LOCs with little structure) and on the other hand i don't see the
manpower to write and maintain a usable desktop shell, and adding a
little feature here and there will not do much for that, but may make
it a lot more complex to understand.
This is not to say we shold not have, say, a xdg_shell implementation.
That is a very basic building block of a wayland desktop shell, so it
fits perfectly there. Stuff like expose or the broken virtual desktops
implementation, not so well, imho.


--
Giulio


>
> Should we add one more goal for Weston: a simple desktop environment?
> But how simple? Would it include, say, a tool to do permanent video
> mode changes? A real screen lock? A task list? Also see the note about
> "camp agnostic" below, which limits the realistic possibilities a lot.
>
> Before one says "Yes!", we need to think about maintainability. Can we
> write a test that would run during 'make check' and see that the
> feature keeps on working? I agree with the saying that if something is
> not tested, you can assume it's broken. It is also a reason why I am so
> thrilled about the test suite improvements.
>
> So far the desktop shell implementation in Weston has not been
> considered anything more than a reference implementation of
> wl_shell and xdg_shell. Proper, more user friendly DEs are external
> projects that build Weston plugins. A problem there is that if
> Weston has to have a feature that is not used from the Weston project
> itself, it may easily break. There is also the problem that the plugin
> ABI is not stable.
>
> The libweston effort by Giulio is set to solve some of those problems. I
> suggested that every minor (not micro) version of libweston needs to be
> cleanly parallel-installable. This will make it easier for
> distributions to ship multiple Weston-based DEs even if their required
> Weston versions differ.
>
> Then again, why was IVI-shell merged? My own opinion is that IVI-shell
> serves the embedded (automotive) space. The people pushing it had a
> strong will to see it upstreamed to Weston, and I have understood they
> are committed to maintaining it. It's not just a code drop, there is
> more to come. I hope that it will also bring new contributions and new
> contributors for all over Weston, benefiting also the desktop.
>
> IVI-shell is also, for a long time or maybe ever, the first non-desktop
> shell in Weston intended for applications and not mostly for nested
> compositors like the fullscreen shell. It helps to clarify the concept
> of shell (protocol).
>
> Then what should we not put in Weston?
>
> So far Weston has been kept deliberately "camp" agnostic, which means
> that dependencies to GNOME, KDE, E or similar "camps" are not allowed.
> In practice, Weston should never even optionally depend on GTK+, Qt,
> EFL, or such. Weston does optionally depend on glib, but I suppose that
> is acceptable considering the features depending on it. It has been camp
> agnostic to not favour any particular existing DE camp, and to not
> alienate any other DE camp.
>
> I think walking that middle road has been good, and we should continue
> that.
>
> What do you think what Weston should be in the future?
>
>
> Btw. I still would not claim to be *the* Wayland/Weston maintainer, even
> though lately I have practically been doing that as time permits
> (sponsored by Collabora). I would like to see more of capable people
> rising as reviewers and some through experience eventually to
> maintainership. I cannot do this alone forever like Kristian did. To
> make it easier to step forward and take a bit of responsibility as a
> reviewer, I wrote this email to query and set up the community
> expectations.
>
> Note, that even though I'm interested in the concensus, it is not one
> person, one vote. The vote is weighed by the person's track record, as
> in most open source projects.
>
>
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel