Wayland and Weston 1.0

Tue Oct 23 20:32:32 PDT 2012

Wayland team,
Thank you for your effort and contribution to this excellent project. I'm
really hoping to see Wayland in one of Linux distros soon.

Pekka,
It is probably a good idea to copy/paste the information that you posted
into some kind of a user guide. A simple and short text file would suffice.
Otherwise, it will get buried under the avalanche of posts on the dev list.
Also, more usage descriptions are welcome as well. Just looking at the code
doesn't tell me where the core functionality is, how to debug total
freezes, how popup windows are handled and many other useful topics that
you covered in various posts.

Nick

On Tue, Oct 23, 2012 at 12:21 AM, Pekka Paalanen <ppaalanen at gmail.com>wrote:

> On Mon, 22 Oct 2012 16:46:52 -0700
> Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
>
> > On Mon, 22 Oct 2012 19:26:46 -0400
> > Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> >
> > > Wayland and Weston 1.0.0 have been released!
> > >
> > > Thanks and congrats to everybody involved for making this happen.
> > > We're entering a new, exciting and somewhat scary phase for Wayland.
> > > As of this 1.0.0 release, we're changing the development model and
> > > committing to the the protocol and client side API we have now.
> >
> > Woohoo!  I'm really excited by this.  My hope is that with a "stable"
> > release number out there, people will really start evaluating Wayland
> > and Weston for their needs, and hopefully see the same sorts of big
> > power and memory footprint savings I've seen when compared with other
> > solutions.
> >
> > I really hope one of the desktop environments jumps on board now.  With
> > a modern toolkit the porting effort shouldn't be huge (mostly in the
> > window management component), and the power savings on a typical laptop
> > have the potential to be huge.  Given the existing toolkit support, it's
> > also possible someone could start a simple, new environment with Weston
> > at its core.
>
> Indeed!
>
> Though, I think it is worth mentioning, that Wayland 1.0 is about the
> core protocol. Desktop environments are going to need a lot more, for
> example:
> - clients want to restack their surfaces
> - server to ask a client to minimize/maximize/fullscreen or go
>   normally windowed
> - client wants to minimize itself
> - server wants a client to not draw window decorations, shadows, title
>   bar, on all or some sides (would be especially useful for tiling
>   window managers, I guess)
> - to be able to recall window position
>
> I'm not aware of any of the above available through the wl_shell
> protocol yet, so if you want to really implement a real DE, you will be
> facing some protocol designing, too. Currently the wl_shell protocol is
> just enough to be able to work with windows in Weston.
>
> I believe this is mostly because there has not been time to concentrate
> on desktop shell protocols yet, just get something that one can test the
> core with, but also to avoid dictating a single desktop protocol design
> without getting some real experimentation and discussion. Maturing a
> generic desktop protocol will certainly take time, and more people than
> there were designing the core protocol.
>
> For anyone wanting to port or write their own window manager to Wayland:
>
> Most likely you have a desktop window manager. A quick way to get
> started, is to fork Weston's desktop-shell plugin and start hacking it.
> Qt could be another good choice, but I am not familiar with it.
>
> You also need to understand some concepts. I'm repeating things I wrote
> to the wayland-devel list earlier [1], a little rephrased.
>
> We need to distinguish three different things here (towards Wayland
> clients):
>
> - compositors (servers)
>         All Wayland compositors are indistinguishable by definition,
>         since they are Wayland compositors. They only differ in the
>         global interfaces they advertise, and for general purpose
>         compositors, we should aim to support the same minimum set of
>         globals everywhere. For instance, all desktop compositors
>         should implement wl_shell. In X, this component corresponds to
>         the X server with a built-in compositing manager.
>
> - shells
>         This is a new concept compared to an X stack. A shell defines
>         how a user and applications interact. The most familiar is a
>         desktop (environment). If KDE, Gnome, and XFCE are desktop
>         environments, they all fall under the *same* shell: the desktop
>         shell. You can have applications in windows, several visible at
>         the same time, you have keyboards and mice, etc.
>
>         An example of something that is not a desktop shell
>         could be a TV user interface. TV is profoundly different:
>         usually no mouse, no keyboard, but you have a remote control
>         with some buttons. Freely floating windows probably do not make
>         sense. You may have picture-in-picture, but usually not several
>         applications showing at once. Most importantly, trying to run
>         desktop applications here does not work due to the
>         incompatible application and user interface paradigms.
>
>         On protocol level, a shell is the public shell interface(s),
>         currently for desktop it is the wl_shell.
>
> - "window managers"
>         The X Window Managers correspond to different wl_shell
>         implementations, not different shells, since they pratically
>         all deal with a desktop environment. You also want all desktop
>         applications to work with all window managers, so you need to
>         implement wl_shell anyway.
>
> I understand there could be special purpose X Window Managers, that
> would better correspond to their own shells. These window managers
> might not implement e.g. EWMH by the spec.
>
> When you implement your own window manager, you want to keep the public
> desktop shell interface (wl_shell). You can offer new public
> interfaces, too, but keep in mind, that someone needs to make
> applications use them.
>
> In Weston, a shell implementation has two parts: a weston plugin, and a
> special client. For desktop shell (wl_shell) these are src/shell.c and
> clients/desktop-shell.c. The is also a private protocol extension that
> these two can explicitly communicate with.
>
> The plugin does window management, and the client does most of user
> interaction: draw backgrounds, panels, buttons, lock screen dialog,
> basically everything that is on screen.
>
>
> Phew... this came out a lot longer than I intended, and I really need
> to stop for now. This is my view of the Wayland world, hoping to
> clarify concepts, and raise discussion where (if?) I got it wrong. :-)
>
>
> Thanks,
> pq
>
> [1]
> http://lists.freedesktop.org/archives/wayland-devel/2012-August/004796.html
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20121023/71ad39ed/attachment.html>