notes.txt 3.77 KB
Newer Older
Pekka Paalanen's avatar
Pekka Paalanen committed
1 2 3 4 5 6
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.

7 8 9 10 11 12 13 14 15 16
2015-04-14; Pekka Paalanen <>

Never destroy weston_views or weston_surfaces from animation hooks.
Never destroy weston_views from weston_view signals.

Basically, never manipulate a list while transversing it.

Pekka Paalanen's avatar
Pekka Paalanen committed
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
2012-10-23; Pekka Paalanen <>

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

- 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
Abdur Rehman's avatar
Abdur Rehman committed
	implementations, not different shells, since they practically
Pekka Paalanen's avatar
Pekka Paalanen committed
65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87
	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.