1This file is a collection of informal notes, with references to where 2they were originally written. Each note should have a source and date 3mentioned. Let's keep these in date order, newest first. 4 5 6 7----------------------------------------------------------------------- 82015-04-14; Pekka Paalanen <ppaalanen@gmail.com> 9http://lists.freedesktop.org/archives/wayland-devel/2015-April/021309.html 10 11Never destroy weston_views or weston_surfaces from animation hooks. 12Never destroy weston_views from weston_view signals. 13 14Basically, never manipulate a list while transversing it. 15 16 17----------------------------------------------------------------------- 182012-10-23; Pekka Paalanen <ppaalanen@gmail.com> 19http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html 20 21For anyone wanting to port or write their own window manager to Wayland: 22 23Most likely you have a desktop window manager. A quick way to get 24started, is to fork Weston's desktop-shell plugin and start hacking it. 25Qt could be another good choice, but I am not familiar with it. 26 27You also need to understand some concepts. I'm repeating things I wrote 28to the wayland-devel list earlier, a little rephrased. 29 30We need to distinguish three different things here (towards Wayland 31clients): 32 33- compositors (servers) 34 All Wayland compositors are indistinguishable by definition, 35 since they are Wayland compositors. They only differ in the 36 global interfaces they advertise, and for general purpose 37 compositors, we should aim to support the same minimum set of 38 globals everywhere. For instance, all desktop compositors 39 should implement wl_shell. In X, this component corresponds to 40 the X server with a built-in compositing manager. 41 42- shells 43 This is a new concept compared to an X stack. A shell defines 44 how a user and applications interact. The most familiar is a 45 desktop (environment). If KDE, Gnome, and XFCE are desktop 46 environments, they all fall under the *same* shell: the desktop 47 shell. You can have applications in windows, several visible at 48 the same time, you have keyboards and mice, etc. 49 50 An example of something that is not a desktop shell 51 could be a TV user interface. TV is profoundly different: 52 usually no mouse, no keyboard, but you have a remote control 53 with some buttons. Freely floating windows probably do not make 54 sense. You may have picture-in-picture, but usually not several 55 applications showing at once. Most importantly, trying to run 56 desktop applications here does not work due to the 57 incompatible application and user interface paradigms. 58 59 On protocol level, a shell is the public shell interface(s), 60 currently for desktop it is the wl_shell. 61 62- "window managers" 63 The X Window Managers correspond to different wl_shell 64 implementations, not different shells, since they practically 65 all deal with a desktop environment. You also want all desktop 66 applications to work with all window managers, so you need to 67 implement wl_shell anyway. 68 69I understand there could be special purpose X Window Managers, that 70would better correspond to their own shells. These window managers 71might not implement e.g. EWMH by the spec. 72 73When you implement your own window manager, you want to keep the public 74desktop shell interface (wl_shell). You can offer new public 75interfaces, too, but keep in mind, that someone needs to make 76applications use them. 77 78In Weston, a shell implementation has two parts: a weston plugin, and a 79special client. For desktop shell (wl_shell) these are src/shell.c and 80clients/desktop-shell.c. The is also a private protocol extension that 81these two can explicitly communicate with. 82 83The plugin does window management, and the client does most of user 84interaction: draw backgrounds, panels, buttons, lock screen dialog, 85basically everything that is on screen. 86 87----------------------------------------------------------------------- 88