[PATCH weston 6/6] Add informal notes file

[Kristian Høgsberg]

On Wed, Oct 24, 2012 at 09:43:10AM +0300, Pekka Paalanen wrote:
> By request on the wayland-devel mailing list, we could start collecting
> useful writings here.
> 
> However, this is not meant to be a substitute to proper documentation,
> though I understand it may very well become one. Better than nothing, I
> guess, and hopefully helps in writing real documentation.

I suppose we can do this, but it becomes hard to manage pretty fast.
Ideally we'd work this into the documentation instead.  Over time a
lot of small snippets like this becomes hard to search or make sense of.

This and the previous 5 patches committed.

Kristian

> Feel free to add stuff.
> 
> Signed-off-by: Pekka Paalanen <ppaalanen at gmail.com>
> ---
>  notes.txt |   77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 77 insertions(+), 0 deletions(-)
>  create mode 100644 notes.txt
> 
> diff --git a/notes.txt b/notes.txt
> new file mode 100644
> index 0000000..e49052b
> --- /dev/null
> +++ b/notes.txt
> @@ -0,0 +1,77 @@
> +This file is a collection of informal notes, with references to where
> +they were originally written. Each note should have a source and date
> +mentioned. Let's keep these in date order, newest first.
> +
> +
> +
> +-----------------------------------------------------------------------
> +2012-10-23; Pekka Paalanen <ppaalanen at gmail.com>
> +http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html
> +
> +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, 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.
> +
> +-----------------------------------------------------------------------
> -- 
> 1.7.8.6
>